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

Paul Kyzivat <pkyzivat@cisco.com> Thu, 03 March 2011 17:29 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441943A6860 for <sipcore@core3.amsl.com>; Thu, 3 Mar 2011 09:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.408
X-Spam-Level:
X-Spam-Status: No, score=-109.408 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWRMGDjYdv2U for <sipcore@core3.amsl.com>; Thu, 3 Mar 2011 09:29:27 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6E8723A6859 for <sipcore@ietf.org>; Thu, 3 Mar 2011 09:29:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=6828; q=dns/txt; s=iport; t=1299173435; x=1300383035; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jrVv9M70LX6ykX4Q4aEPSE9TGnewxVBcwmSAlaqW/zs=; b=SFm4qBP3Mng8ebkHkhPQJqD40lq+O4JwNxVFIRiBnvTIe3tNr2Vq2kAT e/I+Hxf0CTCEbJuRwe3eCf54/M3Jt7Ym2JdbNPugKNCWKvJ46CzV1RZ4+ zzqO/cp44TjMup806Ss7Qt8uHjEULwq96GazArTfUL42qTKMax+09aen3 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKpeb01AZnwM/2dsb2JhbACmZXSiUpwfgxEHgkkEhRqHEoNC
X-IronPort-AV: E=Sophos;i="4.62,259,1297036800"; d="scan'208";a="222299388"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 03 Mar 2011 17:30:35 +0000
Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p23HUYMR013225; Thu, 3 Mar 2011 17:30:34 GMT
Message-ID: <4D6FD03A.8040507@cisco.com>
Date: Thu, 03 Mar 2011 12:30:34 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: marianne.mohali@orange-ftgroup.com
References: <B11765B89737A7498AF63EA84EC9F5775D36A6@ftrdmel1> <4D6C2CB6.4040800@cisco.com> <B11765B89737A7498AF63EA84EC9F577617DBB@ftrdmel1>
In-Reply-To: <B11765B89737A7498AF63EA84EC9F577617DBB@ftrdmel1>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: sipcore@ietf.org, "Christer.Holmberg@ericsson.com" <Christer.Holmberg@ericsson.com>
Subject: Re: [sipcore] I-DAction: draft-mohali-sipcore-reason-extension-application-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2011 17:29:30 -0000

Marianne,

On 3/3/2011 11:51 AM, marianne.mohali@orange-ftgroup.com 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.

(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?)

> 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 : sipcore-bounces@ietf.org
>> [mailto:sipcore-bounces@ietf.org] De la part de Paul Kyzivat
>> Envoyé : mardi 1 mars 2011 00:16
>> À : sipcore@ietf.org
>> 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 +1-800-555-1234, 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, marianne.mohali@orange-ftgroup.com 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
>>> I-D-Announce@ietf.org
>>> 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
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>