Hi Duane,

I uploaded this patch on the SVN trunk, but I will wait a bit before backporting - just to see if there are any side effects - what I'm concerned a bit is the handling of UPDATE request in early state. Any idea if you could test this case also ? (UPDATES from callee side of b2b, while still in early)

Regards,
Bogdan

On 03/28/2012 08:30 PM, [email protected] wrote:
SUCCESS!!! You rock. Thanks

When will this go into affect on the trunk?

#
U 2012/03/28 12:21:21.571998 64.136.174.30:5060 -> 173.XXX.XXX.88:5060
UPDATE sip:173.XXX.XXX.88:5060 SIP/2.0.
Via: SIP/2.0/UDP 64.136.174.30:5060;branch=z9hG4bK2sansay155968379rdb15277. To: "9016XX6XX4" <sip:[email protected]>;tag=38c6d6bcece65cb87e503e966caf6840-231e.
From: sip:[email protected]:5060;tag=sansay155968379rdb15277.
Call-ID: B2B.164.6603158.
CSeq: 2 UPDATE.
Contact: <sip:[email protected]:5060>.
Max-Forwards: 70.
Content-Length: 0.
.

#
U 2012/03/28 12:21:21.573404 173.XXX.XXX.88:5060 -> 50.XXX.XXX.156:5060
UPDATE sip:[email protected]:17419 SIP/2.0.
Via: SIP/2.0/UDP 173.XXX.XXX.88;branch=z9hG4bKb41c.fe117284.0.
To: "9016XX6XX4" <sip:[email protected]>;tag=e299814d38cd4d34a6a1ba150aaa8da7.
From: <sip:[email protected]>;tag=B2B.502.132.
CSeq: 2 UPDATE.
Call-ID: a0dd9a689d4848c0856f67c5ad13abcf.
Route: <sip:50.XXX.XXX.156;lr;ftag=e299814d38cd4d34a6a1ba150aaa8da7;nat=yes;did=711.16170c36>.
Content-Length: 0.
User-Agent: OpenSIPS (1.8.0-dev0-notls (x86_64/linux)).
Max-Forwards: 70.
Contact: <sip:173.XXX.XXX.88:5060>.
.

#
U 2012/03/28 12:21:21.675141 50.XXX.XXX.156:5060 -> 173.XXX.XXX.88:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 173.XXX.XXX.88;branch=z9hG4bKb41c.fe117284.0.
Record-Route: <sip:50.XXX.XXX.156;lr;ftag=B2B.502.132>.
Call-ID: a0dd9a689d4848c0856f67c5ad13abcf.
From: <sip:[email protected]>;tag=B2B.502.132.
To: "9016XX6XX4" <sip:[email protected]>;tag=e299814d38cd4d34a6a1ba150aaa8da7.
CSeq: 2 UPDATE.
Contact: <sip:[email protected]:63259>.
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER.
Supported: 100rel, norefersub.
Server: Blink 0.2.7 (Windows).
Content-Length: 0.
.

#
U 2012/03/28 12:21:21.676451 173.XXX.XXX.88:5060 -> 64.136.174.30:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 64.136.174.30:5060;branch=z9hG4bK2sansay155968379rdb15277. To: "9016XX6XX4" <sip:[email protected]>;tag=38c6d6bcece65cb87e503e966caf6840-231e.
From: sip:[email protected]:5060;tag=sansay155968379rdb15277.
Call-ID: B2B.164.6603158.
CSeq: 2 UPDATE.
Supported: 100rel, norefersub.
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER.
Contact: <sip:173.XXX.XXX.88:5060>.
Server: Ae SIP B2BUA.
Content-Length: 0.
.


On , Bogdan-Andrei Iancu <[email protected]> wrote:
> Hi Duane,
>
>
>
> Could you tried the attached patch please .
>
>
>
> Thanks and regards,
>
> Bogdan
>
>
>
>
>
> On 03/27/2012 07:26 PM, [email protected] wrote:
>
>
> Just wondering if there is an update on the UPDATE
>
>
>
>
>
>
>
> On , [email protected] wrote:
>
> > Thanks for looking at this.
>
> >
>
> >
>
> >
>
> >
>
> > On , Bogdan-Andrei Iancu [email protected]> wrote:
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > Thanks, got the info I need - I have a start, need to investigate
>
> > > bit more on UPDATE handling. I will come up with a fix for you.
>
> > >
>
> > >
>
> > >
>
> > > Regards,
>
> > >
>
> > > Bogdan
>
> > >
>
> > >
>
> > >
>
> > > On 03/23/2012 05:09 PM, Duane Larson wrote:
>
> > > Ok
>
> > >
>
> > >
>
> > >
>
> > > Patched dlg.c to look like this
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > b2b_dlg_t* b2b_search_htable_next_dlg(b2b_dlg_t* start_dlg,
>
> > > b2b_table table, unsigned int hash_index,
>
> > >
>
> > >                 unsigned int local_index, str* to_tag, str*
>
> > > from_tag, str* callid)
>
> > >
>
> > > {
>
> > >
>
> > >         b2b_dlg_t* dlg;
>
> > >
>
> > >         str dlg_from_tag={NULL, 0};
>
> > >
>
> > >         dlg_leg_t* leg;
>
> > >
>
> > >
>
> > >
>
> > >         LM_DBG("entering with start=%p, table=%p, hash=%i,
>
> > > label=%i \n",
>
> > >
>
> > >                 start_dlg,table,hash_index,local_index);
>
> > >
>
> > >         if(callid)
>
> > >
>
> > >                 LM_DBG("searching  callid %d[%.*s]\n",
>
> > > callid->len,callid->len, callid->s);
>
> > >
>
> > >         if(to_tag)
>
> > >
>
> > >                 LM_DBG("searching   totag %d[%.*s]\n",
>
> > > to_tag->len,to_tag->len, to_tag->s);
>
> > >
>
> > >         if(from_tag)
>
> > >
>
> > >                 LM_DBG("searching fromtag %d[%.*s]\n",
>
> > > from_tag->len,from_tag->len, from_tag->s);
>
> > >
>
> > >         dlg= start_dlg?start_dlg->next:table[hash_index].first;
>
> > >
>
> > >         while(dlg)
>
> > >
>
> > >         {
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > And here is the debug output and an NGREP of the call
>
> > >
>
> > >
>
> > >
>
> > > http://pastebin.com/ZiQsQj5r
>
> > >
>
> > >
>
> > >
>
> > > On Fri, Mar 23, 2012 at 6:19 AM,
>
> > > Bogdan-Andrei Iancu [email protected]>
>
> > > wrote:
>
> > >
>
> > > Hi Duane,
>
> > >
>
> > >
>
> > >
>
> > > Strange, the logs shows that the UPDATE did not actually
>
> > > match, while the BYE did...
>
> > >
>
> > >
>
> > >
>
> > > Could you please retake the test (same debug=4) while using
>
> > > the attached patch - the patch is just for printing more info
>
> > > related to matching.
>
> > >
>
> > >
>
> > >
>
> > > Thanks and regards,
>
> > >
>
> > > Bogdan
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > On 03/22/2012 06:24 PM, [email protected]
>
> > > wrote:
>
> > >
>
> > >
>
> > > Here is a debug and the NGREP that goes along with it.
>
> > >
>
> > >
>
> > >
>
> > > http://pastebin.com/DuDKUrGd
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > On , Bogdan-Andrei Iancu [email protected]>
>
> > > wrote:
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > > Hi Duane,
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > > Could please re-run the scenario with opensips in
>
> > > full debug
>
> > >
>
> > > > (debug=4) and and post somewhere the logs
>
> > > corresponding to UPDATE
>
> > >
>
> > > > and BYE processing ?
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > > Thanks and regards,
>
> > >
>
> > > >
>
> > >
>
> > > > Bogdan
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > > On 03/22/2012 03:46 AM, [email protected]
>
> > > wrote:
>
> > >
>
> > > > I am seeing the following issue
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > > One of OpenSIPS users makes an outbound call
>
> > > through a SIP
>
> > >
>
> > > > carrier. This gets sent to my OpenSIPS B2BUA which
>
> > > then sends it
>
> > >
>
> > > > to the SIP carrier. The calls length makes it to 30
>
> > > minutes and
>
> > >
>
> > > > then it is killed.
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > >
>
> > >
>
> > > > I see that the SIP carrier at around the 30 minute
>
> > > mark is sending
>
> > >
>
> > > > an UPDATE message to the client but for some reason
>
> > > when the
>
> > >
>
> > > > OpenSIPS B2BUA sees this UPDATE message it doesn't
>
> > > think it is
>
> > >
>
> > > > apart of the current dialog. So then the SIP
>
> > > carrier sends a BYE
>
> > >
>
> > > > because it never got a reply back for the UPDATE.
>
> > > The OpenSIPS
>
> > >
>
> > > > B2BUA has no problem recognizing the BYE message as
>
> > > being apart of
>
> > >
>
> > > > the Dialog and sends this over to the OpenSIPS
>
> > > user. Am I doing
>
>
>
>
> --
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>
> http://www.opensips-solutions.com
>
>
>
>


--
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to