Subject: RE: [Sip] Question on Service Route Discovery Procedure duringRegistration

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 7 Apr 2006 11:21:19 +0200

Hi,

If we are going to update RFC 3608 there are a couple of things I think
we should also consider.

1. UA behavior

Currently the text says that the UA MAY use the Service-Route e.g. to
create a route for future requests.

Now, if we are going to add an option-tag (to be used by the UA in the
Require/Supported header) I think we should also say that the UA SHALL
use the Service-Route for future request (why would it otherwise ask for
it?), and also HOW the route is created. 24.229 defines how IMS UEs
create the route, so similar text is needed for generic UA behavior.

2. Registrar processing of Path

I think we should also take Jonathan's draft,
draft-rosenberg-sip-route-construct-00, into consideration, which allows
a registrar to build a Service-Route set based on the received Path
headers.

Regards,

Christer  

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: 5. huhtikuuta 2006 20:06
To: Lu, Yang, VF-DE
Cc: [email-masked]
Subject: Re: [Sip] Question on Service Route Discovery Procedure
duringRegistration

On Apr 3, 2006, at 7:09 AM, Lu, Yang, VF-DE wrote:

>
> Dear All
>
> RFC 3261 Section 8.2.4 "Applying Extensions" says
>
> "A UAS that wishes to apply some extension when generating the 
> response MUST NOT do so unless support for that extension is indicated

> in the Supported header field in the request".
>
> However, the Service Route discovery  procedure during Registration 
> described in RFC 3608 does not follow this as shown in the example in 
> Section 6.
>
> Are there any reasons for that and for the fact that there is no need 
> to define an Option Tag for Service Route?

I remember debating this at the time that RFC 3608 was being edited, but
do not recall why we ended up with the text therein. Looking at it from
the perspective of history, at the moment it appears that you're
absolutely right and that RFC 3608 is inconsistent with RFC
3261 in this respect.

I do recall that there was a decision to not provide an option-tag for
Service-Route related to the extremely "optional" nature of the
information conveyed by Service-Route, which is actually completely
orthogonal to the operation of the REGISTER request itself. We didn't
want the UAC to be able to "demand" a service-route. With some
deployment experience behind us, I'm not sure that this was really an
important issue.

Jonathan is very fond of saying that both RFC 3608 and RFC 3327 are
"broken, or at best horribly underspecified". I've been planning to rev
them once GRUU and the route-construction draft stabilize, although its
also been proposed that the route-construction draft might actually
replace both 3608 and 3327. In either case, we should address this issue
at that time.

Question to the WG: Should we post an errata for RFC 3608 to the RFC
Editor page discussing this?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Mon, 10 Apr 2006 08:49:30 -0500

> create the route, so similar text is needed for generic UA behavior.

Why must the US a route all requests through this domain? What if it has 
multiple registrations?

> a registrar to build a Service-Route set based on the received Path

Lovely idea, and 3608 suggests it as a possibility. Doesn't work for IMS 
AFAIk, so it can't be a MUST.

--
dean