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

Tue Sep 5 18:35:07 CDT 2017

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rusty Newton updated ASTERISK-27239:
------------------------------------

    Assignee: Frederic Steinfels  (was: Unassigned)
      Status: Waiting for Feedback  (was: Triage)

Thanks for formatting and providing the additional information.

Can you revert to a GIT commit previous to bc51d4324a69a0b8ee4a3be208b91bb2081124ff and report back if the issue no longer occurs? 

That is, use anything before that commit.

I'm thinking the root problem here is the same as on ASTERISK-27250 and they are reporting that that commit caused the regression. Possibly also the same as ASTERISK-27223. I may be off, but this will help narrow it down.

> 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: Frederic Steinfels
>            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)