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

[Christer Holmberg <[e-mail]>]

Hi,

>>>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.
> 
>>(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.

Marianne is correct: proxy-feature is about entity capabilities - what they CAN do.

Regards,

Christer








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