[asterisk-bugs] [JIRA] (ASTERISK-27239) PJSIP losing RTP connection (no more audio)

Wed Oct 25 17:45:22 CDT 2017

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=239661#comment-239661 ] 

Kevin Harwell commented on ASTERISK-27239:
------------------------------------------

{quote}
On the SIP/RTP please provide an example (command line tool, settings) how to capture the packets in the way you want them captured
{quote}
If you want to use tcpdump something like the following should get you most of the way:
{noformat}
tcpdump -i <interface> -w <output file name>
{noformat}
I don't use tcpdump enough to know what settings to use for filters and such. The man page however lists the various options you'll need if you go that route.

I'm also not familiar with the wireshark command line interface, but it too has a man page that lists the options for reference if you'd rather use that.

If you use the wireshark UI, select the interface you want to listen on, and then start listening. You can then filter packets after the fact if needed. Again using the UI.

{quote}
You already have a full debug log. However I can do more logging for you with the current version.
{quote}
Yes, please provide a full log of the scenario with debugging turned up and with SIP logging ("pjsip set logger on") that aligns (is captured at the same time) with the packet capture.

> PJSIP losing RTP connection (no more audio)
> -------------------------------------------
>
>                 Key: ASTERISK-27239
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27239
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 13.17.1, 14.6.1, 15.0.0-beta1
>         Environment: independent
>            Reporter: Frederic Steinfels
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: log.txt
>
>
> 1. The specific steps or actions you took that caused you to encounter the problem.
> Placing an outbound call
> 2. The behavior you expected and the location of documentation that led you to that expectation.
> I expect there to be audio when placing a call.
> 3. The behavior you actually encountered.
> There is no audio in case of a codec change. Details below.
> Using PJSIP together with the biggest telecom provider in Switzerland, Swisscom, in conjunction with there "Smart Business Connect Trunk" solution, there is a scenario resulting in losing the audio connection.
> First, the call is initiated and RTP packets are exchanged (code alaw). After a few seconds, the call is diverted for some reason and Swisscom is changing to g722. At this point, PJSIP or asterisk will not reinitiate the RTP connection as it is supposed to.
> If a call is picked up normally, swisscom knows the correct codec from the beginning so there is no codec change after ringing. That works perfectly. However if the call is diverted to an answering machine or another party that requires a different codec, the problem occurs. When I am talking about diversion, I mean diversion + call pickup using a different codec.
> I have complained at Swisscom, they are telling me its my (asterisks) fault. Their response was (translated to english):
> In the worst case, BTN is starting 17:13: RTP. As soon as the ringing is sent, the MS is turned on and is playing the ringing. As soon as the BTN is taking the call, the P4_eMRS_NNI2 is starting the RTP towards the ATN and is reinitiating it. However, the ATN is only starting the RTP but not reinitiating it.
> ATN propably means Party A or calling party, ie me.
> BTN probably means Party B or called party.
> If there is a diversion without a change of codec, the audio is not lost.
> If the call is initiated with g722 from the beginning, the audio is available.
> I can not force Swisscom to only use g722 to avoid the problem. If I do so, the call can not be initiated.
> If you want to try this, please PM me to so I can give you a phone number that behaves this way.
> Here are some logs:
> {noformat}
>     -- Executing [s at outboundfst:14] Dial("SCCP/Frederic-000006DE", "PJSIP/xxxx at swisscomTestTrunk,180,gIT") in new stack
>     -- Called PJSIP/xxxx at swisscomTestTrunk
>     -- Connected line update to SCCP/Frederic-000006DE prevented.
>     -- PJSIP/swisscomTestTrunk-000003ea is making progress passing it to SCCP/Frederic-000006DE
>   == Using SCCP RTP TOS bits 184
>   == Using SCCP RTP CoS mark 6
>        > 0x7f2150013300 -- Probation passed - setting RTP source address to 192.168.99.166:27936
> {noformat}
> RTP Packets are flowing (192.168.99.19 is swisscom): 
> {noformat}
> Sent RTP packet to      192.168.99.19:24496 (type 09, seq 006312, ts 1155988568, len 000160)
> Got  RTP packet from    192.168.99.19:24496 (type 09, seq 028521, ts 3235640619, len 000160)
> {noformat}
> at the time of the diversion, this happens:
> {noformat}
>    -- PJSIP/swisscomTestTrunk-000003ea requested media update control 26, passing it to SCCP/Frederic-000006DE
>     -- PJSIP/swisscomTestTrunk-000003ea answered SCCP/Frederic-000006DE
>     -- SEP001F9EAC4817: (sccp_pbx_answer) Outgoing call SCCP/Frederic-000006DE has been answered by remote party
>     -- Channel PJSIP/swisscomTestTrunk-000003ea joined 'simple_bridge' basic-bridge <64e1db67-f435-4393-a360-05e59ef59887>
>     -- Channel SCCP/Frederic-000006DE joined 'simple_bridge' basic-bridge <64e1db67-f435-4393-a360-05e59ef59887>
> {noformat}
> From this point, there are no further "Got  RTP packet from" messages from the corresponding IP.
> It does not matter, if the call is made from a PJSIP or SCCP device (tried both).
> The corresponding SIP headers in case of the diversion and codec change:
> {noformat}
>     -- PJSIP/swisscomTestTrunk-0000000d requested media update control 26, passing it to SCCP/Frederic-0000001E
> <--- Received SIP response (1022 bytes) from UDP:192.168.99.19:5060 --->
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 192.168.99.10:5060;rport;branch=z9hG4bKPjf91cf3c1-f62b-44bb-b336-c7556481f67f
> From: "xxx.ch" <sip:+41435440808 at 192.168.99.10>;tag=db836e4b-0a44-4a95-ad4e-93a8d885393c
> To: <sip:xxxx at 192.168.99.19>;tag=D590A070-1660
> Date: Tue, 08 Aug 2017 10:04:31 GMT
> Call-ID: 329cc7ac-938a-40a5-87d4-17733d86220a
> CSeq: 12944 INVITE
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
> Allow-Events: telephone-event
> Contact: <sip:xxxx at 192.168.99.19:5060>
> Supported: replaces
> Supported: sdp-anat
> Server: Cisco-SIPGateway/IOS-15.5.2.16.T
> Supported: timer
> Content-Type: application/sdp
> Content-Disposition: session;handling=required
> Content-Length: 271
> v=0
> o=CiscoSystemsSIP-GW-UserAgent 1121 8511 IN IP4 192.168.99.19
> s=SIP Call
> c=IN IP4 192.168.99.19
> t=0 0
> m=audio 21872 RTP/AVP 9 101
> c=IN IP4 192.168.99.19
> a=rtpmap:9 G722/8000
> a=fmtp:9 bitrate=64
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> <--- Transmitting SIP request (428 bytes) to UDP:192.168.99.19:5060 --->
> ACK sip:xxxx at 192.168.99.19:5060 SIP/2.0
> Via: SIP/2.0/UDP 192.168.99.10:5060;rport;branch=z9hG4bKPj3335f178-728b-47a0-b3ae-a187da37fb92
> From: "xxx.ch" <sip:+41435440808 at 192.168.99.10>;tag=db836e4b-0a44-4a95-ad4e-93a8d885393c
> To: <sip:xxxx at 192.168.99.19>;tag=D590A070-1660
> Call-ID: 329cc7ac-938a-40a5-87d4-17733d86220a
> CSeq: 12944 ACK
> Max-Forwards: 70
> User-Agent: Asterisk PBX
> Content-Length:  0
> {noformat}
> The difference is:
> g722:
> a=rtpmap:9 G722/8000
> a=fmtp:9 bitrate=64
> not g722:
> a=rtpmap:8 PCMA/8000
> As I said before, if the codec remains g711, no problem. If changed to g722, the call will fail.

--
This message was sent by Atlassian JIRA
(v6.2#6252)