Christer, We still seem to have a disconnect in our understanding. See below.
John > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: 16 January 2008 14:32 > 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 > > > John, > > 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. > > 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. > > Regards, > > Christer > > > > > > > -----Original Message----- > > From: Elwell, John [mailto:[EMAIL PROTECTED] > > Sent: 16. tammikuuta 2008 15:53 > > To: Christer Holmberg; [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 > > > > 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 > _______________________________________________ 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
