< Previous by Date	Date Index	Next by Date >
< Previous in Thread	Thread Index	Next in Thread >

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

From: "Scott Godin" <slgodin@xxxxxxxxxxxx>
Date: Thu, 8 Mar 2007 12:00:28 -0500

Actually I’m convinced that the only way this can happen is if the resip application re-uses CSeq’s in mid-dialog requests – not garbage from the wire.

Scott

From: Scott Godin
Sent: Thursday, March 08, 2007 11:39 AM
To: 'Byron Campen'
Cc: 'Kovar, William (Bill)'; 'Robert Sparks'; 'resiprocate-devel@xxxxxxxxxxxxxxxxxxxx'
Subject: RE: [reSIProcate] Route Set problem with Update in resip 1.1 RC1

Well technically we can set the RouteSet on a 1xx and then later update on a 2xx. We could add a flag that gets set to true when we set the routeset due to 2xx response. I think that would work. I’ll look into this.

From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Thursday, March 08, 2007 11:25 AM
To: Scott Godin
Cc: Kovar, William (Bill); Robert Sparks; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Route Set problem with Update in resip 1.1 RC1

Maybe we ought to just put in a bool that gets set to true when the Record-Routes are first set. That would be nice and robust against garbage from the wire, I think.

Best regards,

Byron Campen

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@xxxxxxxxx]
Sent: Wednesday, March 07, 2007 6:28 PM
To: Robert Sparks; Byron Campen; Scott Godin
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx

Avaya, Inc.

(732) 852-2609

From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx]
Sent: Wednesday, March 07, 2007 5:35 PM
To: Byron Campen
Cc: Kovar, William (Bill); resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx

Avaya, Inc.

(732) 852-2609

From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Wednesday, March 07, 2007 4:31 PM
To: Kovar, William (Bill)
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx:5061;transport=tls SIP/2.0

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

Max-Forwards: 70

Route: <sip:135.8.52.181:5060;lr>

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

Contact: <sip:56000@xxxxxxxxxxxx:5060>

To: <sip:76800@xxxxxxxxx>;tag=0945f2f40dddb181b46f94dc00

From: "IC 7.1 B2B"<sip:56000@xxxxxxxxx>;tag=b855e212

Call-ID: ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.

CSeq: 2 ACK

Content-Type: application/sdp

Proxy-Authorization: Digest username="56000",realm="avaya.com",nonce="MTE3MzMzMTA4NTpTREZTZXJ2ZXJTZWNyZXRLZXk6NzQ1MTU0ODc4",uri="sip:76800@xxxxxxxxx",response="e1bdfe0882c087d5334812ad288f7c60",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: UPDATE56000@xxxxxxxxxxxx:5060 tid=03950393A79343D4439ec3.0 cseq=UPDATE contact=76800@xxxxxxxxx: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@xxxxxxxxxxxx: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=z9hG4bK80945f2f40dddb1c1b46f94dc00

Max-Forwards: 69

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

Contact: " CONFERENCE 2"<sip:76800@xxxxxxxxx:5061;transport=tls>;isfocus

To: "IC 7.1 B2B" <sip:56000@xxxxxxxxx>;tag=b855e212

From: sip:76800@xxxxxxxxx;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: UPDATE56000@xxxxxxxxxxxx:5060 tid=83A503034493935543998a.0 cseq=UPDATE contact=76800@xxxxxxxxx: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@xxxxxxxxxxxx: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=z9hG4bK80945f2f40dddb1c1b46f94dc00

Max-Forwards: 69

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

Contact: " CONFERENCE 2"<sip:76800@xxxxxxxxx:5061;transport=tls>;isfocus

To: "IC 7.1 B2B" <sip:56000@xxxxxxxxx>;tag=b855e212

From: sip:76800@xxxxxxxxx;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: UPDATE56000@xxxxxxxxxxxx:5060 tid=83A503034493935543998a.0 cseq=UPDATE contact=76800@xxxxxxxxx:5061 / 1 from(wire)
![2007-03-07 20:14:53.399] <2840:RESIP:DUM> DEBUG | DialogUsageManager.cxx:1456 | DialogUsageManager::processRequest: SipReq: UPDATE 56000@xxxxxxxxxxxx:5060 tid=83A503034493935543998a.0 cseq=UPDATE contact=76800@xxxxxxxxx:5061 / 1 from(wire)
![2007-03-07 20:14:53.399] <2840:RESIP:DUM> INFO | DialogUsageManager.cxx:1516 | Handling in-dialog request: SipReq: UPDATE56000@xxxxxxxxxxxx:5060 tid=83A503034493935543998a.0 cseq=UPDATE contact=76800@xxxxxxxxx:5061 / 1 from(wire)
![2007-03-07 20:14:53.399] <2840:RESIP:DUM> DEBUG | DialogId.cxx:50 | DialogId::DialogId: ZDU4Yjg4M2UxYTE1MjRiNzJkZTU3ZWMzYmNlMjZlZjk.-b855e212-0945f2f40dddb181b46f94dc00
![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@xxxxxxxxxxxx: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=z9hG4bK80945f2f40dddb1c1b46f94dc00

Max-Forwards: 69

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

Contact: " CONFERENCE 2"<sip:76800@xxxxxxxxx:5061;transport=tls>;isfocus

To: "IC 7.1 B2B"<sip:56000@xxxxxxxxx>;tag=b855e212

From: <sip:76800@xxxxxxxxx>;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: UPDATE56000@xxxxxxxxxxxx:5060 tid=83A503034493935543998a.0 cseq=UPDATE contact=76800@xxxxxxxxx:5061 / 1 from(wire)
![2007-03-07 20:14:53.399] <2840:RESIP> DEBUG | Helper.cxx:372 | Helper::makeResponse(SipReq: UPDATE56000@xxxxxxxxxxxx:5060 tid=83A503034493935543998a.0 cseq=UPDATE contact=76800@xxxxxxxxx: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=z9hG4bK80945f2f40dddb1c1b46f94dc00

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

Contact: <sip:56000>

To: "IC 7.1 B2B"<sip:56000@xxxxxxxxx>;tag=b855e212

From: <sip:76800@xxxxxxxxx>;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@xxxxxxxxx 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=z9hG4bK80945f2f40dddb1c1b46f94dc00

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

Contact: <sip:56000>

To: "IC 7.1 B2B"<sip:56000@xxxxxxxxx>;tag=b855e212

From: <sip:76800@xxxxxxxxx>;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=z9hG4bK80945f2f40dddb1c1b46f94dc00

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

Contact: <sip:56000@xxxxxxxxxxxx:5060>

To: "IC 7.1 B2B"<sip:56000@xxxxxxxxx>;tag=b855e212

From: <sip:76800@xxxxxxxxx>;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@xxxxxxxxx

Avaya, Inc.

(732) 852-2609

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel@xxxxxxxxxxxxxxxxxxxx

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

_______________________________________________

resiprocate-devel mailing list

resiprocate-devel@xxxxxxxxxxxxxxxxxxxx

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

Follow-Ups:
- Re: [reSIProcate] Route Set problem with Update in resip 1.1 RC1
  - From: Kovar, William \(Bill\)

References:
- Re: [reSIProcate] Route Set problem with Update in resip 1.1 RC1
  - From: Byron Campen

Prev by Date: Re: [reSIProcate] Question about Record-Route headers on re-Invite
Next by Date: Re: [reSIProcate] Route Set problem with Update in resip 1.1 RC1
Previous by thread: Re: [reSIProcate] Route Set problem with Update in resip 1.1 RC1
Next by thread: Re: [reSIProcate] Route Set problem with Update in resip 1.1 RC1
Index(es):
- Date
- Thread