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

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

</snip>
> > [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.
> [MM] I don't see the problem with your point. hi-entry parameters
> are not incompatible with URIs' headers.
> hi-entry parameters, allow to do a first sort in hi-entries, then,
> according to UAS needs, URI headers or parameters give a complementary
>  information.
> Imagine a situation where you have Alice calling Bob with a prepaid
> calling card and Bod doesn't answer so the call is retargeted to the
> voicemail.
> You would have the following sequence in the last INVITE (last leg):
> I didn't show possible intermediary proxies entries)
> History-Info:
>       <sip:[e-mail];user=phone?Reason=application
>       ;cause=9;text="Prepaid">;index=1,
>
> <sip:[e-mail];user=phone?Privacy=history>;index=1.1;mp=1,
>
> <sip:[e-mail];user=phone;cause=408>index=1.1.1;mp=1.1

[JRE] So in this particular case, the application might search for the earliest entry marked mp, which points to the hi-entry with index 1, and that contains the Prepaid reason. I suppose that works (subject to my earlier caveat about needing to be in a closed network to rely on that information). However, the fact that it works in this particular scenario does not necessarily mean it is the correct mechanism, and I would like to hear other opinions.

John

>
> Marianne
> >
> > 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
> > > > >
> > > >
> > >
> >
>