Christer, 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.
John > -----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
