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

[<[e-mail]>]

Hi John, 

My answer inline [MM] 

Regards,
Marianne
> -----Message d'origine-----
> De : Elwell, John [mailto:[e-mail]] 
> Envoyé : jeudi 3 mars 2011 18:34
> À : MOHALI Marianne RD-CORE-ISS; [e-mail]; [e-mail]
> Objet : RE: [sipcore] 
> I-DAction:draft-mohali-sipcore-reason-extension-application-01
> 
>  
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of 
> > [e-mail]
> > Sent: 03 March 2011 16:51
> > To: [e-mail]; [e-mail]
> > Subject: Re: [sipcore] I-DAction: 
> > draft-mohali-sipcore-reason-extension-application-01
> > 
> > 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.
> [JRE] This introduces completely new considerations for the 
> security properties of History-Info. Hi-entries are expected 
> to be informational - the application can make use of them on 
> trust. For many purposes (e.g., displaying to Bob the fact 
> that the call was originally targeted at Alice and forwarded) 
> the security properties are sufficient. For making accounting 
> decisions I rather doubt they are sufficient. For a start, 
> the SIP entity doing the prepaid service might not support 
> History-Info and/or the proposed Reason header field 
> extension, and therefore a downstream entity will not know 
> that a prepaid service has been used. Or an intermediate 
> entity could remove the hi-entry or the Reason header field, 
> for privacy or malicious reasons. In fact it sounds like the 
> proposal is in violation of RFC5897, unless used within 
> closed environments.
> 
> If the authors wish to use History-Info in this sort of way, 
> I would suggest they review RFC5897 and the RFC4244bis 
> security considerations very carefully.
> 
[MM] I agree that hi-entries are informational. The draft state that if you want to mark up an application in the signalling path, you can do it using the Reason header with a specific cause value. Obviously, it is up to the service interaction managment to ensure what are the trusted applications, networks, or operators with an interaction policy or to do it only in closed environments. That's why Public and Private values are proposed.
For 3GPP 24.604 CDIV service, the downstream entities rely on History-Info header to find the original called number for ISUP interworking. Even if hi-entries are informational. 
In your example, if the prepaid service is not identified, the 2nd application will act as usual or consider the caller untrusted and not propose the connection. 

> John
> 
> > 
> > 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.
> > 
> > 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-extens
> > > > 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-extens
> > > > 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
> > 
>