Linksys SPA-2102, Software Version: 5.1.12

[amper]

Linksys SPA-2102, Software Version: 5.1.12

 

1) Как поставить пароль на доступ к IVR или полностью его отключить? Максимум, что нашел, это возможность включить "Protect_IVR_FactoryReset" через "Provision", но смысла во всем этом, когда запросто можно изменить IP девайса?

 

2) Как изменить тоны (короткие гудки, длинные гудки, зуммер) на европейские (российские), сейчас там явно американский вариант стоит. В вэб интерфейсе есть настройка "Call Progress Tones", но что там прописывать ума не приложу, ни в одном мануале это не отражено.

 

3) После отбоя на удаленной стороне, проходит около 2-3 секунд, прежде чем SPA выдает в линию короткие гудки. Можно как-то это поправить?

 

P.S. И вообще, был бы благодарен за толковый мануал по описанию всех (или основных) функций доступных через вэб интерфейс, обеспечивающих нормальную работу девайса, желательно на русском. Или хотя бы краткий базисный HOWTO, что необходимо изменить в настройках для корректной работы, прохождения факсов и т.д.

Edited February 9, 2008 by amper

[ram_scan]

Гуглить на слово sipura. На забугорных форумах очень много полезного попадается.

[amper]

А у нас ее разве не юзают? Самая низкая цена за порт ведь!

[ram_scan]

По граблям народ как правило успевает пройти раньше именно там. А у нас народ ленив, чтобы собирать, систематизировать и в переведенном виде выкладывать нужные знания.

 

Например, я практически ни на одном из войпных форумов на которых я бываю ни одна душа живая не спросила как настроить диалплан, хотя эта первая вещь которая делается после базовой настройки. Так без диалплана и живут, или у буржуев консультируются =) В документации то не написано.

 

Что касается 3 пункта, то это очень похоже на багу в софте. Установленную SIP сессию можно завершить корректно как минимум двумя способами, залипон с задержкой отбоя проявляется только при каком-то одном. Кажется девайсу перед bye необходимо в обязательном порядке слать cancel. Если послать просто bye то он потом ждет эти 3 секунды какого-то еще сообщения, после чего отваливается по таймауту.

Edited February 11, 2008 by ram_scan

[amper]

Опытным путем пришел к таким значениям:

Dial Tone: 420@-16;10(*/0/1)

Busy Tone: 420@-16,10@-16;10(.5/.5/1+3)

Ring Back Tone: 420@-16,@-10;*(2/4/1+1)

 

Проблема с отбоем решается установкой параметра Reorder Delay в 0.

 

Вот только не очень пойму, как работает Т.38? Если к SPA подключен обычный аналоговый факс, процесс передачи факса начинается, как правило, с телефонного звонка и разговора, после чего обе стороны стартуют. Вот тут по идее девайс должен автоматом распознать факс и сменить кодек на Т.38?

 

И по прежнему актуален вопрос установки пароля\полного отключения IVR.

Edited February 11, 2008 by amper

[Мартен]

Вот только не очень пойму, как работает Т.38? Если к SPA подключен обычный аналоговый факс, процесс передачи факса начинается, как правило, с телефонного звонка и разговора, после чего обе стороны стартуют. Вот тут по идее девайс должен автоматом распознать факс и сменить кодек на Т.38?

приблизительно. там REINVITE должен происходить

 

[Mikler]

В invite передается SDP image с параментрами факса замечена интересная особенность если настройки буфера не как у неё отбивает сразуже

 

[ram_scan]

Странно, Не должно быть такой пронографии. По крайней мере я не замечал.

[amper]

Столкнулся с проблемой, при входящем звонке - после поднятия трубки получаем одностороннюю слышимость (не слышно удаленного абонента), после нажатия кнопки flash (т.е. постановки звонка на удержание), и последующего возвращения к звонку - слышимость становится двухсторонняя.

 

Проверялось на разных SIP адаптерах (как аппаратных, так и программных).

 

Девайс за NATом, в нате стоит полная трансляция всех внешних портов на внутренний IP.

 

Никто с такой ерундой не сталкивался?

 

[ram_scan]

Мало информации для анализа. Надо дамп сессии смотреть. Линксис с использованием stun сервера не вполне корректно работает только за symmetric nat. Первый раз он из-за ната rtp портом промахивается. Стоит попытаться ничего не портмапить и использовать встроенный механизм nat traversal, или портмап вздыбливать очень аккуратно и с пониманием вопроса, и настроить соответствующим образом шлюз.

[amper]

Вот лог, правда от SJPhone, но глюки там аналогичные тем, что получаем на SPA.

 

17:43:13 SIP.Network DEBUG     
2008-02-12 14:43:13.187 UDP 213.85.168.52:5060->LOCAL
INVITE sip:84995024515@77.106.215.9 SIP/2.0
Via: SIP/2.0/UDP 213.85.168.52:5060;branch=z9hG4bK810vst00aov0ocgi07c1.1
From: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
To: "User1"<sip:84995024515@qwerty.cnt.ru>
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 118269776 INVITE
Contact: <sip:84997414519@213.85.168.52:5060;transport=udp>
Diversion: <sip:74995024515@213.85.168.66:5060;user=phone>;reason=unconditional;counter=1
Supported: 100rel
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: multipart/mixed,application/media_control+xml,application/sdp
Max-Forwards: 9
Content-Type: application/sdp
Content-Length: 455

v=0
o=BroadWorks 107947880 1 IN IP4 213.85.168.52
s=-
c=IN IP4 213.85.168.52
t=0 0
m=audio 23900 RTP/AVP 0 8 18 99 101 102 2 103 125 100
a=rtpmap:99 G.729a/8000
a=rtpmap:101 G.726-16/8000
a=rtpmap:102 G.726-24/8000
a=rtpmap:103 G.729b/8000
a=rtpmap:125 G.nX64/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38

17:43:13 SIP.Network DEBUG     
2008-02-12 14:43:13.187 UDP LOCAL->213.85.168.52:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 213.85.168.52:5060;branch=z9hG4bK810vst00aov0ocgi07c1.1;received=213.85.168.52
From: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
To: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 118269776 INVITE
Content-Length: 0
Server: SJphone/1.65.377a (SJ Labs)


17:43:13 SIP.Network DEBUG     
2008-02-12 14:43:13.671 UDP LOCAL->213.85.168.52:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 213.85.168.52:5060;branch=z9hG4bK810vst00aov0ocgi07c1.1;received=213.85.168.52
From: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
To: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
Contact: <sip:84995024515@77.106.215.9>
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 118269776 INVITE
Content-Length: 0
Server: SJphone/1.65.377a (SJ Labs)


17:43:17 SIPCall    DEBUG     SIP Call 401 (sip:84997414519@213.85.168.66;user=phone): Accept
17:43:17 SIPCall    INFO      SDP Processor dump:
SDP Header:
  Processor: "-", ID = 20
  Connection: 192.168.193.200
  Session:3411816193
  Version:3411816193

Open Internet mode: no

Media slot #0: [audio] -- [normal]
  Remote:
    RTP:  213.85.168.52 : 23900
    RTCP: 213.85.168.52 : 23901
    Capability: PCMU
    RFC2833: disabled

  Remote sdp:
    m=audio 23900 RTP/AVP 0 8 18 99 101 102 2 103 125 100
    a=rtpmap:99 G.729a/8000
    a=rtpmap:101 G.726-16/8000
    a=rtpmap:102 G.726-24/8000
    a=rtpmap:103 G.729b/8000
    a=rtpmap:125 G.nX64/8000
    a=rtpmap:100 X-NSE/8000
    a=fmtp:100 200-202
    a=X-sqn:0
    a=X-cap: 1 audio RTP/AVP 100
    a=X-cpar: a=rtpmap:100 X-NSE/8000
    a=X-cpar: a=fmtp:100 200-202
    a=X-cap: 2 image udptl t38


17:43:17 SIPCall    INFO      Multimedia Session dump:
  Multimedia Session dump:
    Session ID: 20
    IP address: 0.0.0.0:0

    2 channels created:

      RTP Audio Inbound channel dump:
        Status: started
        Capability: undefined
        Local  RTP  = 0.0.0.0 : 49168
        Local  RTCP = 0.0.0.0 : 49169
        Remote RTP  = 213.85.168.52 : 23900
        Remote RTCP = 213.85.168.52 : 23901

      RTP Audio Outbound channel dump:
        Status: started
        Capability: Microsoft CCITT G.711 u-Law CODEC ( Payload Type = 0 )
        Local  RTP  = 0.0.0.0 : 49168
        Local  RTCP = 0.0.0.0 : 49169
        Remote RTP  = 213.85.168.52 : 23900
        Remote RTCP = 213.85.168.52 : 23901
        RFC2833 Disabled



17:43:17 SIPSession INFO      Session Timer supported but not used in this session
17:43:17 SIP.Network DEBUG     
2008-02-12 14:43:17.750 UDP LOCAL->213.85.168.52:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 213.85.168.52:5060;branch=z9hG4bK810vst00aov0ocgi07c1.1;received=213.85.168.52
From: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
To: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
Contact: <sip:84995024515@77.106.215.9>
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 118269776 INVITE
Content-Length: 200
Content-Type: application/sdp
Server: SJphone/1.65.377a (SJ Labs)
Supported: replaces,norefersub,timer

v=0
o=- 3411816193 3411816193 IN IP4 192.168.193.200
s=SJphone
c=IN IP4 192.168.193.200
t=0 0
m=audio 49168 RTP/AVP 0
c=IN IP4 192.168.193.200
a=rtpmap:0 PCMU/8000
a=setup:active
a=sendrecv

17:43:17 SIP.Network DEBUG     
2008-02-12 14:43:17.937 UDP 213.85.168.52:5060->LOCAL
ACK sip:84995024515@77.106.215.9 SIP/2.0
Via: SIP/2.0/UDP 213.85.168.52:5060;branch=z9hG4bK83r3a33068k0jcoga441.1
From: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
To: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 118269776 ACK
Contact: <sip:84997414519@213.85.168.52:5060;transport=udp>
Max-Forwards: 9
Content-Length: 0


17:43:18 SIP.Registration INFO      NAT/Firewall binding refresh by dummy packet to UDP:213.85.168.52:5060
17:43:18 SIP.Network DEBUG     
2008-02-12 14:43:18.406 UDP LOCAL->213.85.168.52:5060


17:43:18 SIP.Registration INFO      Scheduling NAT/Firewall binding refresh for sip:84995024515@qwerty.cnt.ru after 20 

seconds
17:43:30 SIPCall    DEBUG     SIP Call 401 (sip:84997414519@213.85.168.66;user=phone): Hold
17:43:30 SIP.Network DEBUG     
2008-02-12 14:43:30.531 UDP LOCAL->213.85.168.52:5060
INVITE sip:84997414519@213.85.168.52:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 77.106.215.9;branch=z9hG4bKc0a8c1c80000019647b1b09200001bce000000cc;rport
From: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
To: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
Contact: <sip:84995024515@77.106.215.9>
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: SJphone/1.65.377a (SJ Labs)
Content-Length: 186
Content-Type: application/sdp
Supported: replaces,norefersub,timer

v=0
o=- 3411816193 3411816195 IN IP4 77.106.215.9
s=SJphone
c=IN IP4 77.106.215.9
t=0 0
m=audio 49168 RTP/AVP 0
c=IN IP4 0.0.0.0
a=rtpmap:0 PCMU/8000
a=setup:active
a=sendonly

17:43:30 SIP.Network DEBUG     
2008-02-12 14:43:30.671 UDP 213.85.168.52:5060->LOCAL
SIP/2.0 200 OK
Via: SIP/2.0/UDP 77.106.215.9;received=77.106.215.9;branch=z9hG4bKc0a8c1c80000019647b1b09200001bc
e000000cc;rport=5060
From: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
To: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 1 INVITE
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,UPDATE,NOTIFY
Supported: 
Accept: multipart/mixed,application/media_control+xml,application/sdp
Contact: <sip:84997414519@213.85.168.52:5060;transport=udp>
Content-Type: application/sdp
Content-Length: 247

v=0
o=BroadWorks 107947880 2 IN IP4 213.85.168.52
s=-
c=IN IP4 213.85.168.52
t=0 0
m=audio 23900 RTP/AVP 0
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38

17:43:30 SIP.Parser NOTICE    Empty Supported header.
17:43:30 SIPSession INFO      Session Timer supported but not used in this session
17:43:30 SIPCall    INFO      SDP Processor dump:
SDP Header:
  Processor: "-", ID = 20
  Connection: 77.106.215.9
  Session:3411816193
  Version:3411816195

Open Internet mode: no

Media slot #0: [audio] -- [active hold]
  Remote:
    RTP:  213.85.168.52 : 23900
    RTCP: 213.85.168.52 : 23901
    Capability: PCMU
    RFC2833: disabled

  Remote sdp:
    m=audio 23900 RTP/AVP 0
    a=X-sqn:0
    a=X-cap: 1 audio RTP/AVP 100
    a=X-cpar: a=rtpmap:100 X-NSE/8000
    a=X-cpar: a=fmtp:100 200-202
    a=X-cap: 2 image udptl t38


17:43:30 SIPCall    INFO      Multimedia Session dump:
  Multimedia Session dump:
    Session ID: 20
    IP address: 0.0.0.0:0

    2 channels created:

      RTP Audio Inbound channel dump:
        Status: stopped
        Capability: undefined
        Local  RTP  = 0.0.0.0 : 49168
        Local  RTCP = 0.0.0.0 : 49169
        Remote RTP  = 213.85.168.52 : 23900
        Remote RTCP = 213.85.168.52 : 23901

      RTP Audio Outbound channel dump:
        Status: started
        Capability: Microsoft CCITT G.711 u-Law CODEC ( Payload Type = 0 )
        Local  RTP  = 0.0.0.0 : 49168
        Local  RTCP = 0.0.0.0 : 49169
        Remote RTP  = 213.85.168.52 : 23900
        Remote RTCP = 213.85.168.52 : 23901
        RFC2833 Disabled



17:43:30 SIP.Network DEBUG     
2008-02-12 14:43:30.687 UDP LOCAL->213.85.168.52:5060
ACK sip:84997414519@213.85.168.52:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 77.106.215.9;branch=z9hG4bKc0a8c1c80000019647b1b092000000f4000000cf;rport
From: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
To: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
Contact: <sip:84995024515@77.106.215.9>
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 1 ACK
Max-Forwards: 70
User-Agent: SJphone/1.65.377a (SJ Labs)
Content-Length: 0


17:43:33 SIPCall    DEBUG     SIP Call 401 (sip:84997414519@213.85.168.66;user=phone): Resume
17:43:33 SIP.Network DEBUG     
2008-02-12 14:43:33.546 UDP LOCAL->213.85.168.52:5060
INVITE sip:84997414519@213.85.168.52:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 77.106.215.9;branch=z9hG4bKc0a8c1c80000019847b1b095000047fe000000d0;rport
From: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
To: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
Contact: <sip:84995024515@77.106.215.9>
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: SJphone/1.65.377a (SJ Labs)
Content-Length: 271
Content-Type: application/sdp
Supported: replaces,norefersub,timer

v=0
o=- 3411816193 3411816196 IN IP4 77.106.215.9
s=SJphone
c=IN IP4 77.106.215.9
t=0 0
m=audio 49168 RTP/AVP 0 8 101
c=IN IP4 77.106.215.9
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=setup:active
a=sendrecv

17:43:33 SIP.Network DEBUG     
2008-02-12 14:43:33.703 UDP 213.85.168.52:5060->LOCAL
SIP/2.0 200 OK
Via: SIP/2.0/UDP 77.106.215.9;received=77.106.215.9;branch=z9hG4bKc0a8c1c80000019847b1b095000047f
e000000d0;rport=5060
From: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
To: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 2 INVITE
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,UPDATE,NOTIFY
Supported: 
Accept: multipart/mixed,application/media_control+xml,application/sdp
Contact: <sip:84997414519@213.85.168.52:5060;transport=udp>
Content-Type: application/sdp
Content-Length: 303

v=0
o=BroadWorks 107947880 3 IN IP4 213.85.168.52
s=-
c=IN IP4 213.85.168.52
t=0 0
m=audio 23900 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38

17:43:33 SIP.Parser NOTICE    Empty Supported header.
17:43:33 SIPSession INFO      Session Timer supported but not used in this session
17:43:33 SIPCall    INFO      SDP Processor dump:
SDP Header:
  Processor: "-", ID = 20
  Connection: 77.106.215.9
  Session:3411816193
  Version:3411816196

Open Internet mode: no

Media slot #0: [audio] -- [normal]
  Remote:
    RTP:  213.85.168.52 : 23900
    RTCP: 213.85.168.52 : 23901
    Capability: PCMU
    RFC2833: enabled [pt:101]

  Remote sdp:
    m=audio 23900 RTP/AVP 0 101
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=X-sqn:0
    a=X-cap: 1 audio RTP/AVP 100
    a=X-cpar: a=rtpmap:100 X-NSE/8000
    a=X-cpar: a=fmtp:100 200-202
    a=X-cap: 2 image udptl t38


17:43:33 SIPCall    INFO      Multimedia Session dump:
  Multimedia Session dump:
    Session ID: 20
    IP address: 0.0.0.0:0

    2 channels created:

      RTP Audio Inbound channel dump:
        Status: started
        Capability: undefined
        Local  RTP  = 0.0.0.0 : 49168
        Local  RTCP = 0.0.0.0 : 49169
        Remote RTP  = 213.85.168.52 : 23900
        Remote RTCP = 213.85.168.52 : 23901

      RTP Audio Outbound channel dump:
        Status: started
        Capability: Microsoft CCITT G.711 u-Law CODEC ( Payload Type = 0 )
        Local  RTP  = 0.0.0.0 : 49168
        Local  RTCP = 0.0.0.0 : 49169
        Remote RTP  = 213.85.168.52 : 23900
        Remote RTCP = 213.85.168.52 : 23901
        RFC2833 Enabled ( Payload Type = 101 )



17:43:33 SIP.Network DEBUG     
2008-02-12 14:43:33.703 UDP LOCAL->213.85.168.52:5060
ACK sip:84997414519@213.85.168.52:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 77.106.215.9;branch=z9hG4bKc0a8c1c80000019847b1b09500002983000000d3;rport
From: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
To: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
Contact: <sip:84995024515@77.106.215.9>
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 2 ACK
Max-Forwards: 70
User-Agent: SJphone/1.65.377a (SJ Labs)
Content-Length: 0


17:43:38 SIP.Registration INFO      NAT/Firewall binding refresh by dummy packet to UDP:213.85.168.52:5060
17:43:38 SIP.Network DEBUG     
2008-02-12 14:43:38.406 UDP LOCAL->213.85.168.52:5060


17:43:38 SIP.Registration INFO      Scheduling NAT/Firewall binding refresh for sip:84995024515@qwerty.cnt.ru after 20 

seconds
17:43:44 Power      INFO      Following power event retrieved:
wParam = 10( 0x0000000a ) - PBT_APMPOWERSTATUSCHANGE
lParam = 0( 0x00000000 )

17:43:52 SIP.Network DEBUG     
2008-02-12 14:43:52.890 UDP 213.85.168.52:5060->LOCAL
BYE sip:84995024515@77.106.215.9 SIP/2.0
Via: SIP/2.0/UDP 213.85.168.52:5060;branch=z9hG4bK83r3a33068k0jcoga441cd703eq81.1
From: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
To: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 118269777 BYE
Max-Forwards: 9
Content-Length: 0


17:43:52 SIP.Network DEBUG     
2008-02-12 14:43:52.906 UDP LOCAL->213.85.168.52:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 213.85.168.52:5060;branch=z9hG4bK83r3a33068k0jcoga441cd703eq81.1;received=213.85.168.52
From: <sip:84997414519@213.85.168.66;user=phone>;tag=2093201032-1202827382430-
To: "unknown" <sip:84995024515@qwerty.cnt.ru>;tag=653754d5d5
Contact: <sip:84995024515@77.106.215.9>
Call-ID: BW174302430120208-1131768162@213.85.168.66
CSeq: 118269777 BYE
Content-Length: 0
Server: SJphone/1.65.377a (SJ Labs)
Supported: replaces,norefersub,timer


17:43:53 App        INFO      Call 20 ended
17:43:58 SIP.Registration INFO      NAT/Firewall binding refresh by dummy packet to UDP:213.85.168.52:5060
17:43:58 SIP.Network DEBUG     
2008-02-12 14:43:58.406 UDP LOCAL->213.85.168.52:5060


17:43:58 SIP.Registration INFO      Scheduling NAT/Firewall binding refresh for sip:84995024515@qwerty.cnt.ru after 20 seconds

[ram_scan]

Ну собственно как и ожидалось. Голос и будет в одну сторону. Когда sjphone говорит 200, он заявляет удаленной стороне свой фейковый адрес c=IN IP4 192.168.193.200. Ремотная сторона естественно по этому адресу голос отправить не может, даже если ей очень хочется. Это или неправильно настроеный клиент, или глюк в клиенте (потому-что как я смотрю via он заявляет везде правильно). Я думаю что скорее всего неправильно что-то настроено или недонастроено.

[amper]

Странно, везде где можно руками прописан внешний IP. И вопрос все же - после HOLD'a все почему-то возвращается на круги своя...?

[ram_scan]

А после HOLD надо дамп сессии посмотреть и станет видно. На сипе процедура постановки на удержание и трансфера делается через весьма хитровыгнутую многоходовку, может там адрес нормальный и светится.

 

Но факт на рыло, в первом случае контакт анонсится фейковый. Вообще правильнее не прописывать "везде где только можно" и не портмапиться, а пользоваться при работе из-за NAT STUN серверами. Автоматика как правило если работает, то работает правильно.

[amper]

Так это полный дамп сессии. Звонок, поднятие трубки, ничего не слышно, удержание, полная слышимость, конец звонка.

 

А по какому принципу работает STUN сервер? Мне казалось, что он ничем кроме выяснения реального IP не занимается.

Если не делать port map, то входящие звонки тупо не проходят...

[ram_scan]

А вот после удержания в контакте уже появляется почему-то нормальный адрес.

 

STUN занимается не только выяснением реального IP. Он еще занимается определением типа NAT и особенностей его работы (там процедура состоит из нескольких шагов, происходит 4 коннекта на разные порты и в разные адреса. Сопоставляя потом полученые данные можно определить не только свой внешний адрес, но и логику проброса, и отнести NAT к одному из известных четырех типов, а также скорректировать логику работы клиента под это дело.

 

Самый геморрой - это symmetric nat. Он через STUN не работает, потому-что дырка открывается не в направлении исходный_хост:все_порты<->NAT<->хост:порт, а исходный_хост:порт<->NAT<->хост:порт. Именно такой механизм по дефолту реализовн в linux. Там STUN пользоваться бесполезно (именно об этом я говорил когда заводил речь о том что если автоматика работает вообще) потому-что при коннекте на другой сервер и другой порт откроется совершенно другая "дырка" с заранее неясными свойствами. Есть в природе драфт Symmetric NAT Traversal using STUN servers, но там по его рекомендациям надо очень активно играть с сип таймаутами и знать механизм аллочения порта при траверсале без гарантированого результата.

 

Я могу сказать что у меня дома сейчас прекрасно работает linksys pap2t за NAT построеном на базе хуавеевского ADSL модема u880t, причем безо всяких портмапов и полностью автоматически, просто глядя в STUN сервер. И входящие и исходящие есть, и голос в обе стороны.

Edited February 17, 2008 by ram_scan

[amper]

Разобрался! Ох уж и намудрили они с этим NAT'ом. Вообще, насколько я понял, NAT в классическом его понимании китайцами и фактическом воплощении в нашей действительности - это скорее всего PAT и он всегда будет SYMMETRICAL, ибо внешний IP только один, а внутри клиентов может быть много.

 

В итоге, получаем такую картину - исходящий пакет ушел с внутреннего порта 26020, о чем SIP девайс честно написал в сервисных пакетах, роутер его "оттранслировал" и наружу пакет вылез через порт 14385... ну и соответственно, при получении пакета удаленной стороной, она нифига не смотрит в ip датаграмму, а читает сервисную инфу, где указан порт 26020, и наивно пытается долбиться на него!

 

Проблему решил благодаря умному роутеру, в котором можно отключить "трансляцию" определенных портов, теперь все работает вообще без пробросов портов, чисто через STUN, но думаю UDP 5060-5070 все же стоит пробросить, дабы гарантированно не прозевать входящий звонок.

 

Только теперь уже нет 100% уверенности в том, что если какой-то другой IP из внутренней сети захочет вылезти наружу, у него это получится в полном объеме (ибо source порт может быть занят другим клиентом).

 

Кстати, насколько прожорлив NAT Keep Alive Packet, отсылаемый каждую минуту?

 

P.S. Осталось не решенной проблема запрета изменения адреса через IVR.

Edited February 21, 2008 by amper

[amper]

Теперь осталось разобраться с хождением факсов.

 

Напрямую SIPNET<->SIPNET все ходит нормально, а вот в вариациях PSTN<->SIPNET, SIPNET<->BAZA - как-то неуверенно... Причем судя по логам, устройства не могут между собой договориться о кодеке.

 

На SPA2102 стоит FAX Passthru Codec: G711u, Preferred Codec: G711u, FAX CED Detect Enable, FAX CNG Detect Enable, FAX Codec Symmetric, FAX Passthru Method: NSE, FAX Process NSE: Yes, FAX Disable ECAN: Yes, FAX Enable T38: Yes, FAX Tone Detect Mode: Caller&Callee

[ram_scan]

Неуверенное хождение факсов - обычное дело. Процент прохождения факсов в 80% считается уже очень хорошим, можно говорить что "факсы ходют".

 

Причин "плохого" хождения факсов в данном случае может быть три.

 

1) Корявые факсовые аппараты (попадаются и такие из самых китаезных, способы проверки и решения проблемы очевидны)

2) нехватка полосы пропускания канала (t38 жрет полосы шире чем 711 кодек)

3) Действительно не могут договориться на t38.

 

Кроме того непонтна схема сети, и какое голосовое ПО используется (если используется).

 

Так что схему, и дамп факсовой сессии в студию (желательно как удачной так и неудачной). Будем посмотреть.

 

PS: fax passthrough codec имеет смысл заменить на G711a. G711u в расее на цифровых сетях не применяется, можно в будущем огрести граблей с тем же сипнетом если нарваться на терминатора у которого этот кодек отключен по причине "ненадобности" и нет поддержки t38. Вот там и на сипнете с факсами тогда выйдет полная шляпа.

Edited February 22, 2008 by ram_scan

[rover-lt]

Опытным путем пришел к таким значениям:

Dial Tone: 420@-16;10(*/0/1)

Busy Tone: 420@-16,10@-16;10(.5/.5/1+3)

Ring Back Tone: 420@-16,@-10;*(2/4/1+1)

 

Проблема с отбоем решается установкой параметра Reorder Delay в 0.

 

Вот только не очень пойму, как работает Т.38? Если к SPA подключен обычный аналоговый факс, процесс передачи факса начинается, как правило, с телефонного звонка и разговора, после чего обе стороны стартуют. Вот тут по идее девайс должен автоматом распознать факс и сменить кодек на Т.38?

 

И по прежнему актуален вопрос установки пароля\полного отключения IVR.

Tone

Frequency (Hz)

Cadence (seconds)

 

Dial

425

Continuous.

 

Alternate Dial Tone

425

Continuous.

 

Secondary Dial Tone

425

Continuous.

 

Busy Tone

425

(0.35/0.35) on/off.

 

Fast Busy Tone

425

(0.2/0.2) on/off.

 

Intercept Busy Tone

425

(0.35/0.35) on/off.

 

Ring Tone

425

(1.0/4.0) on/off.

 

Call Waiting Tone

425

(0.2/5.0) on/off.

 

NU

425

Continuous.

 

 

[amper]

Что-то с удачными сессиями стало совсем туго, вот логи неудачных, получены через AXON PBX (Схема такая: с одной стороны VentaFAX (USR Sportster 56K) <-> SPA <-> AXON PBX <-> NAT <-> SIPNET\BAZA, с другой стороны PANASONIC KX-FP105 <-> ZYXEL 2602 <-> PSTN\SIPNET).

 

Что я вижу по логам SPA - когда на нем выключено распознавание факсов, то разрыв связи происходит на первых секундах коннекта факсов, по причине "Reinvite failed" (непонятно, кем инициируется этот reinvite при звонке на PSTN). Если на SPA включено распознавание факсов, то при начале коннекта факсов он показывает "Call 1 FAX: YES", но в значениях "Call 1 Encoder" и "Decoder" - стоят "?", т.е. он не может договориться о кодеке.

Пробовал 711u\a.

 

P.S. Установил такой Dial Plan:

 

([1-79]xxxxxx|8,[2-9]xxxxxxxxx|8,10XXXXXXXXXXX.)

 

Первая запись - для звонков внутри SIP, вторая - межгород, третья - международные звонки, а там, как я понимаю, длина номера не фиксирована, соотв. возможность набора доп. цифр добавляем "точкой". "Запятая" - для получения привычного гудка после 8ки.

 

После набора 810, сразу же получаю отбой (в логах вижу, что после "Report digit 0" сразу же идет попытка вызова "Calling: 810@192...." и соотв. отшивается PBX'ом) - почему?

Edited February 25, 2008 by amper

[ram_scan]

Посмотрел логи с включеным t38. Все три стороны (те что видно из представленного лога) переходят на t38 честно. То есть стартует голосовая транзитная сессия, потом персонажем 213.85.x.x предлагается перейти на t.38 и все стороны с этой инициативой соглашаются, то есть дается и 200 с параметрами сессии, и ACK на эти 200.

 

То есть из логов граблей по сигнализации по крайней мере не видно. Отсюдова может следовать вывод, что неработоспособность t38 связана 1) с некорректным процессингом какой-то стороной rtp t.38 трафика или 2) есть нечто что живет за 213.85.x.x и что там происходит - не видно. Судя по всему имеет место какая-то несовместимость именно по t.38, то есть сессия стартует правильно, и судя по логам через 20 с копейками секунд даже завершается правильно. Это все что можно увидеть из лога с поддержкой t.38.

 

Логи без поддержки t.38 смотреть особливого смысла нет, я поленился. Reinvite failed там может появляться когда одна сторона предлагает t.38, а вторая ей отказывает из-за оключеной или отсутствуюшей его поддержки, это нормальное явление, так и должно быть.

 

Единственное - разрыва по reinvite failed происходить НЕ ДОЛЖНО, в пределах установленной сессии неудачный реинвайт ни в коем случае не должен приводить к обрыву сессии, он должен игнорироваться. Кто рвет соединение в данном случае надо разбираться, кто-то неправ однозначно.

 

По поводу "попытки сразу звонить на 810" там где-то в линксисе есть так называемый emergency number, мож оно срабатывает, я им не баловался. Диалплан в первом приближении написан верно.

 

PS: Виноват в разрыве сессии без поддержки t.38 персонаж Axon PBX. Он получает от SPA ошибку 488, что означает что SPA не поддерживает переход на t.38, Axon должен был зафорвардить этот код ошибки, и по стандарту сессия должна была остаться в том же состоянии как будто никакого реинваайта не происходило. А Axon отвечает пассажиру по адресу 213.85.x.x кодом 408, что есть неправильно, и ведет к рассыпанию соединения. Это явная и 100%-ная бага Axon.

 

PPS: к сожалению вся "дешевая, эффективная и качественная IP телефония которая решит все проблемы бизнеса" постоянно спотыкается об такое говно... Совместимость оборудования - ниже плинтуса.

Edited February 25, 2008 by ram_scan

[amper]

Надо прекращать работать по ночам, определенно...

Dial plan не работал из-за того, что вместо строчных "х", использовались прописные "Х" :-D

Кстати, посмотрел emergency numbers - там пусто, почитал описание и не очень понял смысл:

"Comma separated list of emergency number patterns. If outbound call matches one of the pattern, SPA will disable hook flash event handling." - т.е. если вызыватся номер, подпадающий под шаблон, то отключается поддержка "flash" (удержания звонка)? Нафиг?

 

С Т.38 все намного плачевнее, ибо узлов, поддерживающих Т.38 в том же SIPNET'e - единицы. BAZA, по описаниям, вообще его не поддерживает, хотя инициирует переход на T.38 именно удаленный узел (т.е. 213.85)!

 

Может как-то поиграться с настройками:

FAX CED Detect Enable: yes\no

FAX CNG Detect Enable: yes\no

FAX Passthru Codec: G711u\G711a

FAX Codec Symmetric: yes\no

FAX Passthru Method: None\NSE\ReINVITE

FAX Process NSE: yes\no

FAX Enable T38: yes\no

FAX T38 Redundancy: 0\1\2\3

FAX Tone Detect Mode: caller or callee\caller only\callee only

 

Например, не очень понятно, что означают FAX Codec Symmetric, FAX Process NSE и FAX T38 Redundancy?

 

P.S. Кстати, столкнулся еще в одним глюком, при вызове откуда то появляется 491 Request Pending, хотя никаких активных звонков по этому номеру нет - опять глюк AXON'a?

Edited February 25, 2008 by amper

[ram_scan]

Судя по тому что Axon путается при реинвайте на t38 припарки не помогут. Крыша у него так будет ехать при ремнвайте на любой неподдерживаемый кодек. То есть про хождение факсов по clear channel можно забыть. Единственная настройка которая может влиять на хождение факсов по t.38 - это redudancy. Поскольку факсовый протокол симплексный, то один потеряный пакет может привести к обрыву сессии, это не голос, где щелкнуло-квакнуло и хрен с ним. Параметр redudancy указывает сколько раз нужно продублировать пакет для более-менее приемлимого приема на тот край если в канале потери. Играть можно и нужно, но осторожно, потому-что кривых девайсов и софта море, некоторые в упор не понимают некоторые значения redudancy и давятся лишними пакетами, или считают что должно приходить обязательно не меньше какого-то определенного количества.

 

Ну и должно быть ессно включено fax enable t38 и можно поиграть с fax tone detect mode на тот случай если реинвайт на t38 правильно проходит только в одну сторону (опять-же из-за кривости софта или оборудования)

Edited February 25, 2008 by ram_scan

[amper]

Так ни к чему и не пришел, с redudancy игрался, а Т38 упорно не хочет ходить, судя по логам нет сигнала. Со стороны SIPNET'a шлюз, к которому производится коннект заявлен и подтвержден как адекватно пропускающий G711 и T38.

 

1) Лог снятый с SPA2102 при коннекте через AXON далее к SIPNET:

 

2) Лог снятый с SPA2102 при коннекте напрямую к SIPNET:

 

3) Лог снятый с SPA2102 при коннекте напрямую к BAZA:

Edited February 27, 2008 by amper