Подключили недавно SIP линии от Киевстар. Звонки ходят, но при вызове некоторых номеров наблюдается странное поведение *.
При нормальном звонке, на мой INVITE Киевстар отвечает 100 Trying, потом 183 Session Progress и все отлично. Но при звонке на некоторые номера на мой INVITE Киевстар отвечает 100 Trying, потом 180 Ringing, и после этого * переключает звонок на удержание, вкючает MOH, и вообще делает вид что он не приделах.
| Код: |
| --- Audio is at 12032 Adding codec 100004 (alaw) to SDP Adding non-codec 0x1 (telephone-event) to SDP Reliably Transmitting (NAT) to 188.163.212.3:5060: INVITE sip:0xxxxxxxxxx@voip.kyivstar.ua SIP/2.0 Via: SIP/2.0/UDP 10.5.3.3:5060;branch=z9hG4bK7560f7bb;rport Max-Forwards: 70 From: ;tag=as71cde03c To: Contact: Call-ID: 383bef6c69692af4336b0a983673fc69@voip.kyivstar.ua CSeq: 103 INVITE User-Agent: Linksys/SPA8000-5.1.10 Authorization: Digest username="yyyyyyyy", realm="44200", algorithm=MD5, uri="sip:0xxxxxxxxxx@voip.kyivstar.ua", nonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxx", response="xxxxxxxxxxxxxxxxxxxxxxxx", opaque="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", qop=auth, cnonce="51cd4fe7", nc=00000001 Date: Wed, 06 Jul 2016 15:18:05 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 228 v=0 o=root 917367806 917367807 IN IP4 10.5.3.3 s=Linksys SPA8000-5.1.10 c=IN IP4 10.5.3.3 t=0 0 m=audio 12032 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv --- SIP/2.0 100 Trying Via: SIP/2.0/UDP xx.xx.xx.xx;received=xx.xx.xx.xx;branch=z9hG4bK7560f7bb;rport=5060 From: ;tag=as71cde03c To: Call-ID: 383bef6c69692af4336b0a983673fc69@voip.kyivstar.ua CSeq: 103 INVITE --- (6 headers 0 lines) --- SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.5.3.3;received=xx.xx.xx.xx;branch=z9hG4bK7560f7bb;rport=5060 From: ;tag=as71cde03c To: ;tag=SD7op5499-4ae678e1bh Call-ID: 383bef6c69692af4336b0a983673fc69@voip.kyivstar.ua CSeq: 103 INVITE Allow: INVITE,ACK,CANCEL,INFO,PRACK,UPDATE,OPTIONS,REGISTER,REFER,SUBSCRIBE,PUBLISH Contact: P-Asserted-Identity: "0xxxxxxxxxx" Content-Length: 219 Content-Type: application/sdp Content-Disposition: session;handling=required v=0 o=- 4516122 3648217 IN IP4 188.163.212.3 s=- c=IN IP4 188.163.212.3 b=AS:64 t=0 0 m=audio 32066 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendonly --- (12 headers 12 lines) --- list_route: hop: Found RTP audio format 8 Found RTP audio format 101 Found audio description format PCMA for ID 8 Found audio description format telephone-event for ID 101 Capabilities: us - (alaw), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw) Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|) Peer audio RTP is at port 188.163.212.3:32066 -- SIP/yyyyyyyy-000000c3 is ringing -- Call on SIP/yyyyyyyy-000000c3 placed on hold -- Started music on hold, class 'default', on SIP/1103-000000c1 -- SIP/yyyyyyyy-000000c3 is making progress passing it to SIP/1103-000000c1 -- Stopped music on hold on SIP/1103-000000c1 Scheduling destruction of SIP dialog '383bef6c69692af4336b0a983673fc69@voip.kyivstar.ua' in 6400 ms (Method: INVITE) Reliably Transmitting (NAT) to 188.163.212.3:5060: CANCEL sip:0xxxxxxxxxx@voip.kyivstar.ua SIP/2.0 Via: SIP/2.0/UDP 10.5.3.3:5060;branch=z9hG4bK7560f7bb;rport Max-Forwards: 70 From: ;tag=as71cde03c To: Call-ID: 383bef6c69692af4336b0a983673fc69@voip.kyivstar.ua CSeq: 103 CANCEL User-Agent: Linksys/SPA8000-5.1.10 Content-Length: 0 --- Scheduling destruction of SIP dialog '383bef6c69692af4336b0a983673fc69@voip.kyivstar.ua' in 6400 ms (Method: INVITE) == Spawn extension (macro-dial-out-ks, s, 7) exited non-zero on 'SIP/1103-000000c1' in macro 'dial-out-ks' == Spawn extension (phones, 7901384, 4) exited non-zero on 'SIP/1103-000000c1' SIP/2.0 200 OK Via: SIP/2.0/UDP xx.xx.xx.xx;received=xx.xx.xx.xx;branch=z9hG4bK7560f7bb;rport=5060 From: ;tag=as71cde03c To: ;tag=SD7op5499-4ae678e1bh Call-ID: 383bef6c69692af4336b0a983673fc69@voip.kyivstar.ua CSeq: 103 CANCEL --- (6 headers 0 lines) --- SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP 10.5.3.3;received=xx.xx.xx.xx;branch=z9hG4bK7560f7bb;rport=5060 From: ;tag=as71cde03c To: ;tag=SD7op5499-4ae678e1bh Call-ID: 383bef6c69692af4336b0a983673fc69@voip.kyivstar.ua CSeq: 103 INVITE Reason: Q.850;cause=16;text="Normal call clearing" Content-Length: 0 --- (8 headers 0 lines) --- Transmitting (NAT) to 188.163.212.3:5060: ACK sip:0xxxxxxxxxx@188.163.212.3:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.5.3.3:5060;branch=z9hG4bK7560f7bb;rport Max-Forwards: 70 From: ;tag=as71cde03c To: ;tag=SD7op5499-4ae678e1bh Contact: Call-ID: 383bef6c69692af4336b0a983673fc69@voip.kyivstar.ua CSeq: 103 ACK User-Agent: Linksys/SPA8000-5.1.10 Content-Length: 0 --- |
т.е. астериск при получении 180 Ringing делает
| Код: |
| -- SIP/yyyyyyyy-000000c3 is ringing -- Call on SIP/yyyyyyyy-000000c3 placed on hold -- Started music on hold, class 'default', on SIP/1103-000000c1 -- SIP/yyyyyyyy-000000c3 is making progress passing it to SIP/1103-000000c1 |
подозреваю что причина в атрибуте a=sendonly в пакете с "180 Ringing", так как при нормальном звонке в пакете с "183 Session Progress" установлен a=sendrecv
Кто-нибудь сталкивался с таким поведением *? Это нормально?
то что выложили - примерно половина от того что нужно увидать
снимайте оба плеча
_________________
платный суппорт по мере возможностей
| awsswa @ Пт Июл 08, 2016 08:27 писал(а): |
| снимите нормальный pcap то что выложили - примерно половина от того что нужно увидать снимайте оба плеча |
Во вложении дамп успешного звонка на моей стороне.
Т.е. когда звонок на удержании, с той стороны все-таки могут снять трубку, и тогда КС присылает мне инвайт с a=sendrecv. В этом случае звонок снимается с удержания и можно поговорить.
Added after 31 minutes:
Пообщался с Киевстаром, они говорят что для транзитных звонков они просто пересылают статус ответа от АТС. т.е. ответ 180 или 183 зависит не от них.
откуда берется a=sendonly они не смогли объяснить, но * реагирует на него как и положено по стандарту - переводит звонок на удержание.
Можно ли как-то указать * от кого следует воспринимать a=sendonly, а от кого игнорировать?