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

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

Hi Paul, 

>>>>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.

[CHH] Ok. So, it's more an RFC issue than an IMS issue.

>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.

[CHH] I guess that change would have to be done together with the other
change(s).

Regards,

Christer

_______________________________________________
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: Fri, 21 Apr 2006 13:58:11 -0500

> [CHH] Ok. So, it's more an RFC issue than an IMS issue.

Not exactly. I believe the IMS Path is discongruent from the IMS  
Service-Route, specifically in the inclusion of P-CSCF in one (path)  
but not the other (s-r). Then again, it's been a few years since I  
looked at that part of the IMS spec.

So a simple inversion doesn't work.

--
Dean