[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
Hi,
We had a looooong discussion about that (ua-loose-route vs Target), and I really hope we should not go back there now.
I think we should focus on whether we want to have this in H-I, as currently proposed, or as a separate header.
Regards,
Christer
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Elwell, John
> Sent: 11. maaliskuuta 2009 13:32
> To: Hadriel Kaplan; Shida Schubert; sip at ietf.org
> Cc: Mary Barnes
> Subject: 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
> >
> _______________________________________________
> 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
>