headers
Arjun Nair | 15 Aug 16:26
Favicon

Record Route Processing in Requests

Hi,

I would like to propose adding record route processing in -

sipXtackLib/src/net/SipMessage.cpp:

void SipMessage::setResponseData(const SipMessage* request,
                         int responseCode,
                         const char* responseText,
                         const char* localContact)
i.e.

if responseCode = 2XX or 18X
then
    if request.isRecordRouteAccepted()
    then
        copy all recordRouteData in request to response
    fi
fi

   
The main question I have about this is:

RFC 3261 states that requests with a dialog in a UAS, - ".. MAY contain
Record-Route and Contact header fields.  However, these requests do not
cause the dialog's route set to be modified, although they may modify
the remote target URI.".. So does the 2XX response to this in-dialog
request still echo the record-routes (especially in the cases where the
record routes differ from the ones set in the dialog-initiating request)
??
(Continue reading)

Permalink | Reply |
headers
Scott Lawrence | 15 Aug 17:27

Re: Record Route Processing in Requests


On Fri, 2008-08-15 at 10:27 -0400, Arjun Nair wrote:
> Hi,
> 
> I would like to propose adding record route processing in -
> 
> sipXtackLib/src/net/SipMessage.cpp:
> 
> void SipMessage::setResponseData(const SipMessage* request,
>                          int responseCode,
>                          const char* responseText,
>                          const char* localContact)
> i.e.
> 
> if responseCode = 2XX or 18X
> then
>     if request.isRecordRouteAccepted()
>     then
>         copy all recordRouteData in request to response
>     fi
> fi

The Record-Route should only be echoed (or used in any other way) if the
response is dialog-forming.  At that level in the stack, I don't think
we know that, so I suspect this is not the right place for this.

> The main question I have about this is:
> 
> RFC 3261 states that requests with a dialog in a UAS, - ".. MAY contain
> Record-Route and Contact header fields.  However, these requests do not
(Continue reading)

Permalink | Reply |
headers
Arjun Nair | 15 Aug 19:00
Favicon

Re: Record Route Processing in Requests


> -----Original Message-----
> From: Scott Lawrence [mailto:slawrence <at> pingtel.com] 
> Sent: Friday, August 15, 2008 11:27 AM
> 
> The Record-Route should only be echoed (or used in any other 
> way) if the response is dialog-forming.  At that level in the 
> stack, I don't think we know that, so I suspect this is not 
> the right place for this.
> 

Yes, that was pretty much my concern. If Record-Routes are only echoed
for dialog-forming responses, then it would not make sense put it there.

> 
> No, I think not.  
> 
> The route set cannot be modified by an in-dialog request: 
> only the remote contact value can be (yes, this doesn't make 
> much sense, but that's the way the rules work and it's too 
> late to fix them - this has been getting quite a bit of 
> discussion in the SIP working group over the last several months).
> 
> There really should not _be_ a Record-Route header on an 
> in-dialog request (Route headers, yes, Record-Route, no).  

Are you sure? RFC states in Section 16.6.4

         If this request is already part of a dialog, the proxy SHOULD
         insert a Record-Route header field value if it wishes to remain
(Continue reading)

Permalink | Reply |
headers
Dale Worley | 15 Aug 20:41

Re: Record Route Processing in Requests

The situation is kind of messy, just the sort of thing that needs to be
cleaned up in SIP 3.0.

Record-Routes that are in requests within a dialog have no effect.  The
problem is determining if the request in question is within a dialog.
In our case, there is the classical race between the response to the
SUBSCRIBE and the NOTIFY as to which will create the subscription dialog
at the subscriber's end.  Also the SUBSCRIBE may have forked.

IIRC from discussions on the SIP mailing list, the safe rules are:

- second and later SUBSCRIBEs are always within dialog

- a NOTIFY is known to be within-dialog if we've received a response to
a previous NOTIFY, or if we've received a *second* SUBSCRIBE

- one can always insert and turn around Record-Routes safely, it is
omitting to do so that needs to be checked for safety

The concept of "reconstituting" a dialog when a UA reboots sounds good
but in practice can't be done, because the UA needs to recover the CSeq
it was using for sending requests, and there's no way to get the other
UA to tell it that.  There was a long-standing bug in sipXpublisher due
to the belief that broken message-status subscriptions could be
recovered.

But in sipXtack, the handling of Record-Routes is done at a fairly high
level.  I'm not sure if SipUserAgent does it, or SipUserAgent's caller.
But if you track down where Record-Route is now handled, and modify
that, you'll at least not make the architecture any messier.
(Continue reading)

Permalink | Reply |
headers
Arjun Nair | 19 Aug 00:12
Favicon

Re: Record Route Processing in Requests


> -----Original Message-----
> From: Dale Worley [mailto:dworley <at> pingtel.com] 
> Sent: Friday, August 15, 2008 2:42 PM
> The situation is kind of messy, just the sort of thing that 
> needs to be cleaned up in SIP 3.0.
> 
> Record-Routes that are in requests within a dialog have no 
> effect.  
> But in sipXtack, the handling of Record-Routes is done at a 
> fairly high level.  I'm not sure if SipUserAgent does it, or 
> SipUserAgent's caller.
> But if you track down where Record-Route is now handled, and 
> modify that, you'll at least not make the architecture any messier.
> 
> Dale
> 

http://track.sipfoundry.org/browse/XECS-1363 - Record-Route's not
handled correctly in SUBSCRIBE/NOTIFY by SipSubscriptionManager

Problem:

1. NOTIFYs sent from SipSubscribeServer do not include any Route sets
set by the dialog initiating SUBSCRIBE

2. Dialog forming "202 ACCEPTED" Response sent from SipSubscribeServer,
does not echo any Record-Routes present in the dialog initiating
SUBSCRIBE
(Continue reading)

Permalink | Reply |
headers
Dale Worley | 19 Aug 00:18

Re: Record Route Processing in Requests

On Mon, 2008-08-18 at 18:12 -0400, Arjun Nair wrote:
> 1. In the SipDialog constructor, check for dialog initiating Requests,
> that are initiated from the remote side. If found, set the Route sets
> from this Request.
> 
> 2. Add an extra function argument - "UtlBoolean responseIsDialogForming"
> to SipMessage::setResponseData(), with a default value of "FALSE". If
> this argment is set to "TRUE" then any Record-Routes present in the
> Request is added to the Response. 

I think the name might better be "responseMayBeDialogForming" -- the
problem is that the sender doesn't always know whether the response will
be dialog-forming or not, and we can only omit Record-Route processing
if we *know* that the response is not dialog-forming.  This also bears
on whether the default value should be FALSE.  At least in principle,
the default should be to handle Record-Route.

(How is this done for INVITEs?)

> In SipSubscriptionMgr::updateDialogInfo(), where the "202 Accepted"
> dialog-forming Response is build, call the SipMessage::setResponseData()
> with "UtlBoolean responseIsDialogForming" set to "TRUE".

Dale
Permalink | Reply |
headers
Arjun Nair | 19 Aug 15:02
Favicon

Re: Record Route Processing in Requests


> -----Original Message-----
> From: Dale Worley [mailto:dworley <at> pingtel.com] 
> Sent: Monday, August 18, 2008 6:19 PM
> To: Nair, Arjun (CAR:9D30)
> 
> I think the name might better be "responseMayBeDialogForming" 
> -- the problem is that the sender doesn't always know whether 
> the response will be dialog-forming or not, and we can only 
> omit Record-Route processing if we *know* that the response 
> is not dialog-forming.  This also bears on whether the 

OK, I agree on the premise that it is better to have a
non-dialog-forming Response echo back the Record-Route headers, than
have a dialog-forming Response not do so.

> default value should be FALSE.  At least in principle, the 
> default should be to handle Record-Route.

True, while it makes sense to handle Record-Routes by default, there
already exists so much code that is based on it not being handled by
default - 200 OKs to BYE, 202 ACCEPTED to in-dialog NOTIFYs, etc. Now,
if handling Record-Routes in non-dialog-forming Responses are truly
inconsequential, then we can go ahead and set the default to TRUE,
otherwise, I would suggest we raise a separate issue and make this
change across the board..

> 
> (How is this done for INVITEs?)
(Continue reading)

Permalink | Reply |

Gmane