Christer Holmberg wrote:
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.
In theory it is a problem. Its not at all clear that it is a problem in
practice. That depends on whether this *will* be known in the places
where the mechanism is used.
AFAIK the loose route draft requires that the behavior of the next hop
*be* known before the mechanism is used. So raising issues based on
problems if it is used inappropriately are not valid. What *would* be
valid are places where the mechanism is not used because support it not
known, resulting is less functionality. I remain to be convinced there
are any such cases.
So I think these two mechanisms are getting close to be just being in a
beauty contest.
I think the crucial point in both of these is deciding when you are
retargeting vs rerouting.
Paul
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
