Subject: [Sip] Revised P-Service-Route header draft, please review

From: "Dean Willis" <[email-masked]>
Date: Mon, 29 Apr 2002 12:01:46 -0500

I've submitted -02 of the P-Service-Route header to internet-drafts. In
the meantime, you can get it from:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-02.txt
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-02.htm
l
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-02.xml

I think this is getting fairly close to final. Please eyeball it
carefully.

This draft is an individual informational documenting a P-header
requested by 3GPP. We'll be processing it by "expert review". Current
plans require review to be complete by May 10 or thereabouts.

Thanks,

--
Dean Willis

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 29 Apr 2002 14:22:13 -0500

> I think this is getting fairly close to final. Please eyeball it

Dean:

Some comments:

Section 1, bullet 5:
    5. Performing an operation equivalent to record-routing in a
       REGISTER transaction between the UA and the associated
       registrar, then storing that route in the UA and reusing it
       as a service route on future messages originating from the UA.
       While efficient, this constrains the service route for proxy
       operations to be congruent with the route taken by the REGISTER
       message.

I interpret the last sentence as follows:
    "While efficient, this constrains the service route for proxy
     operations to be congruent with the Route set formed at the UA
     from the Path headers in a 200 OK (REGISTER)."

On an initial read of this I-D, I thought that the Path extension may
help.  However, the problem appears to be, if we use the Path extension,
that the service route will necessarily be equivalent to the one
formed when a Path-header knowledgable UA gets back a 200 OK (REGISTER)
with multiple Paths.  At least to me, this was not immediately apparent
from the wording in bullet 5. I don't know if my suggested wording
makes it more easier to understand or not...

Also, should the Path I-D be referenced here?

Also, what happens if a 200 OK (REGISTER) has multiple Path headers
*and* a P-Service-Route header?  The I-D does provide some guidance
in Section 5.1: "In general, the service route set is appended to any
locally configured route needed to egress the access proxy chain."
I think this should be highlighted and maybe included in the examples
in Section 5.

That's all.  Thanks.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

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

>      from the Path headers in a 200 OK (REGISTER)."

Yep, that's what I meant. I was just trying not to refer to Path draft .
. .
 
> On an initial read of this I-D, I thought that the Path 
> extension may help.  However, the problem appears to be, if 
> we use the Path extension, that the service route will 
> necessarily be equivalent to the one formed when a 
> Path-header knowledgable UA gets back a 200 OK (REGISTER) 
> with multiple Paths.  At least to me, this was not 
> immediately apparent from the wording in bullet 5. I don't 
> know if my suggested wording makes it more easier to 
> understand or not...

> Also, should the Path I-D be referenced here?

I was hoping not to.

> *and* a P-Service-Route header?  The I-D does provide some 
> guidance in Section 5.1: "In general, the service route set 
> is appended to any locally configured route needed to egress 
> the access proxy chain." I think this should be highlighted 
> and maybe included in the examples in Section 5.

Then I have failed to make something clear. Path and P-Service-Route are
completely independent in specification.

The Path header reports a proxy sequence, associated with a specific
registration, that will be traversed by requests that have visited the
home service proxy associated with the registrar. This is "just so the
UA knows who's in the loop". It is not used, in any way whatsover, to
route messages out of the UA.

The P-Service-Route header provides a proxy sequence that the UA MAY use
in order to request services from a specific proxy cluster.

They MAY have some of the same values in them, just as two different
INVITES may also traverse the same proxy.

How can I make this more clear?

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 29 Apr 2002 15:34:26 -0500

> Vijay wrote:

[...]

> Yep, that's what I meant. I was just trying not to refer to Path draft .

[...]

>>Also, should the Path I-D be referenced here? 

Any idea why the reluctance?

> completely independent in specification.

Right; on closer introspection, disregard what I wrote above; I am not
debating that Path and P-Service-Route are dependent on each other.
They are not; but since Path and P-Service-Route *appear* to be doing
similar things for requests, i.e. *force* them to follow a certain path,
there is some equivalence that needs to be strongly pointed out.

 > How can I make this more clear?

Maybe something as simple as the following will do:
"The Path mechanism is applicable for requests arriving at a UA from the
home domain, and the P-Service-Route mechanism is applicable for forcing
requests from the UA to visit the home domain"

Regards,

- vijay

---

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

. . . 
> Any idea why the reluctance?

Well, it hardly seems right to make a full header dependent on a
P-header, and the full header is more debatable so I did not wish to
make them sequence the other way either. In general, normative
dependencies, especially on works not yet complete, are better when
avoided.

> requests from the UA to visit the home domain"

How about:

In Path:

"The routing established by the Path header mechanism applies only to to
requests transiting or originating in the home domain."

In P-Service-Route:

"The routing established by P-Service-Route applies only to requests
originating in the UA and transiting or terminating in the home domain."

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 29 Apr 2002 17:38:48 -0500

> dependencies, especially on works not yet complete, are better when

I see.

> originating in the UA and transiting or terminating in the home domain."

Sounds reasonable.

Thanks, Dean.

- vijay