Re: [Sip] RE: Delivering request-URI and parameters to UAS via proxy -new version of the draft-holmberg-sip-target-uri-delivery draft

[Paul Kyzivat <[e-mail]>]

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:[e-mail]]
>>> Sent: 16 January 2008 11:06
>>> To: Elwell, John; [e-mail]
>>> 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:[e-mail]]
>>>>> Sent: 16 January 2008 08:41
>>>>> To: [e-mail]
>>>>> 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 
>>> [e-mail] for questions on current sip Use 
>>> [e-mail] 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 
>> [e-mail] for questions on current sip 
>> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip