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 -- _____________________________________________________________________ -- 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
