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

[Scott Godin]

Are you somehow re-using the CSeq number from the original request for
mid-dialog requests (re-invites)?  That's the only way I can explain why
my fix is not working for you.

 

From: Kovar, William (Bill) [mailto:bkovar at avaya.com] 
Sent: Thursday, March 08, 2007 11:58 AM
To: Scott Godin
Cc: resiprocate-devel at list.resiprocate.org
Subject: RE: [reSIProcate] Question about Record-Route headers on
re-Invite

 

Scott,

 

You are correct about me missing a 2xx route set change, but in the
SBC's I am communicating with, this problem never happens.

 

That's why my fix, although not complete, works.

 

 

Bill Kovar

bkovar at avaya.com

Avaya, Inc.

(732) 852-2609

 

	 

________________________________

	From: Scott Godin [mailto:slgodin at icescape.com] 
	Sent: Thursday, March 08, 2007 11:45 AM
	To: Kovar, William (Bill)
	Cc: resiprocate-devel at list.resiprocate.org
	Subject: RE: [reSIProcate] Question about Record-Route headers
on re-Invite

	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/9f9126fc/attachment.htm>