Just to expand on what Hadriel says, the SIP Forum is addressing the case where a request is delivered by a SIP Service Provider to a SIP-PBX, the SIP-PBX having registered with the SIP-SP. The SIP-PBX needs to be in possession of the target, in order to route onwards correctly within the enterprise. If only the SIP-PBX's contact URI is available in the Request-URI, the SIP-PBX would have to look elsewhere for the target. In accordance with recent SIP WG agreements, this would be the History-Info header field, but that requires the present extension.
Advantages of putting the target in the Request-URI for this particular situation: - This is where the SIP-PBX would normally expect to find the target when a request is received from elsewhere (e.g., another SIP-PBX within the enterprise), so it is reasonable also to expect it there when received from a SIP SP. - SIPConnect 1.1 will not require History-Info for any other purpose, so it would make it a mandatory specification for SIPConnect 1.1 just in order to solve this particular problem, thereby raising the bar for SPs and SIP-PBXs wanting to comply with the spec. - We would need to define procedures for what to do if History-Info is absent from a received request or if there is no entry marked as 'istarget'. - SIPConnect 1.1 is due for completion in the next few weeks, and cannot wait the usual IETF cycle time for History-Info update to hit the RFC Editor's queue. - If History-Info is used anyway (for its original purpose), the history revealed when a request comes from a SIP-SP via a SIP-PBX to another proxy and finally to a UAS would be unnecessarily complicated and therefore confusing, because the target would be replaced by a contact and would then appear again at the next hop. John > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Hadriel Kaplan > Sent: 11 March 2009 06:55 > To: Shida Schubert; [email protected] List > Cc: Mary Barnes > Subject: Re: [Sip] Fwd: I-D > ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > > > At the risk of opening up a topic we have already agreed on, > but in the spirit of open communication... [how's that for an > opener!?] > > Are we absolutely sure we want to put this target-URI in the > History-Info header? > > I am not asking this because I think it's hard. I am asking > because I am not sure it will be used. Several of us from > this same WG are involved in the SIP-Forum's SIP-Connect > profile, and when faced with either using this new > History-Info mechanism for a target-uri delivery issue, vs. > not, we chose not to. And we were mostly the same people who > liked the idea of putting it in History-Info in the IETF! > (myself included) But I am concerned that when given a > reasonable opportunity to use a mechanism we ourselves > promote when wearing a different hat, we chose not to use it > in practice. It doesn't bode well. :( > > -hadriel > p.s. sorry Mary for raising this, but there isn't much email > traffic anyway. :) > > ________________________________________ > From: [email protected] [mailto:[email protected]] On > Behalf Of Shida Schubert > Sent: Wednesday, March 11, 2009 2:13 AM > To: [email protected] List > > We have submitted the updated target-uri draft based on the comments > submitted to the list and comments received at IETF73. > > I have taken over as editor as Jonathan didn't have the cycles to > update the draft, with Francois, Christer and Hans Erick as > additional > co-authors and great deal of help from Mary. > > The following summarizes the changes made to the target-uri document > 1. Added use-case for toll-free number back > 2. Added definition of "retarget" operation. > 3. Removed a reference to URN > 4. Added a text discussing the difference to P-Called-Party-Id > 5. Changed parameter name from "target" to "istarget" > > Note, that the target-uri document still contains the > normative text for the > History-Info header. > > In addition, Mary (with Francois as co-author) has submitted a > rfc4244bis, with the following changes: > 1. Incorporated the normative aspects of the target-uri document > into the existing normative text in RFC 4244 - the functionality is > virtually identical (as is some of the text) as the HI based solution > described in the target-uri document. It's important that > the solution > be integrated into RFC 4244 as it MUST work and be based on > the normative > aspects of RFC 4244. > 2. Added the use cases from target-uri the the summary > in the overview of rfc4244bis. > 3. Added an additional requirement to capture the > "target-uri" information. > 4. Fixed an error in the RFC 4244 ABNF and added "retarget" parameter. > 5. Added a more simplified example. > > > We had some very long offline exchanges as to the best way forward and > remaining work for both documents. > > Some of the issues identified are: > > ::Issues:: > 1. Should we remove the normative text from target-uri and progress > 4244bis along with the target-uri document to meet the > chartered > SIP WG milestone? > > > 2. Name of the parameter. > At the last meeting, parameter "target" was said inappropriate > because voicemail-uri spec already defines a parameter called > "target" which also can be found in hi-entry, thus potentially > causing confusion. > > Currently the target-uri draft uses "istarget" and 4244bis uses > "retarget" but we could never come to > a consensus on what name is appropriate. Other suggestions have > included the following: > "target-identity" (someone didn't like that "identity" > is also a SIP header) > "reg-uri" (can be paired with "mapped-uri" for item 3 below) > "aor" > "jibberish" > etc. > > One reason this is so difficult relates to the problem > statement in target-uri in that > RFC 3261 doesn't differentiate the mechanism by which the new > (target) Request-URI is selected. Another issue is > that some of the terminology in > RFC 3261 is overloaded - e.g., "forwarding" refers both > to a Proxy > which does not have responsibility for the domain of > the request-URI > in the incoming request, thus the proxy just "forwards" > the request to > the next hop AND "forwarding" is used to describe the > process whereby > the outgoing request is built and "forwarded" to the > next hop at which > point the proxy does not know how the new request-uri > was selected. > RFC 4244 has attempted to clarify the terms and > attempts to use "forward" > in the context of the former situation and "retarget" > for the case whereby > a proxy is responsible for the domain and thus can use > a number of > mechanism to select the new target for the request - > e.g., a REGISTRAR, > configured data, etc. > > 3. Related to the last point in item 2 above, it has been > proposed that > we differentiate the hi-entries even more by defining > separate parameters > for registered and configured/mapped contacts. > Currently when the R-URI is translated to a URI which is > either derived > from location service lookup(registered by UA) or from mapping > table, there is no differentiation as to how the URI was > derived once it is > added to the list of potential targets. > > The general consensus of the authors of the two > documents was that it may > be useful for some services to have the hi-entries > tagged with the > more specific information. > > And, of course, this gets us into another naming > contest. In the end, the naming > is not so important as long as the term isn't too > overloaded and it is defined > precisely in the document(s). > > We would appreciate WG feedback on these issues and any other > comments on > the two documents prior to IETF-74. > > Regards, > Shida and Mary. > > > > Begin forwarded message: > From: [email protected] > Date: March 10, 2009 2:30:01 AM JST > To: [email protected] > Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt > Reply-To: [email protected] > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Delivery of Request-URI Targets to User Agents > Author(s) : J. Rosenberg, H. van Elburg, C. > Holmberg, F. Audet, S. Schubert > Filename : draft-rosenberg-sip-target-uri-delivery-01.txt > Pages : 16 > Date : 2009-3-9 > > When a Session Initiation Protocol (SIP) proxy receives a request > targeted at a URI identifying a user or resource it is responsible > for, the proxy translates the URI to a registered or configured > contact URI of an agent representing that user or resource. In the > process, the original URI is removed from the request. Numerous use > cases have arisen which require this information to be delivered to > the user agent. This document describes these use cases and defines > an extension to the History-Info header field which allows it to be > used to support those cases. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rosenberg-sip-target -uri-delivery-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain<BR>Content-ID: > <[email protected]><BR><BR> > _______________________________________________ > I-D-Announce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > Sip mailing list https://www.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://www.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
