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

>>According to the UA-loose-route draft, every proxy in the path need to

>>support the mechanism in order for the "current target" to be retained

>>in the R-URI. A good example is the "Service Invocation" use case in 
>>the UA loose route draft.
>[JRE] The Service Invocation section in loose-route tells me 
>nothing about proxies on the path. It simply talks about 
>invocation of a service at the UAS.

This is what the loose draft says:

"5. Proposed Solution

   The proposed solution is simple.  When handling a request, a proxy
   only rewrites the Request-URI when performing a retargeting
   operation.  If, instead, the proxy is trying to route the request via
   some entity (whether its a proxy or UA) to reach the target, the
   Request-URI is retained, and Route header fields are pushed into the
   request to reach the target.

etc."

This applies to ALL proxies on the path, otherwise one will not always
find the current target (service invocation uri) in the Request-URI. 
 
>>Maybe the "loose route" wording is confusing (I think it is also 
>>mentioned in the UA-loose-route draft that a better naming may be 
>>needed)?
>> 
>>Also, maybe one can assume that a home proxy knows what entities not 
>>registering (MGCs etc) support. But, again, we are not only talking 
>>about home proxies.
>[JRE] Surely it is only the home proxy that takes an AoR and determines
a contact URI to route to. Maybe my understanding of home proxy is
different.

So, what is your understanding?

Regards,

Christer




> > 
> > > -----Original Message-----
> > > From: Elwell, John [mailto:[e-mail]]
> > > Sent: 16. tammikuuta 2008 15:53
> > > To: Christer Holmberg; [e-mail]
> > > 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
> > > 
> > > 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:[e-mail]]
> > > > Sent: 16 January 2008 11:51
> > > > To: Elwell, John; [e-mail]
> > > > 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:[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
> > 
> 


_______________________________________________
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