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

["Christer Holmberg" <[e-mail]>]

Hi Paul, 

>>>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.

I don't think it's a theoretical problem.

You may have next hop entities in different domains, belonging to
different operators, assigned dynamically for each call (using DNS, load
sharing etc), being updated with more/less capabilities very frequencly
etc etc etc. So, I think there are lots of scenarios where it will
simply be impossible for an entity to know what the next physical hop
will support.

Yes, an UA can indicate to its home proxy what it supports, but again I
think it is important that we are not only talking about home proxies.

And, if we are going to start making protocol design based on the fact
that entities know what other entities support, why do we need
option-tags, why do we need Require, why do we need SDP? Why don't we
just assume everything is provisioned...

I thought the idea behind SIP, and the whole internet model, was to NOT
rely on provisioning.

>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.

Again, the examples are just there to explain the limitation.

Also, the issue about possible services that may break is not related to
inappropriately use of the mechanism. The entity that does trigger the
service relying on the mechanism may very well know that the next hop
supports it. But, the hop after the next hop, and/or the hop after the
hop of the next hop, may not support it. So, somewhere in the chain the
service relying on the mechanism will be "broken" - even if the hop that
doesn't support the mechanism has nothing to do with the service as
such.

We think that limits the usability of the mechanism (again it has
nothing to do with inappropriately use of the mechanism).

>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.

Yes, I agree. We should get a clear defintion, once and for all.

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