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

[Christer Holmberg <[e-mail]>]

Hi, 

>>[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 haven't studies this specific use-case, but if it's about finding a service or capability in the network then I agree that proxy-feature is appropriate.

Without looking at it from a can-do/have-done perspective, another important thing with proxy-feature is that the entity that inserts a feature tag MUST NOT assume that other entities will understand and act upon it.

I am not claiming that Marianne's use-case is any different in that perspective, but just to keep in mind.

>I think it would be helpful for the two of you to come to some reconciliation of what you are trying to accomplish.

I am trying to indicate support of capabilities :)

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