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

[Scott Godin]

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 at avaya.com] 
Sent: Wednesday, March 07, 2007 6:47 PM
To: Scott Godin
Cc: resiprocate-devel at list.resiprocate.org
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 at avaya.com

Avaya, Inc.

(732) 852-2609

 

	 

________________________________

	From: Scott Godin [mailto:slgodin at icescape.com] 
	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 at list.resiprocate.org
[mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of
Kovar, William (Bill)
	Sent: Wednesday, January 10, 2007 4:22 PM
	To: resiprocate-devel at list.resiprocate.org
	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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070308/a7cd5930/attachment.htm>