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

Sat Sep 2 02:38:08 CDT 2017

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

Frederic Steinfels updated ASTERISK-27239:
------------------------------------------

    Description: 
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 P?4_?e?MRS_?NNI?2 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.

  was:
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.