[asterisk-dev] Asterisk 16 / pjsip: actual SDP handling in case of late offer during outbound call seems to break call

[Michael Maier]

On 17.06.19 at 21:11 Michael Maier wrote:
> On 17.06.19 at 20:15 Joshua C. Colp wrote:
>> On Mon, Jun 17, 2019, at 3:10 PM, Michael Maier wrote:
>>> Hello!
>>>
>>> I'm facing a problem on an outbound call which receives a reInvite w/o 
>>> SDP (late / delayed offer technique) from ISP. The ISP won't provide
>>> any SDP in the following received ACK and the call is broken therefore 
>>> afterwards because no more media is sent after this reInvite.
>>>
>>>
>>> Detail:
>>>
>>> - ISP sends ReInvite w/o SDP
>>> - Asterisk sends 200 OK containing the SDP, received by the initial 200 
>>> OK from the ISP before
>>>   (which is a subset of the defined allowed media for this trunk).
>>>   The <sess-version> in the SDP of the 200 OK as answer to the reInvite 
>>> is the same as the one of
>>>   the initial INVITE though the SDP is different. Shouldn't 
>>> <sess-version> be increased if SDP
>>>   is changed changed?
>>> - ISP sends an ACK - but w/o SDP -> Call is dead from now on.
>>
>> Yes, if the SDP is changed then the session version should be incremented. If this is not done then this is likely a bug in pjmedia-sdp (I don't believe we deal with the session version, it's down in the PJSIP SDP side). You can file an issue[1] with the details.
> 
> https://issues.asterisk.org/jira/browse/ASTERISK-28452

I think I probably realized now the real problem of the wrong SDP session version: Based on this patch

diff -urN asterisk-16.3.0.orig/res/res_pjsip/pjsip_message_filter.c asterisk-16.3.0/res/res_pjsip/pjsip_message_filter.c
--- asterisk-16.3.0.orig/res/res_pjsip/pjsip_message_filter.c   2019-04-04 16:49:57.000000000 +0200
+++ asterisk-16.3.0/res/res_pjsip/pjsip_message_filter.c        2019-06-18 14:46:57.784000000 +0200
@@ -341,6 +341,10 @@
                        }
                }

+               /* set new sdp version */
+               ast_debug(5, "increment SDP version, starting from %x\n",sdp->origin.version);
+               sdp->origin.version+=1;
+
                pjsip_tx_data_invalidate_msg(tdata);
        }

---------------------------------------------------------------------------------------------------------------------------

I detected, that the starting point is wrong during the following call to the provider:


INVITE        / SDP session version starts at 0x1c91867
INVITE + AUTH / SDP session version starts at 0x1C91868 (this is ok)

ReInvite 1 from Provider
OK ReInvite  / SDP session version starts at 0x1C91867 (this is not ok - should start at 0x1C91869 and not from beginning)

ReInvite 2 from Provider
OK ReInvite  / SDP session version starts at 0x1C91867 (this is not ok - should start at 0x1C91870 and not from beginning)

Seems, that asterisk uses for the 200 OKs the initial session, starting at the first INVITE instead of using the session data based on the INVITE + AUTH.
Or is there my patch broken?


Thanks
Michael