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

Joshua C. Colp jcolp at digium.com
Fri Aug 9 14:45:51 CDT 2019


On Fri, Aug 9, 2019, at 4:16 PM, Michael Maier wrote:
> Am 09.08.19 um 20:09 schrieb Joshua C. Colp:
> > On Fri, Aug 9, 2019, at 2:58 PM, Michael Maier wrote:
> > 
> > <snip>
> > 
> >>
> >> 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?
> > 
> > I don't really understand your question. 
> 
> What I'm trying to say, is, that during the call, consisting of an 
> INVITE, INVITE + AUTH (after proxy auth request of ISP), ReInvite 1 
> from ISP 
> and ReInvite 2 from ISP, asterisk encounters a session problem, because 
> it reuses the old session data of the beginning for the ReInvites 
> instead of continuously continuing with the session data reached after 
> the INVITE + AUTH and so on.
> 
> > I don't think the patch is the true fix, it's just a convenient place to increment it.
> 
> That's true - but there seems to be a session issue because there is 
> always the same SDP version as base - and not the previously increased 
> one 
> (besides between INVITE and INVITE + AUTH)
> 
> Let me show it on a table
> 
> 		real SDP			expected SDP
> Request		startversion with patch		startversion with patch
> INV		1				1
> INV + AUTH	2				2
> ReInv 1 OK	1				3
> ReInv 2 OK	1				4
> 

I understand there's a problem, and the issue itself was accepted and is in queue.

-- 
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org



More information about the asterisk-dev mailing list