[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] Route-Set for a SUBSCRIBE refresh
From:       Robert Sparks <rjsparks () nostrum ! com>
Date:       2008-02-28 20:02:15
Message-ID: 6258C7D5-19C5-4624-BE05-280A13A9FE89 () nostrum ! com
[Download RAW message or body]

Actually - there's a fairly big problem with the specifications here  
that the IETF
is going to have to weigh in on at some point.

SUBSCRIBE is a non-INVITE transaction. When an initial SUBSCRIBE forks,
and is accepted on more than one branch, only one of the 2xx's make  
it back
to the original subscriber (as opposed to all of the 2xx's making it  
back for an
INVITE transaction).

A consequence is that only the route-set for _one_ of the branches  
makes it back
in the 2xx. That routeset is most likely inappropriate for any other  
of the branches.

That argues for using the route set from the initial notify. BUT.
The requirement for proxies to add Record-Route values to mid-dialog  
requests
(in this case NOTIFYs), is SHOULD strength, and there are a lot of  
existing proxies
that have decided that SHOULD means optional (which is wrong), so in  
practice,
the NOTIFY isn't likely to have any route-set information at all.

Its a mess.

Here's my advice - and take it only as advice from an individual...

Remember the routeset from the 2xx-SUBSCRIBE. Use it for any dialog
that didn't have a routeset in its initial NOTIFY, If there _was_ a  
routeset
in the initial NOTIFY, use that instead. Its not perfect, but its the  
best you can
do with the situation at hand.

I hope to be helping push an update to 3265 through that will make  
this better.

RjS



On Feb 21, 2008, at 5:11 PM, Dale.Worley@comcast.net wrote:

>    From: "Pascal Maugeri" <pascal.maugeri1@gmail.com>
>
>    In a SUBSCRIBE dialog, where should I read the Route-Set from for
>    subsequent re-SUBSCRIBE ? From the SUBSCRIBE-OK response or from
>    the first NOTIFY request ?
>
> The first request/response pair in a dialog establishes the route set,
> so it could come from either source.  But most importantly beware that
> a single SUBSCRIBE can create multiple subscriptions, so you could
> receive a 200 or 202 response, and then a NOTIFY from a *different*
> subscription, which has a separate route-set.
>
>    And then should I respect the exact order when forming the Route
>    headers or should I invert the order ?
>
> Check RFC 3261, I believe it gives an explicit description.
>
> Dale
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


[prev in list] [next in list] [prev in thread] [next in thread]