IETF Logo Mail Archive

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

"Worley, Dale R (Dale)" <dworley@avaya.com> Wed, 09 March 2011 18:31 UTC

Return-Path: <dworley@avaya.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 7A1AF3A6944 for <sipcore@core3.amsl.com>; Wed, 9 Mar 2011 10:31:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.542
X-Spam-Level:
X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, 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 7AolsZrp9kgj for <sipcore@core3.amsl.com>; Wed, 9 Mar 2011 10:31:12 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 831723A6933 for <sipcore@ietf.org>; Wed, 9 Mar 2011 10:31:12 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFMtcU2HCzI1/2dsb2JhbACmZXSkeQKZFoJ+gmMEhRyKcA
X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="268608090"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 Mar 2011 13:32:28 -0500
X-IronPort-AV: E=Sophos;i="4.62,291,1297054800"; d="scan'208";a="614077725"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 Mar 2011 13:32:28 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.187]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 9 Mar 2011 13:32:27 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "marianne.mohali@orange-ftgroup.com" <marianne.mohali@orange-ftgroup.com>, "pkyzivat@cisco.com" <pkyzivat@cisco.com>
Date: Wed, 09 Mar 2011 13:31:42 -0500
Thread-Topic: [sipcore] I-DAction:draft-mohali-sipcore-reason-extension-application-01
Thread-Index: AcvZyONLW9FOvLuUTUqkYcckL0it7wDKxr0yAFSpeNAAEGYxoA==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B220B5C1567@DC-US1MBEX4.global.avaya.com>
References: <B11765B89737A7498AF63EA84EC9F5775D36A6@ftrdmel1><4D6C2CB6.4040800@cisco.com><B11765B89737A7498AF63EA84EC9F577617DBB@ftrdmel1>, <4D6FD03A.8040507@cisco.com> <CD5674C3CD99574EBA7432465FC13C1B220B5C154B@DC-US1MBEX4.global.avaya.com>, <B11765B89737A7498AF63EA84EC9F57765B3A4@ftrdmel1>
In-Reply-To: <B11765B89737A7498AF63EA84EC9F57765B3A4@ftrdmel1>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <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: Wed, 09 Mar 2011 18:31:13 -0000

________________________________________
From: marianne.mohali@orange-ftgroup.com [marianne.mohali@orange-ftgroup.com]

> -----Message d'origine-----
> De : Worley, Dale R (Dale) [mailto:dworley@avaya.com]
>
> Could we see an example of how this is expected to be done?
> (Or have I overlooked the example?)  There are various
> subtlties in a protocol feature whose *absence* in the
> signaling tells another application that a certain action may
> be taken.

[MM] In my network, I have an agreement with the Prepaid application that is to identify itself in the signaling (in the H-I header) when applied.
So that, I can offer to all of my clients a customized service with a connection to the reseached phone number except for prepaid callers.
Callers from other networks will not be able to enjoy the customized service (with the connection) as they are considered as untrusted.
_______________________________________

I was thinking of a call flow, showing the critical header fields, the various proxies involved, etc.

Dale

v2.34.0 | Report a Bug | By Email | System Status