История изменений - Asterisk: Вопросы и Ответы

факсы через e1

Проблема в том, что факсы при входящих звонка не принимаются. При исходящих все без проблем. АТС yeastar м1, плата e1 встроенная

chan_dahdi.conf:

[trunkgroups]
[channels]
usecallerid=yes
hidecallerid=no
usecallingpres=yes
echocancel=yes
echocancelwhenbridged=yes
immediate=no
language=ru
faxdetect=incoming
;#include dahdi-pri.conf
#include dahdi-channels.conf

dahdi/system.conf:

loadzone = ru
defaultzone = ru

span=2,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16


echocanceller=oslec,1-15,17-31

dahdi/ysport.conf:

port_e1_1=e1,1-15,17-31

cat dahdi_test - такой команды не знает(

На шлюзе

Fax mode = Pass-Through
Fax tone detection mode = Caller or Callee

Может кто сталкивался с подобной проблемой?

факсы через e1

Проблема в том, что факсы при входящих звонка не принимаются. При исходящих все без проблем. АТС yeastar м1, плата e1 встроенная

chan_dahdi.conf:

[trunkgroups]
[channels]
usecallerid=yes
hidecallerid=no
usecallingpres=yes
echocancel=yes
echocancelwhenbridged=yes
immediate=no
language=ru
faxdetect=incoming
;#include dahdi-pri.conf
#include dahdi-channels.conf

dahdi/system.conf:

loadzone = ru
defaultzone = ru

span=2,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16


echocanceller=oslec,1-15,17-31

dahdi/ysport.conf:

port_e1_1=e1,1-15,17-31

cat dahdi_test - такой команды не знает(

На шлюзе

Fax mode = Pass-Through
Fax tone detection mode = Caller or Callee

Может кто сталкивался с подобной проблемой?

UPD 14-04-16-51

Все же похоже на баг в самой АТС, тк входящие вызовы при срабатывании факса он странно обрабатывает, а именно в большинстве случаев срабатывает контекст [detect-fax-to-email] и на отправляющей стороне факс уходит, ну а у нас конечно нигде не вылезит:

-- Executing [fax@voicemenu-custom-sklad:1] Goto("DAHDI/3-1", "detect-fax-to-email,s,1") in new stack
    -- Goto (detect-fax-to-email,s,1)
    -- Executing [s@detect-fax-to-email:1] NoOp("DAHDI/3-1", "ready fax to ") in new stack
    -- Executing [s@detect-fax-to-email:2] GotoIf("DAHDI/3-1", "0>0?from-outside,,1") in new stack
    -- Executing [s@detect-fax-to-email:3] Set("DAHDI/3-1", "SENDMAIL=0") in new stack
    -- Executing [s@detect-fax-to-email:4] Set("DAHDI/3-1", "FAXFROM=0172698830") in new stack
    -- Executing [s@detect-fax-to-email:5] Set("DAHDI/3-1", "FAXFILE=/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack
    -- Executing [s@detect-fax-to-email:6] ReceiveFAX("DAHDI/3-1", "/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack

Однако иногда контекст не срабатывает, а вызов обрабатывается, как при принятии факса:

[2014-04-14 16:35:01] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38

и факс в этом случае проходит...

Но все же есть случаи, когда контекст не срабатывает, но и факс не приходит, на отправляющей стороне факс так же не пищит об ошибке.. Но это ладно... Как бы пофиксить этот [detect-fax-to-email].

В конекстах, создаваемые вебмордой, в конце прописано:

exten = fax,1,Goto(detect-fax-to-email,s,1)

Пробовал убирать эту строку и все точно так же переписать в extensions_custom, но ситуацию это не поменяло (в целом не ждал, что что-то поменяется)

Отправил все это производителю, пока жду ответа

факсы через e1

Проблема в том, что факсы при входящих звонка не принимаются. При исходящих все без проблем. АТС yeastar м1, плата e1 встроенная

chan_dahdi.conf:

[trunkgroups]
[channels]
usecallerid=yes
hidecallerid=no
usecallingpres=yes
echocancel=yes
echocancelwhenbridged=yes
immediate=no
language=ru
faxdetect=incoming
;#include dahdi-pri.conf
#include dahdi-channels.conf

dahdi/system.conf:

loadzone = ru
defaultzone = ru

span=2,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16


echocanceller=oslec,1-15,17-31

dahdi/ysport.conf:

port_e1_1=e1,1-15,17-31

cat dahdi_test - такой команды не знает(

На шлюзе

Fax mode = Pass-Through
Fax tone detection mode = Caller or Callee

Может кто сталкивался с подобной проблемой?

UPD 14-04-16-51

Все же похоже на баг в самой АТС, тк входящие вызовы при срабатывании факса он странно обрабатывает, а именно в большинстве случаев срабатывает контекст [detect-fax-to-email] и на отправляющей стороне факс уходит, ну а у нас конечно нигде не вылезит:

-- Executing [fax@voicemenu-custom-sklad:1] Goto("DAHDI/3-1", "detect-fax-to-email,s,1") in new stack
    -- Goto (detect-fax-to-email,s,1)
    -- Executing [s@detect-fax-to-email:1] NoOp("DAHDI/3-1", "ready fax to ") in new stack
    -- Executing [s@detect-fax-to-email:2] GotoIf("DAHDI/3-1", "0>0?from-outside,,1") in new stack
    -- Executing [s@detect-fax-to-email:3] Set("DAHDI/3-1", "SENDMAIL=0") in new stack
    -- Executing [s@detect-fax-to-email:4] Set("DAHDI/3-1", "FAXFROM=0172698830") in new stack
    -- Executing [s@detect-fax-to-email:5] Set("DAHDI/3-1", "FAXFILE=/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack
    -- Executing [s@detect-fax-to-email:6] ReceiveFAX("DAHDI/3-1", "/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack

Однако иногда контекст не срабатывает, а вызов обрабатывается, как при принятии факса:

[2014-04-14 16:35:01] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38

и факс в этом случае проходит...

Но все же есть случаи, когда контекст не срабатывает, но и факс не приходит, на отправляющей стороне факс так же не пищит об ошибке.. Но это ладно... Как бы пофиксить этот [detect-fax-to-email].

В конекстах, создаваемые вебмордой, в конце прописано:

exten = fax,1,Goto(detect-fax-to-email,s,1)

Пробовал убирать эту строку и все точно так же переписать в extensions_custom, но ситуацию это не поменяло (в целом не ждал, что что-то поменяется)

Отправил все это производителю, пока жду ответа

nental, такой команды не знает, вот все, что есть:

pri set debug {on|off|0|1|2} s Enables PRI debugging on a span
            pri set debug file Sends PRI debug output to the specified file
                pri show debug Displays current PRI debug settings
                pri show spans Displays PRI Information
                 pri show span Displays PRI Information
              pri show version Displays libpri version

факсы через e1

Проблема в том, что факсы при входящих звонка не принимаются. При исходящих все без проблем. АТС yeastar м1, плата e1 встроенная

chan_dahdi.conf:

[trunkgroups]
[channels]
usecallerid=yes
hidecallerid=no
usecallingpres=yes
echocancel=yes
echocancelwhenbridged=yes
immediate=no
language=ru
faxdetect=incoming
;#include dahdi-pri.conf
#include dahdi-channels.conf

dahdi/system.conf:

loadzone = ru
defaultzone = ru

span=2,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16


echocanceller=oslec,1-15,17-31

dahdi/ysport.conf:

port_e1_1=e1,1-15,17-31

cat dahdi_test - такой команды не знает(

На шлюзе

Fax mode = Pass-Through
Fax tone detection mode = Caller or Callee

Может кто сталкивался с подобной проблемой?

UPD 14-04-16-51

Все же похоже на баг в самой АТС, тк входящие вызовы при срабатывании факса он странно обрабатывает, а именно в большинстве случаев срабатывает контекст [detect-fax-to-email] и на отправляющей стороне факс уходит, ну а у нас конечно нигде не вылезит:

-- Executing [fax@voicemenu-custom-sklad:1] Goto("DAHDI/3-1", "detect-fax-to-email,s,1") in new stack
    -- Goto (detect-fax-to-email,s,1)
    -- Executing [s@detect-fax-to-email:1] NoOp("DAHDI/3-1", "ready fax to ") in new stack
    -- Executing [s@detect-fax-to-email:2] GotoIf("DAHDI/3-1", "0>0?from-outside,,1") in new stack
    -- Executing [s@detect-fax-to-email:3] Set("DAHDI/3-1", "SENDMAIL=0") in new stack
    -- Executing [s@detect-fax-to-email:4] Set("DAHDI/3-1", "FAXFROM=0172698830") in new stack
    -- Executing [s@detect-fax-to-email:5] Set("DAHDI/3-1", "FAXFILE=/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack
    -- Executing [s@detect-fax-to-email:6] ReceiveFAX("DAHDI/3-1", "/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack

Однако иногда контекст не срабатывает, а вызов обрабатывается, как при принятии факса:

[2014-04-14 16:35:01] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38

и факс в этом случае проходит...

Но все же есть случаи, когда контекст не срабатывает, но и факс не приходит, на отправляющей стороне факс так же не пищит об ошибке.. Но это ладно... Как бы пофиксить этот [detect-fax-to-email].

В конекстах, создаваемые вебмордой, в конце прописано:

exten = fax,1,Goto(detect-fax-to-email,s,1)

Пробовал убирать эту строку и все точно так же переписать в extensions_custom, но ситуацию это не поменяло (в целом не ждал, что что-то поменяется)

Отправил все это производителю, пока жду ответа

~~nental,~~ meral, такой команды не знает, вот все, что есть:

pri set debug {on|off|0|1|2} s Enables PRI debugging on a span
            pri set debug file Sends PRI debug output to the specified file
                pri show debug Displays current PRI debug settings
                pri show spans Displays PRI Information
                 pri show span Displays PRI Information
              pri show version Displays libpri version

факсы через e1

Проблема в том, что факсы при входящих звонка не принимаются. При исходящих все без проблем. АТС yeastar м1, плата e1 встроенная

chan_dahdi.conf:

[trunkgroups]
[channels]
usecallerid=yes
hidecallerid=no
usecallingpres=yes
echocancel=yes
echocancelwhenbridged=yes
immediate=no
language=ru
faxdetect=incoming
;#include dahdi-pri.conf
#include dahdi-channels.conf

dahdi/system.conf:

loadzone = ru
defaultzone = ru

span=2,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16


echocanceller=oslec,1-15,17-31

dahdi/ysport.conf:

port_e1_1=e1,1-15,17-31

cat dahdi_test - такой команды не знает(

На шлюзе

Fax mode = Pass-Through
Fax tone detection mode = Caller or Callee

Может кто сталкивался с подобной проблемой?

UPD 14-04-16-51

Все же похоже на баг в самой АТС, тк входящие вызовы при срабатывании факса он странно обрабатывает, а именно в большинстве случаев срабатывает контекст [detect-fax-to-email] и на отправляющей стороне факс уходит, ну а у нас конечно нигде не вылезит:

-- Executing [fax@voicemenu-custom-sklad:1] Goto("DAHDI/3-1", "detect-fax-to-email,s,1") in new stack
    -- Goto (detect-fax-to-email,s,1)
    -- Executing [s@detect-fax-to-email:1] NoOp("DAHDI/3-1", "ready fax to ") in new stack
    -- Executing [s@detect-fax-to-email:2] GotoIf("DAHDI/3-1", "0>0?from-outside,,1") in new stack
    -- Executing [s@detect-fax-to-email:3] Set("DAHDI/3-1", "SENDMAIL=0") in new stack
    -- Executing [s@detect-fax-to-email:4] Set("DAHDI/3-1", "FAXFROM=0172698830") in new stack
    -- Executing [s@detect-fax-to-email:5] Set("DAHDI/3-1", "FAXFILE=/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack
    -- Executing [s@detect-fax-to-email:6] ReceiveFAX("DAHDI/3-1", "/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack

Однако иногда контекст не срабатывает, а вызов обрабатывается, как при принятии факса:

[2014-04-14 16:35:01] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38

и факс в этом случае проходит...

Но все же есть случаи, когда контекст не срабатывает, но и факс не приходит, на отправляющей стороне факс так же не пищит об ошибке.. Но это ладно... Как бы пофиксить этот [detect-fax-to-email].

В конекстах, создаваемые вебмордой, в конце прописано:

exten = fax,1,Goto(detect-fax-to-email,s,1)

Пробовал убирать эту строку и все точно так же переписать в extensions_custom, но ситуацию это не поменяло (в целом не ждал, что что-то поменяется)

Отправил все это производителю, пока жду ответа

meral, ~~такой команды не знает,~~ вот ~~все, что есть:~~дебаг, когда факс не прошел:

pri set debug {on|off|0|1|2} s Enables PRI debugging [2014-04-14 17:50:21] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38
[ span number: 1 ]
< Protocol Discriminator: Q.931 (8)  len=13
< TEI=0 Call Ref: len= 2 (reference 31/0x1F) (Sent from originator)
< Message Type: DISCONNECT (69)
< [08 02 8a ff]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Network beyond the interworking point (10)
<                  Ext: 1  Cause: Interworking, unspecified (127), class = Interworking (7) ]
< [1e 02 82 88]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Public network serving the local user (2)
<                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
Received message for call 0x49ff4788 on a span
            pri set debug file Sends PRI debug output link 0x3810d0 TEI/SAPI 0/0
-- Processing IE 8 (cs0, Cause)
-- Processing IE 30 (cs0, Progress Indicator)
-- Found active call: 0x49ff4788 cref:31
q931.c:8709 post_handle_q931_message: Call 31 enters state 12 (Disconnect Indication).  Hold state: Idle
    -- Channel 0/2, span 2 got hangup request, cause 127
  == Spawn extension (queue-885, 885, 3) exited non-zero on 'DAHDI/2-1'
q931.c:6839 q931_hangup: Hangup other cref:31
q931.c:6596 __q931_hangup: ourstate Disconnect Indication, peerstate Disconnect Request, hold-state Idle
q931.c:5705 q931_release: Call 31 enters state 19 (Release Request).  Hold state: Idle

> DL-DATA request
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 31/0x1F) (Sent to originator)
> Message Type: RELEASE (77)
TEI=0 Transmitting N(S)=8, window is open V(A)=8 K=7
[ span number: 1 ]
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 31/0x1F) (Sent to originator)
> Message Type: RELEASE (77)
> [08 02 81 ff]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the specified file
                pri show debug Displays current PRI debug settings
                pri show spans Displays PRI Information
                 pri show span Displays PRI Information
              pri show version Displays libpri version
local user (1)
>                  Ext: 1  Cause: Interworking, unspecified (127), class = Interworking (7) ]
    -- Hungup 'DAHDI/2-1'
  == MixMonitorCall close filestream
  == End MixMonitorCall Recording DAHDI/2-1

Самому его прочитать не хватает скилла(

факсы через e1

Проблема в том, что факсы при входящих звонка не принимаются. При исходящих все без проблем. АТС yeastar м1, плата e1 встроенная

chan_dahdi.conf:

[trunkgroups]
[channels]
usecallerid=yes
hidecallerid=no
usecallingpres=yes
echocancel=yes
echocancelwhenbridged=yes
immediate=no
language=ru
faxdetect=incoming
;#include dahdi-pri.conf
#include dahdi-channels.conf

dahdi/system.conf:

loadzone = ru
defaultzone = ru

span=2,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16


echocanceller=oslec,1-15,17-31

dahdi/ysport.conf:

port_e1_1=e1,1-15,17-31

cat dahdi_test - такой команды не знает(

На шлюзе

Fax mode = Pass-Through
Fax tone detection mode = Caller or Callee

Может кто сталкивался с подобной проблемой?

UPD 14-04-16-51

Все же похоже на баг в самой АТС, тк входящие вызовы при срабатывании факса он странно обрабатывает, а именно в большинстве случаев срабатывает контекст [detect-fax-to-email] и на отправляющей стороне факс уходит, ну а у нас конечно нигде не вылезит:

-- Executing [fax@voicemenu-custom-sklad:1] Goto("DAHDI/3-1", "detect-fax-to-email,s,1") in new stack
    -- Goto (detect-fax-to-email,s,1)
    -- Executing [s@detect-fax-to-email:1] NoOp("DAHDI/3-1", "ready fax to ") in new stack
    -- Executing [s@detect-fax-to-email:2] GotoIf("DAHDI/3-1", "0>0?from-outside,,1") in new stack
    -- Executing [s@detect-fax-to-email:3] Set("DAHDI/3-1", "SENDMAIL=0") in new stack
    -- Executing [s@detect-fax-to-email:4] Set("DAHDI/3-1", "FAXFROM=0172698830") in new stack
    -- Executing [s@detect-fax-to-email:5] Set("DAHDI/3-1", "FAXFILE=/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack
    -- Executing [s@detect-fax-to-email:6] ReceiveFAX("DAHDI/3-1", "/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack

Однако иногда контекст не срабатывает, а вызов обрабатывается, как при принятии факса:

[2014-04-14 16:35:01] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38

и факс в этом случае проходит...

Но все же есть случаи, когда контекст не срабатывает, но и факс не приходит, на отправляющей стороне факс так же не пищит об ошибке.. Но это ладно... Как бы пофиксить этот [detect-fax-to-email].

В конекстах, создаваемые вебмордой, в конце прописано:

exten = fax,1,Goto(detect-fax-to-email,s,1)

Пробовал убирать эту строку и все точно так же переписать в extensions_custom, но ситуацию это не поменяло (в целом не ждал, что что-то поменяется)

Отправил все это производителю, пока жду ответа

meral, вот дебаг, когда факс не прошел:

pri set debug on span 1


[2014-04-14 17:50:21] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38
[ span number: 1 ]
< Protocol Discriminator: Q.931 (8)  len=13
< TEI=0 Call Ref: len= 2 (reference 31/0x1F) (Sent from originator)
< Message Type: DISCONNECT (69)
< [08 02 8a ff]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Network beyond the interworking point (10)
<                  Ext: 1  Cause: Interworking, unspecified (127), class = Interworking (7) ]
< [1e 02 82 88]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Public network serving the local user (2)
<                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
Received message for call 0x49ff4788 on link 0x3810d0 TEI/SAPI 0/0
-- Processing IE 8 (cs0, Cause)
-- Processing IE 30 (cs0, Progress Indicator)
-- Found active call: 0x49ff4788 cref:31
q931.c:8709 post_handle_q931_message: Call 31 enters state 12 (Disconnect Indication).  Hold state: Idle
    -- Channel 0/2, span 2 got hangup request, cause 127
  == Spawn extension (queue-885, 885, 3) exited non-zero on 'DAHDI/2-1'
q931.c:6839 q931_hangup: Hangup other cref:31
q931.c:6596 __q931_hangup: ourstate Disconnect Indication, peerstate Disconnect Request, hold-state Idle
q931.c:5705 q931_release: Call 31 enters state 19 (Release Request).  Hold state: Idle

> DL-DATA request
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 31/0x1F) (Sent to originator)
> Message Type: RELEASE (77)
TEI=0 Transmitting N(S)=8, window is open V(A)=8 K=7
[ span number: 1 ]
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 31/0x1F) (Sent to originator)
> Message Type: RELEASE (77)
> [08 02 81 ff]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Interworking, unspecified (127), class = Interworking (7) ]
    -- Hungup 'DAHDI/2-1'
  == MixMonitorCall close filestream
  == End MixMonitorCall Recording DAHDI/2-1

Самому его прочитать не хватает скилла(

факсы через e1

Проблема в том, что факсы при входящих звонка не принимаются. При исходящих все без проблем. АТС yeastar м1, плата e1 встроенная

chan_dahdi.conf:

[trunkgroups]
[channels]
usecallerid=yes
hidecallerid=no
usecallingpres=yes
echocancel=yes
echocancelwhenbridged=yes
immediate=no
language=ru
faxdetect=incoming
;#include dahdi-pri.conf
#include dahdi-channels.conf

dahdi/system.conf:

loadzone = ru
defaultzone = ru

span=2,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16


echocanceller=oslec,1-15,17-31

dahdi/ysport.conf:

port_e1_1=e1,1-15,17-31

cat dahdi_test - такой команды не знает(

На шлюзе

Fax mode = Pass-Through
Fax tone detection mode = Caller or Callee

Может кто сталкивался с подобной проблемой?

UPD 14-04-16-51

Все же похоже на баг в самой АТС, тк входящие вызовы при срабатывании факса он странно обрабатывает, а именно в большинстве случаев срабатывает контекст [detect-fax-to-email] и на отправляющей стороне факс уходит, ну а у нас конечно нигде не вылезит:

-- Executing [fax@voicemenu-custom-sklad:1] Goto("DAHDI/3-1", "detect-fax-to-email,s,1") in new stack
    -- Goto (detect-fax-to-email,s,1)
    -- Executing [s@detect-fax-to-email:1] NoOp("DAHDI/3-1", "ready fax to ") in new stack
    -- Executing [s@detect-fax-to-email:2] GotoIf("DAHDI/3-1", "0>0?from-outside,,1") in new stack
    -- Executing [s@detect-fax-to-email:3] Set("DAHDI/3-1", "SENDMAIL=0") in new stack
    -- Executing [s@detect-fax-to-email:4] Set("DAHDI/3-1", "FAXFROM=0172698830") in new stack
    -- Executing [s@detect-fax-to-email:5] Set("DAHDI/3-1", "FAXFILE=/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack
    -- Executing [s@detect-fax-to-email:6] ReceiveFAX("DAHDI/3-1", "/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack

Однако иногда контекст не срабатывает, а вызов обрабатывается, как при принятии факса:

[2014-04-14 16:35:01] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38

и факс в этом случае проходит...

Но все же есть случаи, когда контекст не срабатывает, но и факс не приходит, на отправляющей стороне факс так же не пищит об ошибке.. Но это ладно... Как бы пофиксить этот [detect-fax-to-email].

В конекстах, создаваемые вебмордой, в конце прописано:

exten = fax,1,Goto(detect-fax-to-email,s,1)

Пробовал убирать эту строку и все точно так же переписать в extensions_custom, но ситуацию это не поменяло (в целом не ждал, что что-то поменяется)

Отправил все это производителю, пока жду ответа

meral, вот дебаг, когда факс не прошел:

pri set debug on span 1


[2014-04-14 17:50:21] 18:15:59] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38
  == Extension Changed 666[extensions-hintcontext] new state Idle for Notify User 776
  == Extension Changed 666[extensions-hintcontext] new state Idle for Notify User 778
  == Spawn extension (queue-885, 885, 3) exited non-zero on 'DAHDI/1-1'
  == MixMonitorCall close filestream
q931.c:6839 q931_hangup: Hangup other cref:20
q931.c:6596 __q931_hangup: ourstate Active, peerstate Active, hold-state Idle
q931.c:5785 q931_disconnect: Call 20 enters state 11 (Disconnect Request).  Hold state: Idle
MyPBX*CLI>
> DL-DATA request
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: DISCONNECT (69)
TEI=0 Transmitting N(S)=33, window is open V(A)=33 K=7
[ span number: 1 ]
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
    -- Hungup 'DAHDI/1-1'
  == End MixMonitorCall Recording DAHDI/1-1
[ span number: 1 ]
< Protocol Discriminator: Q.931 (8)  len=13
len=5
< TEI=0 Call Ref: len= 2 (reference 31/0x1F) 20/0x14) (Sent from originator)
< Message Type: DISCONNECT (69)
< [08 02 8a ff]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Network beyond the interworking point (10)
<                  Ext: 1  Cause: Interworking, unspecified (127), class = Interworking (7) ]
< [1e 02 82 88]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Public network serving the local user (2)
<                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
RELEASE (77)
Received message for call 0x49ff4788 0x49f24a50 on link 0x3810d0 TEI/SAPI 0/0
-- Processing IE 8 (cs0, Cause)
-- Processing IE 30 (cs0, Progress Indicator)
-- Found active call: 0x49ff4788 cref:31
q931.c:8709 q931.c:8622 post_handle_q931_message: Call 31 20 enters state 12 (Disconnect Indication). 0 (Null).  Hold state: Idle
    -- Channel 0/2, span 2 got hangup request, cause 127
  == Spawn extension (queue-885, 885, 3) exited non-zero on 'DAHDI/2-1'
q931.c:6839 q931_hangup: Hangup other cref:31
cref:20
q931.c:6596 __q931_hangup: ourstate Disconnect Indication, Null, peerstate Disconnect Release Request, hold-state Idle
q931.c:5705 q931_release: Call 31 enters state 19 (Release Request).  Hold state: Idle

> DL-DATA request
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 31/0x1F) 20/0x14) (Sent to originator)
> Message Type: RELEASE (77)
COMPLETE (90)
TEI=0 Transmitting N(S)=8, N(S)=34, window is open V(A)=8 V(A)=34 K=7
[ span number: 1 ]
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 31/0x1F) 20/0x14) (Sent to originator)
> Message Type: RELEASE (77)
COMPLETE (90)
> [08 02 81 ff]
90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Interworking, unspecified (127), Normal Clearing (16), class = Interworking (7) Normal Event (1) ]
    -- Hungup 'DAHDI/2-1'
  == MixMonitorCall close filestream
  == End MixMonitorCall Recording DAHDI/2-1
q931.c:6839 q931_hangup: Hangup other cref:20
q931.c:6596 __q931_hangup: ourstate Null, peerstate Null, hold-state Idle
Destroying call 0x49f24a50, ourstate Null, peerstate Null, hold-state Idle

Самому его прочитать не хватает скилла(

факсы через e1

Проблема в том, что факсы при входящих звонка не принимаются. При исходящих все без проблем. АТС yeastar м1, плата e1 встроенная

chan_dahdi.conf:

[trunkgroups]
[channels]
usecallerid=yes
hidecallerid=no
usecallingpres=yes
echocancel=yes
echocancelwhenbridged=yes
immediate=no
language=ru
faxdetect=incoming
;#include dahdi-pri.conf
#include dahdi-channels.conf

dahdi/system.conf:

loadzone = ru
defaultzone = ru

span=2,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16


echocanceller=oslec,1-15,17-31

dahdi/ysport.conf:

port_e1_1=e1,1-15,17-31

cat dahdi_test - такой команды не знает(

На шлюзе

Fax mode = Pass-Through
Fax tone detection mode = Caller or Callee

Может кто сталкивался с подобной проблемой?

UPD 14-04-16-51

Все же похоже на баг в самой АТС, тк входящие вызовы при срабатывании факса он странно обрабатывает, а именно в большинстве случаев срабатывает контекст [detect-fax-to-email] и на отправляющей стороне факс уходит, ну а у нас конечно нигде не вылезит:

-- Executing [fax@voicemenu-custom-sklad:1] Goto("DAHDI/3-1", "detect-fax-to-email,s,1") in new stack
    -- Goto (detect-fax-to-email,s,1)
    -- Executing [s@detect-fax-to-email:1] NoOp("DAHDI/3-1", "ready fax to ") in new stack
    -- Executing [s@detect-fax-to-email:2] GotoIf("DAHDI/3-1", "0>0?from-outside,,1") in new stack
    -- Executing [s@detect-fax-to-email:3] Set("DAHDI/3-1", "SENDMAIL=0") in new stack
    -- Executing [s@detect-fax-to-email:4] Set("DAHDI/3-1", "FAXFROM=0172698830") in new stack
    -- Executing [s@detect-fax-to-email:5] Set("DAHDI/3-1", "FAXFILE=/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack
    -- Executing [s@detect-fax-to-email:6] ReceiveFAX("DAHDI/3-1", "/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack

Однако иногда контекст не срабатывает, а вызов обрабатывается, как при принятии факса:

[2014-04-14 16:35:01] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38

и факс в этом случае проходит...

Но все же есть случаи, когда контекст не срабатывает, но и факс не приходит, на отправляющей стороне факс так же не пищит об ошибке.. Но это ладно... Как бы пофиксить этот [detect-fax-to-email].

В конекстах, создаваемые вебмордой, в конце прописано:

exten = fax,1,Goto(detect-fax-to-email,s,1)

Пробовал убирать эту строку и все точно так же переписать в extensions_custom, но ситуацию это не поменяло (в целом не ждал, что что-то поменяется)

Отправил все это производителю, пока жду ответа

meral, вот дебаг, когда факс не прошел:

pri set debug on span 1


[2014-04-14 18:15:59] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38
  == Extension Changed 666[extensions-hintcontext] new state Idle for Notify User 776
  == Extension Changed 666[extensions-hintcontext] new state Idle for Notify User 778
  == Spawn extension (queue-885, 885, 3) exited non-zero on 'DAHDI/1-1'
  == MixMonitorCall close filestream
q931.c:6839 q931_hangup: Hangup other cref:20
q931.c:6596 __q931_hangup: ourstate Active, peerstate Active, hold-state Idle
q931.c:5785 q931_disconnect: Call 20 enters state 11 (Disconnect Request).  Hold state: Idle
MyPBX*CLI>
> DL-DATA request
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: DISCONNECT (69)
TEI=0 Transmitting N(S)=33, window is open V(A)=33 K=7
[ span number: 1 ]
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
    -- Hungup 'DAHDI/1-1'
  == End MixMonitorCall Recording DAHDI/1-1
[ span number: 1 ]
< Protocol Discriminator: Q.931 (8)  len=5
< TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent from originator)
< Message Type: RELEASE (77)
Received message for call 0x49f24a50 on link 0x3810d0 TEI/SAPI 0/0
q931.c:8622 post_handle_q931_message: Call 20 enters state 0 (Null).  Hold state: Idle
q931.c:6839 q931_hangup: Hangup other cref:20
q931.c:6596 __q931_hangup: ourstate Null, peerstate Release Request, hold-state Idle

> DL-DATA request
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: RELEASE COMPLETE (90)
TEI=0 Transmitting N(S)=34, window is open V(A)=34 K=7
[ span number: 1 ]
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
q931.c:6839 q931_hangup: Hangup other cref:20
q931.c:6596 __q931_hangup: ourstate Null, peerstate Null, hold-state Idle
Destroying call 0x49f24a50, ourstate Null, peerstate Null, hold-state Idle

Самому его прочитать не хватает скилла(

факсы через e1

Проблема в том, что факсы при входящих звонка не принимаются. При исходящих все без проблем. АТС yeastar м1, плата e1 встроенная

chan_dahdi.conf:

[trunkgroups]
[channels]
usecallerid=yes
hidecallerid=no
usecallingpres=yes
echocancel=yes
echocancelwhenbridged=yes
immediate=no
language=ru
faxdetect=incoming
;#include dahdi-pri.conf
#include dahdi-channels.conf

dahdi/system.conf:

loadzone = ru
defaultzone = ru

span=2,1,0,ccs,hdb3
bchan=1-15,17-31
dchan=16


echocanceller=oslec,1-15,17-31

dahdi/ysport.conf:

port_e1_1=e1,1-15,17-31

cat dahdi_test - такой команды не знает(

На шлюзе

Fax mode = Pass-Through
Fax tone detection mode = Caller or Callee

Может кто сталкивался с подобной проблемой?

UPD 14-04-16-51

Все же похоже на баг в самой АТС, тк входящие вызовы при срабатывании факса он странно обрабатывает, а именно в большинстве случаев срабатывает контекст [detect-fax-to-email] и на отправляющей стороне факс уходит, ну а у нас конечно нигде не вылезит:

-- Executing [fax@voicemenu-custom-sklad:1] Goto("DAHDI/3-1", "detect-fax-to-email,s,1") in new stack
    -- Goto (detect-fax-to-email,s,1)
    -- Executing [s@detect-fax-to-email:1] NoOp("DAHDI/3-1", "ready fax to ") in new stack
    -- Executing [s@detect-fax-to-email:2] GotoIf("DAHDI/3-1", "0>0?from-outside,,1") in new stack
    -- Executing [s@detect-fax-to-email:3] Set("DAHDI/3-1", "SENDMAIL=0") in new stack
    -- Executing [s@detect-fax-to-email:4] Set("DAHDI/3-1", "FAXFROM=0172698830") in new stack
    -- Executing [s@detect-fax-to-email:5] Set("DAHDI/3-1", "FAXFILE=/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack
    -- Executing [s@detect-fax-to-email:6] ReceiveFAX("DAHDI/3-1", "/home/fax/0172698830-20140414-1501-1930981073.tiff") in new stack

Однако иногда контекст не срабатывает, а вызов обрабатывается, как при принятии факса:

[2014-04-14 16:35:01] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38

и факс в этом случае проходит...

Но все же есть случаи, когда контекст не срабатывает, но и факс не приходит, на отправляющей стороне факс так же не пищит об ошибке.. Но это ладно... Как бы пофиксить этот [detect-fax-to-email].

В конекстах, создаваемые вебмордой, в конце прописано:

exten = fax,1,Goto(detect-fax-to-email,s,1)

Пробовал убирать эту строку и все точно так же переписать в extensions_custom, но ситуацию это не поменяло (в целом не ждал, что что-то поменяется)

Отправил все это производителю, пока жду ответа

meral, вот дебаг, когда факс не прошел:

pri set debug on span 1

при ошибке факса:

[2014-04-14 18:15:59] WARNING[1190]: chan_sip.c:8679 process_sdp: Unsupported SDP media type in offer: image 8012 udptl t38
q931.c:6839 q931_hangup: Hangup other cref:20
q931.c:6596 __q931_hangup: ourstate Active, peerstate Active, hold-state Idle
q931.c:5785 q931_disconnect: Call 20 enters state 11 (Disconnect Request).  Hold state: Idle
MyPBX*CLI>
> DL-DATA request
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: DISCONNECT (69)
TEI=0 Transmitting N(S)=33, window is open V(A)=33 K=7
[ span number: 1 ]
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
    -- Hungup 'DAHDI/1-1'
  == End MixMonitorCall Recording DAHDI/1-1
[ span number: 1 ]
< Protocol Discriminator: Q.931 (8)  len=5
< TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent from originator)
< Message Type: RELEASE (77)
Received message for call 0x49f24a50 on link 0x3810d0 TEI/SAPI 0/0
q931.c:8622 post_handle_q931_message: Call 20 enters state 0 (Null).  Hold state: Idle
q931.c:6839 q931_hangup: Hangup other cref:20
q931.c:6596 __q931_hangup: ourstate Null, peerstate Release Request, hold-state Idle

> DL-DATA request
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: RELEASE COMPLETE (90)
TEI=0 Transmitting N(S)=34, window is open V(A)=34 K=7
[ span number: 1 ]
> Protocol Discriminator: Q.931 (8)  len=9
> TEI=0 Call Ref: len= 2 (reference 20/0x14) (Sent to originator)
> Message Type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
q931.c:6839 q931_hangup: Hangup other cref:20
q931.c:6596 __q931_hangup: ourstate Null, peerstate Null, hold-state Idle
Destroying call 0x49f24a50, ourstate Null, peerstate Null, hold-state Idle

Самому его прочитать не хватает скилла(

История изменений [назад]

факсы через e1

факсы через e1

факсы через e1

факсы через e1

факсы через e1

факсы через e1

факсы через e1

факсы через e1

факсы через e1