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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
