Re: [reSIProcate] Question about Record-Route headers on re-Invite

["Scott Godin" <slgodin@xxxxxxxxxxxx>]

The problem is probably that the UA your testing with is reusing the CSeq that was used to establish the dialog in the first place.  My fix, looks at the CSeq of the request that created the dialog and checks against the CSeq in the response to know whether to update the route set or not. 

 

Note:  The routeset is created by the first dialog creating response (could be 1xx or 2xx) if created from a 1xx response then it must be updated after receiving the 200 (section 13.2.2 – 2xx Responses).  If your fix is only in the Dialog constructor then it will not work if the dialog is created with a 1xx response.

 

Scott

 

 

From: Kovar, William (Bill) [mailto:bkovar@xxxxxxxxx]
Sent: Wednesday, March 07, 2007 6:47 PM
To: Scott Godin
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Question about Record-Route headers on re-Invite

 

Scott,

 

The code below does not work.

 

I put back in the fix my developer had created and the problem is solved.

 

I put my old fix back in and it now works correctly.

 

Here's the code for Dialog.cxx

 

if(mInviteSession == 0 || mRouteSet.size() == 0)

{

    if (code >=200 && code < 300)

    {

        if (response.exists(h_RecordRoutes))

        {

            mRouteSet = response.header(h_RecordRoutes).reverse();

        }

    }

}

 

In particular, this code never gets run because the route set is created during construction of the Dialog. That should be enough.

 

 

 

Bill Kovar

bkovar@xxxxxxxxx

Avaya, Inc.

(732) 852-2609

 

 

---

From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Thursday, January 18, 2007 5:30 PM
To: Kovar, William (Bill)
Subject: RE: [reSIProcate] Question about Record-Route headers on re-Invite

Hi Bill,

 

I’m just waiting back to hear from the developer that modified this code last before I commit a solution.  But here is what I have so far – if you want to try it out:

 

Modify the code in Dialog.cxx near line 561 to read.

 

      const SipMessage& response = msg;

      int code = response.header(h_StatusLine).statusCode();

      // If this is a 200 response to the initial request, then store the routeset (if present)

      if (creator && (creator->getLastRequest()->header(h_CSeq).sequence() == response.header(h_CSeq).sequence()) && code >=200 && code < 300)

      {

         if (response.exists(h_RecordRoutes))

         {

            mRouteSet = response.header(h_RecordRoutes).reverse();

         }

      }

 

Thanks,

 

Scott

 

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Kovar, William (Bill)
Sent: Wednesday, January 10, 2007 4:22 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Question about Record-Route headers on re-Invite

 

I'm seeing a situation where an initial session has been established with 2 Record-Route's set, i.e. IP1 & IP2.

 

When a re-invite sent, both Routes (IP1 & IP2) are used, however, the 200 OK only sends one (IP1).

 

The subsequent ACK generated only insert Route: IP1 and the final destination is never reached. This causes retransmission of the 200 OK over and over.

 

It seems like DUM/resip is over-writing the original Route set established with the initial session, which is an RFC 3261 violation - section 12.2

 

As I am on a version of resip prior to resip 1.0, is this a known problem and fixed??

 

Bill Kovar