Subject: RE: [Sip] Revised Service Route Discovery Draft

From: Tan Ya-Ching ICM N PG U ID A 1 <[email-masked]>
Date: Mon, 29 Apr 2002 14:23:28 +0200

| -----Original Message-----
| From: Dean Willis [mailto:[email-masked]]
| Sent: 24 April 2002 12:33
| 
| Well, the return code of the Path MAY be similar to the value of
| P-Service-Route. It might not. The Path is an exact subset of the
| traversal path of the REGISTER request. 

No, it needs not be. draft-willis-sip-path-03 states that "It is also
possible for a proxy with specific knowledge of network topology to add a
path element referencing another node, thereby allowing construction of a
Path which is discongruent with the route taken by the REGISTER request".

It is not clear to me whether the Path header and the P-Service-Route header
can co-exist in a 200 OK response to a REGISTER. If Path header exists in
the REGISTER request, the Path draft expects the registrar to reflect
accumulated Path back into the REGISTER response. The Service-Route draft on
the other hand says that the registrar may choose to return a
P-Service-Route header in any successful 200 OK response. Should the
registrar not return the Path if it wants to insert the Service-Route ?

Regards,
Ya-Ching

_______________________________________________
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, 29 Apr 2002 08:21:55 -0500

Tan Ya-Ching said:
> Dean Said:
> No, it needs not be. draft-willis-sip-path-03 states that "It 
> is also possible for a proxy with specific knowledge of 
> network topology to add a path element referencing another 
> node, thereby allowing construction of a Path which is 
> discongruent with the route taken by the REGISTER request".

Ah! Thanks for pointing that out. That paragraph is left over from an
earlier version of the draft, and needs to be deleted. My fault. Thanks
for the careful reading!

> It is not clear to me whether the Path header and the 
> P-Service-Route header can co-exist in a 200 OK response to a 
> REGISTER. If Path header exists in the REGISTER request, the 
> Path draft expects the registrar to reflect accumulated Path 
> back into the REGISTER response. The Service-Route draft on 
> P-Service-Route header in any successful 200 OK response. 
> Should the registrar not return the Path if it wants to 
> insert the Service-Route ?

They may both be present.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 29 Apr 2002 10:22:21 -0500

Ok, it's apparently my day for making stupid responses. I hope it's not
becoming a habit.

Please allow me to clarify what I meant to say (as opposed to what I
actually said, which was wrong).

A proxy adding a Path element to a REGISTER request MAY construct that
element so that it actually refers to a different proxy. It's actually
possible to do something similar in Record-Route, although I'm not aware
of any systems that have actually implemented this. 

So it is not technically correct to say that the Path is an exact subset
of traversal path of the RESGISTER. Rather, it is "usually" an exact
subset of the traversal path of the REGISTER.

But this is still very different from the value returned by
P-Service-Route.

From the UA's perspective, the Path response means "These are the
proxies that have been added to my registration, such that messages
going from my home proxy to me will visit these proxies". It deals with
UA-terminated messages, i.e., when the UA us acting as a UAS.

From the UA's perspective, the P-Service-Route response means "This is a
route set that I can combine with other routing knoweldge I may have so
that I can get services from a particular set of service proxies." It
deals with UA-originated messages, i.e., when the UA is acting as a UAC.

--
Dean

> Ah! Thanks for pointing that out. That paragraph is left over 
> from an earlier version of the draft, and needs to be 
> deleted. My fault. Thanks for the careful reading!