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

Wed Mar 7 17:28:20 CST 2007

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/20070307/08053dae/attachment.htm>