Subject: [Sip] Question on Service Route Discovery draft and multiple contacts per AoR

From: "Dean Willis" <[email-masked]>
Date: Mon, 14 Apr 2003 13:44:31 -0500

The current text in draft-ietf-sip-scvrtdisco-03.txt says, in "6.3
Procedures at the Registrar":

   A REGISTER operation performing a Fetching Bindings (i.e.  no Contact
   header field is present in the request) SHOULD return the same value
   of Service-Route as returned in the corresponding previous REGISTER
   response for the address-of-record in question.  In some cases, the
   Service-Route may be dynamically calculated by the registrar rather
   than stored, and the decision as to whether this route should be
   recalculated in the event of a Fetching Bindings operation is left to
   the implementation.

Ben Jenkins pointed out to me that this may be unclear in cases where there
are multiple contacts registered for a specific AoR.

We do not state explicitly that the Service Route is common to all contacts
for the AoR. Is it really? Do we need to add anything here for clarity?

--
Dean

_______________________________________________
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, 14 Apr 2003 23:12:15 -0400

inline.

> for the AoR. Is it really? Do we need to add anything here for clarity?

I would be surprised if its the same. After all, the Contacts could have 
been registered from completely different visited networks. Ideally, 
there is one service route per contact, and so the REGISTER response 
would indicate a service route for each contact in the response. That 
would be a big change from whats in the spec now though.

-Jonathan R.

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

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 15 Apr 2003 12:02:36 -0500

> been registered from completely different visited networks. 

So? The Service-Route does not contain information about the visited network
-- just information about the home network -- the "specific home proxy or
network of proxies" from which services are being requested.

See the Applicability Statement:

   2.  The registrar has knowledge of a service proxy that should be
       used by the UA when requesting services from the domain of the
       registrar.  This knowledge may be a result of dynamic assignment
       or some other mechanism outside the scope of this document.
   3.  The registrar(s) has/have sufficient knowledge of the network
       topology, policy, and situation such that a reasonable service
       route can be constructed.

Since one can reasonably assume that the registrar has NO explicit knowledge
about the foreign/visited network from which the UA registered, the service
route does not contain data about that network. Clearly the UA and the
visited network have enough routing data to be able to get a REGISTER
request to the edge of the home network (since we're building this route in
the response to that REGISTER request).

> Ideally, 

True. There MIGHT be a difference on the preferred route through the home
network depending on which visited network (and consequently, Contact) is
involved. One can envision using a Service Route-like mechanism to assign a
firewall proxy on a per-contact basis. Such an approach is not supported in
the current draft, which we might point out has completed WGLC and IETF LC
and probably shouldn't be changed (especially substantively) unless there's
a glaring error.

At about this point I should say "Gee, it would have been nice to be able to
use a loose-routing syntax in the actual Contact value (and in fact
everywhere that a URI is given), but that wouldn't have been backward
compatible."

Open Question: Is the additional capability being proposed here important
enough to change the spec at this time, or is it something we should
consider in future work?

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Apr 2003 02:57:36 -0400

inline.

> the response to that REGISTER request).

My bad. You're right. I think I had Path in mind.

> enough to change the spec at this time, or is it something we should

I think we can consider it in the future. You just need to be clear in 
the draft that there is ONE service route across all registered contacts.

Thanks,
Jonathan R.

---

From: Erkut CULLUOGLU <[email-masked]>
Date: Wed, 16 Apr 2003 10:09:39 +0200

just an idea  -> inline

>the response to that REGISTER request).
So we can expect that an Invite request will still be able to arrive to 
the edge-proxy. If we keep the edge-proxy out of the service-route, 
wouldn't it  make the service route for a AoR identical for any
number of contacts? Teorethically isn't it correct to claim that for 
each AoR we'll have the same
route within the home network,  if we can just take out the edge-proxy?

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 16 Apr 2003 16:17:53 -0500

Erkut asked:
---------------------
 So we can expect that an Invite request will still be able to arrive to the
edge-proxy. If we keep the edge-proxy out of the service-route, wouldn't it
make the service route for a AoR identical for any 
number of contacts? Teorethically isn't it correct to claim that for each
AoR we'll have the same
route within the home network,  if we can just take out the edge-proxy?
 ---------------------
 
Yes, I think that's what I was trying to say.
 
The question is, is it worth adding this clarification to the current draft?
It coulod be done in Auth-48 with AD approval -- it's not really a technical
change, I believe, but it is a substantive clarification.
 
--
Dean