[reSIProcate] Route Set problem with Update in resip 1.1 RC1

Thu Mar 8 10:14:28 CST 2007

Strange.  Every sent re-invite should have a different CSeq than
creator->getLastRequest() (request used to create the UAC dialog) - so
this code should NOT update the route set.  How are you sending
re-invites?

Scott

From: Kovar, William (Bill) [mailto:bkovar at avaya.com] 
Sent: Wednesday, March 07, 2007 6:28 PM
To: Robert Sparks; Byron Campen; Scott Godin
Cc: resiprocate-devel at list.resiprocate.org
Subject: RE: [reSIProcate] Route Set problem with Update in resip 1.1
RC1

Robert, Byron, Scott,

The problem I am seeing is actually not directly (I think), related to
the Update. Additional digging seems to point to the bug I had found a
while back (see thread: Question about Record-Route headers on
re-Invite).

The Update msg gets sent a 200 OK correctly. But my ensuing re-invite,
w/2 RR, is 200 OK's w/1 RR, and the ACK only uses 1 RR. I believe that
the 200 OK to the re-invite is causing DUM to over-write the mRouteSet
for the session.

Scott Godin put a fix in for this problem but I believe the fix is
broken because EVERY sent Invite's 200 OK is over-writing the route set.

The fix in Dialog.cxx line 561 is:

BaseCreator* creator = mDialogSet.getCreator();

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();

    }

}

I don't know what mDialog.getCreator() is pointing to, but this code is
getting executed again for an already established session.

Bill Kovar

bkovar at avaya.com

Avaya, Inc.

(732) 852-2609

________________________________

	From: Robert Sparks [mailto:rjsparks at nostrum.com] 
	Sent: Wednesday, March 07, 2007 5:35 PM
	To: Byron Campen
	Cc: Kovar, William (Bill);
resiprocate-devel at list.resiprocate.org
	Subject: Re: [reSIProcate] Route Set problem with Update in
resip 1.1 RC1

	Ok - so I dug and have to concede that I find no normative
requirement to echo the RR in the 200

	to a mid-dialog request (on today's dig anyhow).

	Here is what we have assuming I didn't miss something:

	12.1.1.1 first paragraph contains the requirement to echo what
you see (arguably, you could 

	claim that this applies only to messages that create a dialog)

	12.2 contains the text telling you that RR may show up
mid-dialog, but you don't update the route set.

	Bill - for your purposes, that text in 12.2 should give you the
path out of your original question. It doesn't

	_matter_ what bits get put those responses - you are supposed to
ignore them as an endpoint.

	12.2.2 sends you off to 8.2 once you've figured out this is a
mid-dialog request (and has

	some of the reconstituting state text btw). I am willing to bet
(based on memory, take it for what it's worth)

	that the text there at one point contained the reflect the RR
and it got shuffled out during the 3261

	restructuring editing.

	So where does that leave us? We _could_ decide to not return any
RR at all in these mid-dialog requests

	without violating spec. (We could also populate them with frogs
as long as we can make them syntactically

	valid without violating spec).

	I'll argue that most of the world will expect to see what was
contained in the request reflected back to them

	and we'll keep our interoperability level highest by doing that
(until we have an opportunity to clean the

	spec with respect to this). 

	RjS

	On Mar 7, 2007, at 4:11 PM, Byron Campen wrote:

	By the way, is there specific normative text for this? I tried
finding some, but I never found a section that specified the UAS
behavior vis-a-vis Record-Routes for in-dialog requests (in 3261
anyway).

	Best regards,

	Byron Campen

	You are correct that the route set doesn't change. But that has
nothing to do with 

	the contents of the Record-Route header field in a mid-dialog
transaction.

	We are still required by the spec to reflect in the response
exactly what we receive in the request.

	It does not change our route set. It will not change the other
ends route set. (The endpoints are

	_required_ to ignore the Record-Route header field in mid-dialog
transactions).

	So there are many wasted bits, but that is what the spec
requires.

	How did the spec get into such a messy place? There was an
attempt at one point

	(mostly led by Henning) to make it so that endpoints could
"reconstitute" dialog state

	after rebooting by pulling some mid-dialog message out of the
ether and filling in all the blanks.

	To support that effort, a SHOULD requirement on proxies to add
Record-Route to mid-dialog

	requests was added. And, in a twist of irony, the very same
conversations reinforced the idea

	that the route set must never change (shooting down the
suggestion that we record-route

	every request, we might as well make the route set updateable).
((And this is one of the arguments

	I'm still bitter about losing btw).

	The upshot is: The stack is doing what it's supposed to do.

	RjS

	On Mar 7, 2007, at 3:36 PM, Kovar, William ((Bill)) wrote:

	The basic rule is:

	Once the route set is computed (from an initial INVITE or
response that creates a dialog) it doesn't change. 

	Only the remote target can change.

	So this in-dialog Update shouldn't be doing this....

	Bill Kovar

	bkovar at avaya.com

	Avaya, Inc.

	(732) 852-2609

________________________________

		From: Byron Campen [mailto:bcampen at estacado.net] 
		Sent: Wednesday, March 07, 2007 4:31 PM
		To: Kovar, William (Bill)
		Cc: resiprocate-devel at list.resiprocate.org
		Subject: Re: [reSIProcate] Route Set problem with Update
in resip 1.1 RC1

		This is interesting. I do not think it would be correct
to change the Record-Route stack to reflect the Route set in the dialog.
Obviously something in the middle is confused if this happens, and
changing the Record-Route stack in the response is liable to confuse it
even further. Both endpoints should just ignore the Record-Route
header-field-values entirely, I think.

		Any other opinions?

		Best regards,

		Byron Campen

		There seems to be another problem with Record Route
processing.

		After an established dialog, an Update is received that
runs through Helper::makeResponse() to build a 200 msg that does not
contain the correct Route Set.

		I had found this error in a different scenario, i.e. a
response, which is fixed. Now I see this in an Update, i.e. a request.

		I believe the problem is at Helper.cxx line 410

		Here's a log snip, correct route set in ACK in blue, bad
route set in 200 OK in red for same call-id:

		 ![2007-03-07 20:14:53.258] <2952:RESIP:TRANSPORT>
DEBUG | TransportSelector.cxx:869 | Transmitting to [ V4
135.8.52.181:5060 UDP target domain=135.8.52.181 received on: Transport:
[ V4 0.0.0.0:5060 UDP target domain=unspecified connectionId=0 ]
connectionId=0 ] tlsDomain= via [ V4 135.8.116.33:5060 UDP target
domain=135.8.52.181 connectionId=0 ]

		ACK sip:76800 at avaya.com:5061;transport=tls SIP/2.0

		Via: SIP/2.0/UDP
135.8.116.33:5060;branch=z9hG4bK-d8754z-b20c1e5c1c57e971-1---d8754z-;rpo
rt

		Max-Forwards: 70

		Route: <sip:135.8.52.181:5060;lr>

		Route: <sip:135.8.83.172:5061;lr;transport=tls>

		Contact: <sip:56000 at 135.8.116.33:5060>

		To: <sip:76800 at avaya.com>;tag=0945f2f40dddb181b46f94dc00

		From: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=b855e212

		Call-ID: ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.

		CSeq: 2 ACK

		Content-Type: application/sdp

		Proxy-Authorization: Digest
username="56000",realm="avaya.com",nonce="MTE3MzMzMTA4NTpTREZTZXJ2ZXJTZW
NyZXRLZXk6NzQ1MTU0ODc4",uri="sip:76800 at avaya.com",response="e1bdfe0882c0
87d5334812ad288f7c60",algorithm=MD5

		User-Agent: AvSIP 1.04.2

		Content-Length: 202

		v=0

		o=- 1 2 IN IP4 135.8.83.172

		s=-

		c=IN IP4 135.8.83.133

		t=0 0

		m=audio 36456 RTP/AVP 0 18 127

		a=fmtp:18 annexb=no

		a=rtpmap:0 PCMU/8000

		a=rtpmap:18 G729/8000

		a=rtpmap:127 telephone-event/8000

		 ![2007-03-07 20:14:53.258] <2952:RESIP:TRANSPORT>
DEBUG | Transport.cxx:213 | Adding message to tx buffer to: [ V4
135.8.52.181:5060 UDP target domain=135.8.52.181 received on: Transport:
[ V4 0.0.0.0:5060 UDP target domain=unspecified connectionId=0 ]
connectionId=0 ]
		 ![2007-03-07 20:14:53.305] <2952:RESIP:TRANSPORT>
DEBUG | Transport.cxx:287 | incoming from: [ V4 135.8.52.181:32796 UDP
target domain=unspecified received on: Transport: [ V4 0.0.0.0:5060 UDP
target domain=unspecified connectionId=0 ] connectionId=0 ]
		 ![2007-03-07 20:14:53.305] <2952:RESIP:TRANSACTION>
DEBUG | TransactionUser.cxx:66 | Checking if SipReq:  UPDATE
56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=03950393A79343D4439ec3.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061>  / 1 from(wire) is for me
		 ![2007-03-07 20:14:53.305] <2952:RESIP:TRANSACTION>
DEBUG | TransactionUser.cxx:71 | Checking rule...
		 ![2007-03-07 20:14:53.305] <2952:RESIP:TRANSACTION>
DEBUG | MessageFilterRule.cxx:70 | Matching rule for: 

		UPDATE sip:56000 at 135.8.116.33:5060 SIP/2.0

		Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0

		Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00

		Max-Forwards: 69

		Record-Route: <sip:135.8.52.181:5060;lr>

		Contact: "  CONFERENCE
2"<sip:76800 at avaya.com:5061;transport=tls>;isfocus

		To: "IC 7.1 B2B" <sip:56000 at avaya.com>;tag=b855e212

		From: sip:76800 at avaya.com;tag=0945f2f40dddb181b46f94dc00

		Call-ID: ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.

		CSeq: 1 UPDATE

		Session-Expires: 240;refresher=uac

		Min-SE: 240

		Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE,
NOTIFY, REFER, OPTIONS

		Supported: 100rel, timer, replaces, join, histinfo

		User-Agent: Avaya CM/R013x.01.2.632.1

		Content-Length: 0

		 ![2007-03-07 20:14:53.383] <2952:RESIP:TRANSACTION>
DEBUG | MessageFilterRule.cxx:241 | MSG User = 56000
		 ![2007-03-07 20:14:53.383] <2952:RESIP:TRANSACTION>
DEBUG | MessageFilterRule.cxx:252 | List USER = 56000
		 ![2007-03-07 20:14:53.383] <2952:RESIP:TRANSACTION>
DEBUG | TransactionUser.cxx:74 | Match!
		 ![2007-03-07 20:14:53.383] <2952:RESIP>  DEBUG |
Helper.cxx:372 | Helper::makeResponse(SipReq:  UPDATE
56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061>  / 1 from(wire) code=100 reason=
		 ![2007-03-07 20:14:53.383] <2952:RESIP:TRANSACTION>
DEBUG | TimerQueue.cxx:85 | Adding timer: Timer Trying
tid=83A503034493935543998a.0 ms=3500
		 ![2007-03-07 20:14:53.383] <2952:RESIP:TRANSACTION>
DEBUG | TransactionState.cxx:1852 | Send to TU: TU: DialogUsageManager
size=0 

		UPDATE sip:56000 at 135.8.116.33:5060 SIP/2.0

		Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0

		Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00

		Max-Forwards: 69

		Record-Route: <sip:135.8.52.181:5060;lr>

		Contact: "  CONFERENCE
2"<sip:76800 at avaya.com:5061;transport=tls>;isfocus

		To: "IC 7.1 B2B" <sip:56000 at avaya.com>;tag=b855e212

		From: sip:76800 at avaya.com;tag=0945f2f40dddb181b46f94dc00

		Call-ID: ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.

		CSeq: 1 UPDATE

		Session-Expires: 240;refresher=uac

		Min-SE: 240

		Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE,
NOTIFY, REFER, OPTIONS

		Supported: 100rel, timer, replaces, join, histinfo

		User-Agent: Avaya CM/R013x.01.2.632.1

		Content-Length: 0

		 ![2007-03-07 20:14:53.383] <2840:RESIP:DUM>  INFO |
DialogUsageManager.cxx:1190 | Got: SipReq:  UPDATE
56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061>  / 1 from(wire)
		 ![2007-03-07 20:14:53.399] <2840:RESIP:DUM>  DEBUG |
DialogUsageManager.cxx:1456 | DialogUsageManager::processRequest:
SipReq:  UPDATE 56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061>  / 1 from(wire)
		 ![2007-03-07 20:14:53.399] <2840:RESIP:DUM>  INFO |
DialogUsageManager.cxx:1516 | Handling in-dialog request: SipReq:
UPDATE 56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061>  / 1 from(wire)
		 ![2007-03-07 20:14:53.399] <2840:RESIP:DUM>  DEBUG |
DialogId.cxx:50 | DialogId::DialogId:
ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.-b855e212-0945f2f40dddb181b4
6f94dc00
		 ![2007-03-07 20:14:53.399] <2840:RESIP:DUM>  DEBUG |
DialogSet.cxx:428 | Found matching dialog mClientSubscriptions(0),
mServerSubscriptions(0) for 

		UPDATE sip:56000 at 135.8.116.33:5060 SIP/2.0

		Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0

		Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00

		Max-Forwards: 69

		Record-Route: <sip:135.8.52.181:5060;lr>

		Contact: "  CONFERENCE
2"<sip:76800 at avaya.com:5061;transport=tls>;isfocus

		To: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=b855e212

		From:
<sip:76800 at avaya.com>;tag=0945f2f40dddb181b46f94dc00

		Call-ID: ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.

		CSeq: 1 UPDATE

		Session-Expires: 240;refresher=uac

		Min-SE: 240

		Allow: INVITE, CANCEL, BYE, ACK, PRACK, SUBSCRIBE,
NOTIFY, REFER, OPTIONS

		Supported: 100rel, timer, replaces, join, histinfo

		User-Agent: Avaya CM/R013x.01.2.632.1

		Content-Length: 0

		 ![2007-03-07 20:14:53.399] <2840:RESIP:DUM>  DEBUG |
Dialog.cxx:315 | Dialog::dispatch: SipReq:  UPDATE
56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061>  / 1 from(wire)
		 ![2007-03-07 20:14:53.399] <2840:RESIP>  DEBUG |
Helper.cxx:372 | Helper::makeResponse(SipReq:  UPDATE
56000 at 135.8.116.33:5060 <mailto:56000 at 135.8.116.33:5060>
tid=83A503034493935543998a.0 cseq=UPDATE contact=76800 at avaya.com:5061
<mailto:contact=76800 at avaya.com:5061>  / 1 from(wire) code=200 reason=
		 ![2007-03-07 20:14:53.399] <2840:RESIP:DUM>  DEBUG |
Dialog.cxx:984 | Dialog::makeResponse: 

		SIP/2.0 200 OK

		Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0

		Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00

		Record-Route: <sip:135.8.52.181:5060;lr>

		Contact: <sip:56000>

		To: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=b855e212

		From:
<sip:76800 at avaya.com>;tag=0945f2f40dddb181b46f94dc00

		Call-ID: ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.

		CSeq: 1 UPDATE

		Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, NOTIFY

		Content-Length: 0

		 ![2007-03-07 20:14:53.399] <2840:RESIP:APP>  INFO |
UserAgent.cpp:2146 | sip:76800 at avaya.com CUserAgent::onReadyToSend(CISH)
on session 23 - SipResp: 200 tid=83A503034493935543998a.0 cseq=UPDATE
contact=56000 / 1 from(tu)
		 ![2007-03-07 20:14:53.399] <2840:RESIP:APP>  INFO |
UserAgent.cpp:2147 | NO OP
		 ![2007-03-07 20:14:53.399] <2840:RESIP:DUM>  DEBUG |
DialogUsageManager.cxx:800 | SEND: 

		SIP/2.0 200 OK

		Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0

		Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00

		Record-Route: <sip:135.8.52.181:5060;lr>

		Contact: <sip:56000>

		To: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=b855e212

		From:
<sip:76800 at avaya.com>;tag=0945f2f40dddb181b46f94dc00

		Call-ID: ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.

		CSeq: 1 UPDATE

		Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, NOTIFY

		User-Agent: AvSIP 1.04.2

		Content-Length: 0

		 ![2007-03-07 20:14:53.399] <2840:RESIP>  DEBUG |
SipStack.cxx:290 | SEND: SipResp: 200 tid=83A503034493935543998a.0
cseq=UPDATE contact=56000 / 1 from(tu)
		 ![2007-03-07 20:14:53.414] <2952:RESIP:TRANSACTION>
DEBUG | TimerQueue.cxx:85 | Adding timer: Timer J
tid=83A503034493935543998a.0 ms=32000
		 ![2007-03-07 20:14:53.414] <2952:RESIP:TRANSPORT>
DEBUG | TransportSelector.cxx:521 | Looked up source for destination: [
V4 135.8.52.181:5060 UDP target domain=unspecified received on:
Transport: [ V4 0.0.0.0:5060 UDP target domain=unspecified
connectionId=0 ] connectionId=0 ] -> [ V4 135.8.116.33:0 UDP target
domain=unspecified received on: Transport: [ V4 0.0.0.0:5060 UDP target
domain=unspecified connectionId=0 ] connectionId=0 ]
sent-by=135.8.52.181 sent-port=5060
		 ![2007-03-07 20:14:53.414] <2952:RESIP:TRANSPORT>
DEBUG | TransportSelector.cxx:869 | Transmitting to [ V4
135.8.52.181:5060 UDP target domain=unspecified received on: Transport:
[ V4 0.0.0.0:5060 UDP target domain=unspecified connectionId=0 ]
connectionId=0 ] tlsDomain= via [ V4 135.8.116.33:5060 UDP target
domain=unspecified received on: Transport: [ V4 0.0.0.0:5060 UDP target
domain=unspecified connectionId=0 ] connectionId=0 ]

		SIP/2.0 200 OK

		Via: SIP/2.0/UDP
135.8.52.181:5060;branch=z9hG4bK83A503034493935543998a.0

		Via: SIP/2.0/TLS
avaya.com;psrrposn=1;received=135.8.83.172;branch=z9hG4bK80945f2f40dddb1
c1b46f94dc00

		Record-Route: <sip:135.8.52.181:5060;lr>

		Contact: <sip:56000 at 135.8.116.33:5060>

		To: "IC 7.1 B2B"<sip:56000 at avaya.com>;tag=b855e212

		From:
<sip:76800 at avaya.com>;tag=0945f2f40dddb181b46f94dc00

		Call-ID: ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.

		CSeq: 1 UPDATE

		Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE, NOTIFY

		User-Agent: AvSIP 1.04.2

		Content-Length: 0

		 ![2007-03-07 20:14:53.414] <2952:RESIP:TRANSPORT>
DEBUG | Transport.cxx:213 | Adding message to tx buffer to: [ V4
135.8.52.181:5060 UDP target domain=unspecified received on: Transport:
[ V4 0.0.0.0:5060 UDP target domain=unspecified connectionId=0 ]
connectionId=0 ]

		Bill Kovar

		bkovar at avaya.com

		Avaya, Inc.

		(732) 852-2609

		_______________________________________________

		resiprocate-devel mailing list

		resiprocate-devel at list.resiprocate.org

https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

	_______________________________________________

	resiprocate-devel mailing list

	resiprocate-devel at list.resiprocate.org

	https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

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