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

[<[e-mail]>]

 

> -----Message d'origine-----
> De : Elwell, John [mailto:[e-mail]] 
> Envoyé : vendredi 18 mars 2011 08:34
> À : MOHALI Marianne RD-CORE-ISS; [e-mail]
> Cc : [e-mail]; [e-mail]
> Objet : RE: [sipcore] 
> I-DAction:draft-mohali-sipcore-reason-extension-application-01
> 
> 
> 
> > -----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.
[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

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