Subject: [Sip] GRUU record-routing

From: [email-masked]
Date: Mon, 26 Jun 2006 17:58:08 -0400

I fear that I'm rushing in angels fear to tread, and I admit that I've
been busy and not paying close attention to the discussions for the
last six months, but I've saved and reviewed a lot of the discussion,
and I think that I've not seen a full discussion of the solution to
the "edge router" problem given in section 8.2.2 of
draft-ietf-sip-gruu-09.txt:

   8.2.2.  Record-Routing

   The proxy that accesses the location service (called the home proxy
   here) MUST record-route under two circumstances.  Firstly, if the
   home proxy receives a dialog forming request from a UA in its own
   domain (an originating request) whose Contact header field contains a
   GRUU (indicated by the presence of the "gruu" URI parameter), the
   proxy MUST record-route.  Secondly, if the home proxy receives a
   dialog-forming request targeted to an AOR or GRUU within the domain
   of the home proxy (a terminating request), and it translates the
   Request URI into a contact that is associated with an instance ID to
   which a GRUU has been assigned, the proxy MUST record-route.  The URI
   placed into the record-route MUST cause the request to be routed to a
   proxy that can access the location service for that user.

A couple of questions come to mind:

- It seems to me that the home proxy could avoid record-routing a
  terminating request if it knows that no further proxy to the
  ultimate UA will record-route.  Similarly, a home proxy could avoid
  record-routing an originating request if there are no preceding
  record-routes on the request.  (In either case, the request would be
  processed in the same way as is now prescribed by 8.2.2/8.2.3.)  So
  these requirements don't *have* to be MUST-strength.

- For 8.2.2 to have the desired effect for originating requests, it
  seems we must require that if any previous proxy record-routes
  itself, then the request must go through a home proxy for
  record-routing before going on to the greater Internet.  (That is
  necessary, but not implied by the other SIP rules, in some weird
  cases.  E.g., if the home proxy and the Internet-side interface of
  the edge router are globally addressable, but the UA-side interface
  of the edge router is not globally addressable.)  So I think an
  additional MUST is needed here.

Maybe this has already been explicated.  But even if it has, it might
help the reader to put in a few sentences of explanation.

Dale

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Jun 2006 20:44:34 -0400

inline.

>   these requirements don't *have* to be MUST-strength.

The trick is the little oracle function which requires the proxy to know 
two things, (1) that no downstream proxy is going to record-route, and 
that (2) the UA is going to insert a gruu into the contact. The last one 
in particular has been troubling to gaurantee.

Since, when there is a gruu, the request is GOING to hit the home proxy 
anyway, it makes sense to have it always record-route.

>   additional MUST is needed here.

That is a good point; the spec is assuming originating requests will go 
through the home proxy. Things work fine if any of the proxies on the 
record-routing chain in the outbound direction are capable of 
translating the GRUU.

I put these words into section 8.2.2:

<t> The proxy that accesses the location service (called the home
proxy here) MUST record-route under two circumstances. Firstly, if the
home proxy receives a dialog forming request from a UA in its own
domain (an originating request) whose Contact header field contains a
GRUU (indicated by the presence of the "gruu" URI parameter), the
proxy MUST record-route. This, of course, assumes that the home proxy
is in the request path for such originating requests. If it is not,
some other proxy on the request path MUST generate a record-route
which will route to the home proxy. A home proxy can use mechanisms
such as Service-Route <xref target="RFC3608"/> or UA configuration to
ensure that it is on the outgoing request path.
</t>

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: [email-masked]
Date: Tue, 27 Jun 2006 14:40:23 -0400

From: Jonathan Rosenberg <[email-masked]>

You're looking at solving routing problems even when the UAS isn't
using a GRUU as its Contact value.  I hadn't thought of that.

For instance, the proxy might know that the UA's registered contact is
globally routable.

I see your point -- avoiding record-routing in the circumstances where
it isn't strictly necessary isn't likely to save much work.

What gives me pause is that this is a requirement on the UAs, that
they use an "outbound proxy", but we haven't stated it explicitly as
such.

   A home proxy can use mechanisms such as Service-Route <xref
   target="RFC3608"/> or UA configuration to ensure that it is on the
   outgoing request path.

Should we require that proxies/UAs implement RFC 3608?

If the proxy does not provide a Service-Route, should we require that
the UA send the request to the service address for the domain in the
GRUU it is using as its Contact?

Dale

---

From: [email-masked]
Date: Tue, 27 Jun 2006 18:22:21 -0400

From: "Rohan Mahy" <[email-masked]>

   While I hope that eventually they willl start using the SIP
   configuration framework to get this kind of information, I am fine
   with them continuing to user service-route.

Isn't the configuration framework less standardized than
Service-Route?

Dale

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 27 Jun 2006 14:56:17 -0700

> GRUU it is using as its Contact?

Hi,

I think requiring RFC 3608 is a terrible idea.  There is a community
that is using service-route today. While I hope that eventually they
willl start using the SIP configuration framework to get this kind of
information, I am fine with them continuing to user service-route.  I
don't want service-route leaking out into the rest of the Internet
however.

thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 29 Jun 2006 14:54:17 -0700

Yes, but the configuration framework is more flexible and more
generally useful. The configuration framework can become more
standardized, but the Service-Route can't get any more useful.  ;-)

thanks,
-rohan

---

From: [email-masked]
Date: Thu, 29 Jun 2006 22:02:54 -0400

Too true.  But I see the choice as a fig leaf that is *sufficient*
from a whole wardrobe that is currently incompletely specified.

What's itching me is that draft-ietf-sip-gruu-09 requires "outbound
proxy" behavior.  Currently that behavior is (IMO) not directly
specified.  One way to specify it would be to require that UAs
implement Service-Route and that registrars deliver appropriate
Service-Routes.  That provides the needed behavior and specifies the
interaction between the UA and the registrar in an interoperable way.
The alternative is to leave the method by which the outbound proxy is
communicated to the UA outside SIP (since the *content* of the
configuration framework data objects is not specified), but that seems
to make it impossible to make a UA that can in practice implement GRUU
without proprietary knowledge of how it is going to determine the
outbound proxy.

Of course, I may be overlooking something here.

In any case, I think the resolution of this matter should be spelled
out in adequate detail in the I-D.

Dale