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

Tue Sep 19 14:52:09 CDT 2017

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

Rusty Newton commented on ASTERISK-27239:
-----------------------------------------

This is the change that may cause the problem: https://gerrit.asterisk.org/#/q/Ib1647f6902a0843e8c435946f831c2159e8d1d51

>From that search result page you can navigate to the review for the appropriate branch. Then you should spot the commit ID number on that individual review page.

Once you have that commit ID, go to your local git directory for that branch and then look at the git log

{noformat}
git log --pretty=fuller
{noformat}

Find the commit with that commit ID, then find the commit ID just previous to that commit (look at the commit dates) in time.

Once you have the commit ID of the commit previous to the potential regression, go back to your git directory for the branch and do
{noformat}
git checkout <commit ID>
{noformat}

Then you can build and install from there.

For example, the commit ID for 13, shown on the review for 13 is "996a4791ff123e80d71d44cb0fd13bb201d197b1"

So if I search the git log in 13 for that, then I find that the previous commit is "812f5b51cb56a36668decc6dfc83adeca185429e"

In my local clone of branch 13 I would then run
{noformat}
git checkout 812f5b51cb56a36668decc6dfc83adeca185429e
{noformat}
Then I would build and install from there.

Let me know if that makes sense.

> 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)