Subject: AW: AW: [Sip] Question on Service Route DiscoveryProcedure duringRegistration

From: "Lu, Yang, VF-DE" <[email-masked]>
Date: Tue, 25 Apr 2006 16:16:11 +0200

On Apr 25, 2006, at 8:08 AM, Paul Kyzivat wrote:
> What inconsistency is it that you are referring to?

Hi Paul
The inconsistency I referred to can be found at  
http://www1.ietf.org/mail-archive/web/sip/current/msg13858.html
Regards
Yang
Vodafone

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]] 
Gesendet: Dienstag, 25. April 2006 15:09
An: Lu, Yang, VF-DE
Cc: [email-masked]
Betreff: Re: AW: [Sip] Question on Service Route DiscoveryProcedure duringRegistration

Lu, Yang, VF-DE wrote:
>  
> Hi Dean, Christer and Paul
> 
> Thanks for extending the valuable discussions into the usage of the PATH and Service-Route in connection with IMS. 
> 
> May I also come back to the primal issue, ie, how to deal with the inconsistency between the using of the Service-Route Header at the UAS written in RFC 3608 and the UAS behavior of applying extensions when generating the response in RFC 3261.

What inconsistency is it that you are referring to?

I especially do not see what this has to do with generating responses. 
Both Path and Service-Route have to do with generating the preloaded Route header for *requests*.

The only response that has direct relevance to these is the response to REGISTER.

Or are you referring to the general issue of how to manage preloaded Route headers, as explained in draft-rosenberg-sip-route-construct-00.txt?

> As I understood from Dean's primeval response, it seems likely that there are two ways forward:
> 
> 1)	Modify 3608 by providing an option-tag for Service-Route, or
> 
> 2)	Replace both 3608 and 3327 with the route-construction draft. Are there any available concrete proposals for that now? 
> 
> If you could impart your views on choosing a way forward it would be highly appreciated.

I don't have a well formed view just yet. The following are some thoughts on the subject:

- I think it is useful/important to have a well defined set of rules
   for how routes are used and managed. The current situation is
   quite problematic.

- Something consistent that covers all the cases will be inconsistent
   with current usage of Path and Service-Route in IMS. This could be
   dealt with via a new option tag, or by deprecating both of those
   headers and defining a single new one to replace them both.

- I think it makes sense for inbound route (a.k.a. Service-Route) and
   the outbound route (a.k.a. Path) to be symmetric by default.
   But there should be some provision for them to be asymmetric in cases
   where that is useful. This could be achieved by using Path for both
   directions, but allowing the Path to be modified in the REGISTER
   response.

- Impact of 305 responses needs to be dealt with. Jonathan tried,
   but as I recall there may still have been issues. (I don't remember
   the details any longer.)

- The use (or non-use) of the "service-route" on registration
   refreshes needs to be clear. (I think it should apply to
   refreshes, but should not apply to a new register, or one send
   after the prior one timed out.)

While I don't think draft-rosenberg-sip-route-construct-00 is finished and ready to go to RFC, a reasonable way forward would be to resume work with it as a starting point.

	Paul

> Regards
> Yang
> Vodafone
> 
> 
> Best Regards
> *********************************
> *   Yang Lu @ VODAFONE GERMANY    *
> *   Tel: +49 (0)211 533 5432                            *
> *********************************
> 
> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]]
> Gesendet: Donnerstag, 20. April 2006 16:12
> An: Christer Holmberg (JO/LMF)
> Cc: [email-masked]; Dean Willis
> Betreff: Re: [Sip] Question on Service Route DiscoveryProcedure 
> duringRegistration
> 
> 
> 
> Christer Holmberg (JO/LMF) wrote:
> 
> 
>>But, I guess the most important thing is the second: IF the UA uses 
>>the Service-Route, it should be specified how the route is created.
>>
>>
>>
>>>>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.
>>>
>>>Lovely idea, and 3608 suggests it as a possibility. Doesn't work for 
>>>IMS AFAIk, so it can't be a MUST.
>>
>>I need to check that. But, is there something special you have in mind 
>>why it wouldn't work with IMS?
> 
> 
> The way IMS is organized, it is possible to have two UAs registered to the same AOR (Public User Identity), but accessing via different P-CSCFs.
> 
> The Path must include the P-CSCF so that requests can reach the intended UA via the P-CSCF it uses. That means in the two UA case there must be two Paths - one for each registered Contact. This is supported by RFC 3327.
> 
> If route-construct were used to construct the Service-Route, then there would be two different Service-Routes for the same AOR. But according to RFC 3608 there may be only one Service-Route per AOR. So the algorithm of route-construct won't work for IMS as currently defined.
> 
> I believe Jonathan has advocated a revision to RFC 3608 so that there may be a separate Service-Route for each registered contact. But there has been no action to make such a change.
> 
> 	Paul
> 
> _______________________________________________
> 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