Sorry for jumping in late here. Trying to clarify some points here and
there.
The UA-loose mechanism needs to know that the entity which would have
previously been reached by the DNS/IP forwarding based on the R-URI, is
now prepared for a request which reaches it with that target in the
Route header field.
In the case of a UA registering through a chain of Path-inserting
proxies, it means that only the *UA* has to support UA-loose route.
Thats because of the assumption that the intermediate path-inserting
proxies weren't being targeted based on the R-URI previously; they were
(and still will) forward the request based on Route.
The 'next hop' use case that Christer is referring to are cases where we
would have done a R-URI translation without a registration. For example,
lets say a proxy receives an INVITE with sip:[EMAIL PROTECTED], and its
using some number-prefix based routing rules, which have been CONFIGURED
into the proxy, to determine a next-hop gateway. The UA loose route
rules would say that, since this is a routing operation and not a
retargeting, the request looks like:
INVITE sip:[EMAIL PROTECTED]
Route: sip:ip-of-gateway
whereas current rules would require:
INVITE sip:[EMAIL PROTECTED]
in this use case, the entity which was previously being reached by the
R-URI *is* the next hop.
And so, the main limitation that I see of the UA loose route mechanism
is, in cases where the next-hop is being reached via a configured
routing rule, or by some other non-registration means, and said
operation is a re-route and not retarget, the UA_loose-route requires
that this configured routing rule include information about whether the
next hop uses UA loose routing, and if so, what URI to use in the Route
header.
This is a limitation, I agree. Whether its significant or not is debatable.
I will note that, it is possible to separate these concerns. We could
define UA loose route to strictly be used for the registration cases,
since that is the specific problem at hand.
I agree CHrister's mechanism does not have this configuration
limitation, and that this aspect of it is better. My main beef, as
others have commented, is that it leaves us with nearly half-dozen
header fields which are all awfully similar (To, P-C-ID, Route,
History-Info, and now Target). I was hoping to reduce the set and
include only the minimum. In that way, I think UA loose route is
architecturally better since it gives some clarity to this.
-Jonathan R.
Elwell, John wrote:
Christer,
I don't think the entity using the mechanism needs to know about next
hop support for the loose route mechanism - only whether the UAS
supports it. If the UA registers, then the loose route draft provides an
automatic mechanism. If the UA does not register, support would need to
be indicated by provisioning. I am not sure this ranks as a significant
limitation, since a certain amount of provisioning needs to be done
anyway for UAs such as gateways that do not register.
John
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED]
Sent: 16 January 2008 11:51
To: Elwell, John; [email protected]
Cc: Paul Kyzivat; DRAGE,Keith (Keith); Francois Audet
Subject: RE: [Sip] RE: Delivering request-URI and parameters
to UAS via proxy -new version of the
draft-holmberg-sip-target-uri-delivery draft
Hi,
I hear what you are saying, but I don't really see that the
points you
raised in section 4 are real limitations of the loose route mechanism.
I think it is a limitation that an entity using the mechanism has to
know whether the the next hop supports it or not, and that
the mechanism
can only be used if the subsequent hops support it.
Regards,
Christer
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED]
Sent: 16 January 2008 11:06
To: Elwell, John; [email protected]
Cc: Paul Kyzivat; DRAGE, Keith (Keith); Francois Audet
Subject: [Sip] RE: Delivering request-URI and parameters
to UAS via
proxy - new version of the draft-holmberg-sip-target-uri-delivery
draft
Hi John,
Thanks for this revision, which makes things somewhat
clearer. I do
have a couple of comments:
1. I am not sure I agree with the assertions in section 4
concerning
issues with the mechanisms in loose-route. Taking example 1, the
Route header field should contain enough entries to get
you to the
registered contact, not just to an intermediate proxy.
Therefore this
situation should not arise with a correctly implemented
home proxy.
It is not clear to me how example 2 could arise either,
for similar
reasons. The MGC case can be resolved by taking into account the
option tag in the REGISTER request, or if it is permanently
registered, through provisioning.
The examples are not meant to show bugs in the loose-route
mechanism.
They are meant to help people understand the limitations with the
loose-route mechanism.
2. Comparing the mechanism proposed with the loose-route
mechanism,
my understanding is:
a)When retargeting occurs, the loose-route mechanism
places the new
target in the Request URI. Your proposal places the new
target in
both the Request-URI and the Target header field.
b) When rerouting, the loose-route mechanism places the
new route
(i.e., the registered contact) in the Route header field. Your
proposal places the new route in the Request-URI (the
latter as per
RFC 3261).
So the two mechanisms solve exactly the same problems using a
slightly different mechanism. Correct?
Yes. The two solutions intend to solve the same problem.
3. How P-Called-Party-ID fits into this is not really
relevant from
an IETF perspective - it seems there are some 3GPP-specific
situations where the contents of P-Called-Party-ID will
not equal the
contents of Target. Correct?
Correct.
4. If my suggestion in point 1 above that the loose-route
mechanism
does not suffer from the problems suggested, then each
mechanism will
work and each addresses the same problem.
So it is just down to a beauty contest between the two. Correct?
See question 1.
We believe that our solution does not have the same
limitations as the
loose-route solution. But, again, both solutions intend to
solve the
same problem.
Regards,
Christer
-----Original Message-----
From: Christer Holmberg
[mailto:[EMAIL PROTECTED]
Sent: 16 January 2008 08:41
To: [email protected]
Cc: DRAGE, Keith (Keith); Paul Kyzivat; Elwell, John;
Jeroen van
Bemmel; Francois Audet
Subject: Delivering request-URI and parameters to UAS via
proxy - new
version of the draft-holmberg-sip-target-uri-delivery draft
Hi,
We've uploaded a new version (-01) of the Target draft.
We've tried to make things more clear. I've also
removed all text
about P-Called-Party-ID, except from one chapter where
we try to
explain the semantical difference between Target and P-CPI.
You can also find the draft from:
http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-targ
et-uri-del
ivery-01.txt
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 PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
