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

[<[e-mail]>]

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