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