[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Fwd: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: 11 March 2009 06:55
> To: Shida Schubert; sip at ietf.org 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Shida Schubert
> Sent: Wednesday, March 11, 2009 2:13 AM
> To: sip at ietf.org 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: Internet-Drafts at ietf.org
> Date: March 10, 2009 2:30:01 AM JST
> To: i-d-announce at ietf.org
> Subject: I-D ACTION:draft-rosenberg-sip-target-uri-delivery-01.txt
> Reply-To: internet-drafts at ietf.org
>
> 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:
> <2009-3-9102756.I-D at ietf.org><BR><BR>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce at ietf.org
> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>