Re: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01

["Elwell, John" <[e-mail]>]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: 17 March 2011 21:17
> To: Elwell, John; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [sipcore]
> I-DAction:draft-mohali-sipcore-reason-extension-application-01
>
> Hi John,
>
> > -----Message d'origine-----
> > De : Elwell, John [mailto:[e-mail]]
> > Envoyé : jeudi 10 mars 2011 17:01
> > À : MOHALI Marianne RD-CORE-ISS; [e-mail]
> > Cc : [e-mail]; [e-mail]
> > Objet : RE: [sipcore]
> > I-DAction:draft-mohali-sipcore-reason-extension-application-01
> >
> > I have already commented that this sort of usage of H-I is
> > appropriate only for closed networks.
> [MM] Correct.  The draft extends the Reason header not only
> for H-I case, but also for *normal* use of Reason header field.
> >
> > In addition to that, what I seem to be hearing is that the
> > UAS needs to look at H-I to determine how the request
> > arrived, and in particular whether it arrived because of
> > retargeting due to premium rate (for example). Am I correct so far?
> [MM] The UAS should be itself a service using this
> information. It is not considered as a need for the UAS, but
> as an enhanced feature for the service and the customers.
> >
> > The whole concept behind 4244bis is that the UAS, in order to
> > discover how a request arrived, scans back through the
> > hi-entries looking at the parameters. So far we have two such
> > parameters: "rc" and "mp". Marianne seems to be asserting
> > that these two parameters are insufficient, and that other
> > information in the hi-entries needs to be viewed in order to
> > determine that retargeting due to premium rate (for example)
> > took place. However, the proposed solution is to add this in
> > the "headers" component of the URI concerned, rather than add
> > a new hi-entry parameter. So the UAS, in order to analyse the
> > history of the request, now has to scan for both hi-entry
> > parameters AND URI headers. I don't understand why hi-entry
> > parameters are not proposed for such applications. Having
> > said that, we had a longgggg discussion trying to hammer out
> > the set of hi-entry parameters that we really needed, and the
> > final consensus was just to have "rc" and "mp". I would not
> > want to open up that discussion again, but on the other hand
> > using a  different mechanism for solving a similar problem
> > seems inappropriate.
> [MM] UAS already has to scan URI headers to apply Privacy or
> to find the call forwarding reason (according to 3GPP 24.604).
> "rc" and "mp" could be usefull but are not sufficient for
> enhanced supplementary services needs. I expressed the need
> for applications when discussion started for "rc" and "mp"...
> About having a H-I parameter, I'm not against it. The cons is
> that it may not be possible to have this application-specific
> reason for SIP responses and other SIP methods where Reason
> header field can be used.
[JRE] This does not fully address the point I was making. I was making the point that to find the particular hi-entry you are interested in you need, at present, to scan hi-entries looking at their parameters - you do not need to look at the URIs in those hi-entries and the URIs' "headers" components in order to find the hi-entry you are looking for. Of course, once you have found the hi-entry you are looking for, you will be interested in the URI and in anything attached to it, including Privacy and Reason header fields within its "headers" component. The draft under discussion seems to change that principle so that in order to find the hi-entry you are looking for you need to look inside the URIs. This seems to me like a change of principle - the logic of including the proposed application information in the URI as a header field, rather than in hi-entry parameters, is not at all clear to me.

John


>
> Marianne
> >
> > John
> >
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of
> > > [e-mail]
> > > Sent: 07 March 2011 18:30
> > > To: [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > Subject: Re: [sipcore] I-DAction:
> > > draft-mohali-sipcore-reason-extension-application-01
> > >
> > > Paul,
> > >
> > > I think that Christer's draft (proxy-feature) is about
> capabilities
> > > while this one (reason-extension-application) is about
> what really
> > > happened (like reason in general). It is provided only when
> > the event
> > > happens and the purpose is to give an accuate information for
> > > applicative events.
> > >
> > > Let me give you an other example:
> > > A reception AS called with several premium rate numbers (1
> > per hosted
> > > application/service). The AS dispatches calls to several
> > call centers
> > > (eg. Depending on charge, hour of the day/night...). The final
> > > destination needs to know the called service. The premuim
> > rate number
> > > should be listed in the H-I header. Which entry? For which
> > > application/service invocated?
> > > As you can have a call forwarding reason associated to a
> 3xx or 486
> > > Reason-cause, you could have an applicative reason to
> > easily identify
> > > the premium rate dialed number.
> > >
> > > Regards,
> > > Marianne
> > >
> > >
> > > > -----Message d'origine-----
> > > > De : Paul Kyzivat [mailto:[e-mail]] Envoyé :
> > lundi 7 mars
> > > > 2011 01:42 À : MOHALI Marianne RD-CORE-ISS Cc :
> [e-mail];
> > > > [e-mail] Objet : Re: [sipcore] I-DAction:
> > > > draft-mohali-sipcore-reason-extension-application-01
> > > >
> > > > Marianne
> > > >
> > > > On 3/4/2011 11:59 AM, [e-mail] wrote:
> > > > > Hi Paul,
> > > > >
> > > > > My answer below [MM]
> > > > >
> > > > > Marianne
> > > > >> -----Message d'origine-----
> > > > >> De : Paul Kyzivat [mailto:[e-mail]] Envoyé :
> > > > jeudi 3 mars
> > > > >> 2011 18:31 À : MOHALI Marianne RD-CORE-ISS Cc :
> > > [e-mail];
> > > > >> [e-mail] Objet : Re: [sipcore]
> I-DAction:
> > > > >> draft-mohali-sipcore-reason-extension-application-01
> > > > >>
> > > > >> Marianne,
> > > > >>
> > > > >> On 3/3/2011 11:51 AM,
> [e-mail] wrote:
> > > > >>> Hi Paul,
> > > > >>>
> > > > >>> The purpose is to allow applications/services to be
> > > > >> explicitely identified in the signaling path, so that others
> > > > >> services/applications/telephony-AS can act accordingly.
> > > > >> Either to apply a process taking into account the service
> > > > interaction
> > > > >> or on the contrary, do not execute a feature already
> > > > covered by the
> > > > >> application.
> > > > >>> For instance, a caller with a prepaid service calls a
> > > > >> directory enquiries Server to ask for a restaurant phone
> > > > number. The
> > > > >> operator would suggest to connect the caller to the
> > > > researched phone
> > > > >> number EXCEPT if the caller has a prepaid service because
> > > > it is not
> > > > >> sure he has enough credit to pay for the communication. To
> > > > allow this
> > > > >> customized feature, the directory enquiries Application
> > > > needs to know
> > > > >> that the prepaid Application has been invocated.
> > > > >>
> > > > >> So once again, we are back to your wanting to use
> > Reason not to
> > > > >> express a "reason" for anything, but rather as just a
> > > hook to hang
> > > > >> something on H-I.
> > > > > [MM] The *reason* why the call has been
> > > > retargeted/rejected/modified is the invocation of a specific
> > > > application.
> > > > > If you call a Service number and then the URI is changed
> > > > for routing to the real destination, the *reason* of the URI
> > > > modification (listed in H-I) is the application.
> > > >
> > > > Based on your other replies, this is not necessarily so.
> > > >
> > > > In fact the example above is a counter-example.
> > > > The prepaid service is not responsible for any
> > redirection, and the
> > > > operator service is looking for it for a reason other
> > than that it
> > > > has been the cause of anything. Its looking for it
> > because it might
> > > > be the cause of something in the future.
> > > >
> > > > >> (With the causes you have defined, I can't imagine it making
> > > > >> *any* sense to actually use one in a Reason header in
> > a message,
> > > > >> because they aren't specific enough to be actionable.)
> > > > >>
> > > > >> I am now thinking there is a large overlap between
> > what you are
> > > > >> trying to accomplish this way, and what Christer is
> trying to
> > > > >> accomplish with draft-holmberg-sipcore-proxy-feature.
> > > > >>
> > > > >> Is that true?
> > > > >>
> > > > >> (Christer: What do you think?)
> > > > > [MM] I don't see the overlap with Christer's draft because
> > > > it is not about capabilities, it is about what's happened.
> > > >
> > > > In your example above, it seems that the operator service
> > is looking
> > > > for the prepaid service because the prepaid service has the
> > > > capability to influence billing, or something like that.
> > This seems
> > > > at least somewhat in line with what Christer is
> > advocating. Looking
> > > > in the Route header, or Record-Route header would make at
> > least as
> > > > much sense for this case as looking in H-I. H-I makes
> > sense if you
> > > > are indeed looking for something that has already
> > happened, perhaps
> > > > on a path other that the current one.
> > > >
> > > > I think it would be helpful for the two of you to come to some
> > > > reconciliation of what you are trying to accomplish.
> > > >
> > > >         Thanks,
> > > >         Paul
> > > >
> > > > >>> About your comment in case of several applications involved
> > > > >> *simultaneously* in the call establishment, it is possible
> > > > to add 1
> > > > >> more hi-entry for the second application Cause you
> want to be
> > > > >> identified in the signaling path.
> > > > >>
> > > > >> Sure, you can indicate that they are "involved". But you
> > > > can't infer
> > > > >> anything about which one "caused" something. They might
> > > > have, but you
> > > > >> can't tell it from the presence of these headers.
> > > > >>
> > > > >>      Thanks,
> > > > >>      Paul
> > > > >>
> > > > >>> Regards,
> > > > >>> Marianne
> > > > >>>
> > > > >>>
> > > > >>>> -----Message d'origine-----
> > > > >>>> De : [e-mail]
> > > > >>>> [mailto:[e-mail]] De la part de Paul
> > > > >> Kyzivat Envoyé :
> > > > >>>> mardi 1 mars 2011 00:16 À : [e-mail] Objet : Re:
> > > > [sipcore]
> > > > >>>> I-DAction:
> > > > >>>> draft-mohali-sipcore-reason-extension-application-01
> > > > >>>>
> > > > >>>> (As individual)
> > > > >>>>
> > > > >>>> Marianne,
> > > > >>>>
> > > > >>>> I'm still struggling to make sense of this in the form
> > > proposed.
> > > > >>>>
> > > > >>>> I look at the various cause values, and all the
> > > > >> descriptions are of
> > > > >>>> the form. E.g.:
> > > > >>>>
> > > > >>>>          Cause value: 2
> > > > >>>>          Reason text: Freephone
> > > > >>>>          Description: A Freephone application has
> influenced
> > > > >>>> processing of
> > > > >>>>          the call (e.g. by translating a dialed Free Phone
> > > > >> number to a
> > > > >>>>          routable directory number).
> > > > >>>>
> > > > >>>> I can't figure out how to make any actionable decision
> > > > >> based on this.
> > > > >>>> Rather, it seems I need to make a number of leaps of faith
> > > > >> before I
> > > > >>>> can decide what to do.
> > > > >>>>
> > > > >>>> For instance, if I get an error, it *might* be because I
> > > > dialed a
> > > > >>>> freephone number, and it isn't supported from my calling
> > > > location.
> > > > >>>> (E.g.
> > > > >>>> maybe I'm dialing [phone], but I'm doing so from
> > > > >> France, and
> > > > >>>> calling that number is only supported in the USA.
> > > > >>>>
> > > > >>>> But getting a application reason code with cause 2
> > > > doesn't really
> > > > >>>> tell me that is what happened. It could be that the call
> > > > >> indeed was
> > > > >>>> routed through a freephone application, and it properly
> > > > routed the
> > > > >>>> call, and the call failed for some other reason. But the
> > > > cause is
> > > > >>>> there because the application
> > > > >>>> *did* influence the call routing.
> > > > >>>>
> > > > >>>> Also, these "applications" are not, AFAIK, mutually
> > > > >> exclusive. E.g. I
> > > > >>>> could be using a prepaid service to make a directory
> > > > >> assistance call
> > > > >>>> that costs extra $$$ that I don't have credits to
> > > cover. But you
> > > > >>>> can't include two cause values for the same protocol. (But
> > > > >> it is true
> > > > >>>> that you
> > > > >>>> *can* have a number of servers each put one cause into
> > > > >>>> *their* H-I entry.)
> > > > >>>>
> > > > >>>> So *maybe* I would see that my call failed, and that there
> > > > >> is both a
> > > > >>>> reason indicating a prepaid application on one H-I entry,
> > > > >> and another
> > > > >>>> indicating a another H-I indicating a directory service
> > > > >> application.
> > > > >>>> But what can I conclude from that?
> > > > >>>>
> > > > >>>> Bottom line, I just can't make sense how this could be
> > > > >> used in a well
> > > > >>>> defined and interoperable way.
> > > > >>>>
> > > > >>>>    Thanks,
> > > > >>>>    Paul
> > > > >>>>
> > > > >>>> On 2/28/2011 9:58 AM,
> > [e-mail] wrote:
> > > > >>>>> Hello,
> > > > >>>>>
> > > > >>>>> Here is the new version of the draft.
> > > > >>>>> Main changes are following:
> > > > >>>>> - More details about the registration procedure for
> > new values
> > > > >>>>> - Clearer text in section 3.2
> > > > >>>>> - Add of Public and Private status for registered values.
> > > > >>>>> - Add of a range for cause values registration
> > > > >>>>>
> > > > >>>>> Best Regards,
> > > > >>>>> Marianne Mohali
> > > > >>>>>
> > > > >>>>> -----Message d'origine-----
> > > > >>>>> Objet : New Version Notification for
> > > > >>>>> draft-mohali-sipcore-reason-extension-application-01
> > > > >>>>>
> > > > >>>>> A New Internet-Draft is available from the on-line
> > > > >> Internet-Drafts
> > > > >>>>> directories.
> > > > >>>>>
> > > > >>>>>   Title           : Extending the Session
> > > > Initiation Protocol
> > > > >>>>> (SIP) Reason Header for Applications
> > > > >>>>>   Author(s)       : M. Mohali, B. Chatras
> > > > >>>>>   Filename        :
> > > > >>>>> draft-mohali-sipcore-reason-extension-application-01.txt
> > > > >>>>>   Pages           : 10
> > > > >>>>>   Date            : 2011-02-24
> > > > >>>>>
> > > > >>>>> This document defines a new protocol value
> > > > "Application" for the
> > > > >>>>> Reason Header field and a new IANA Registry for
> registering
> > > > >>>>> application types.  This new value enables
> signaling that a
> > > > >>>> request or
> > > > >>>>> response has been issued as a result of a decision
> > made by a
> > > > >>>>> particular type of application or that an initial request
> > > > >> has been
> > > > >>>>> retargeted as a result of an application decision.
> > > > >>>>>
> > > > >>>>> A URL for this Internet-Draft is:
> > > > >>>>>
> > > > >>>>
> > > > >>
> > > >
> > >
> >
> http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten
> > > > >>>> s
> > > > >>>>> io
> > > > >>>>> n-application-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.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>
> > > >
> > >
> >
> <ftp://ftp.ietf.org/internet-drafts/draft-mohali-sipcore-reason-exten
> > > > >>>> s
> > > > >>>>> io
> > > > >>>>> n-application-01.txt>
> > > > >>>>>
> > > > >>>>> _______________________________________________
> > > > >>>>> I-D-Announce mailing list
> > > > >>>>> [e-mail]
> > > > >>>>> 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
> > > > >>>>> _______________________________________________
> > > > >>>>> sipcore mailing list
> > > > >>>>> [e-mail]
> > > > >>>>> https://www.ietf.org/mailman/listinfo/sipcore
> > > > >>>>>
> > > > >>>> _______________________________________________
> > > > >>>> sipcore mailing list
> > > > >>>> [e-mail]
> > > > >>>> https://www.ietf.org/mailman/listinfo/sipcore
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > >
> > > _______________________________________________
> > > sipcore mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/sipcore
> > >
> >
>