[sipcore] draft-shen-interaction-ind-07

<youssef.chadli@orange-ftgroup.com> Fri, 29 October 2010 16:18 UTC

Return-Path: <youssef.chadli@orange-ftgroup.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 DD1F43A65A5 for <sipcore@core3.amsl.com>; Fri, 29 Oct 2010 09:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.759
X-Spam-Level:
X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 XN6dyL-Q--i7 for <sipcore@core3.amsl.com>; Fri, 29 Oct 2010 09:18:08 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 8890A3A6405 for <sipcore@ietf.org>; Fri, 29 Oct 2010 09:18:07 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5BAEF8B800C; Fri, 29 Oct 2010 18:20:47 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4B7AD8B8002; Fri, 29 Oct 2010 18:20:47 +0200 (CEST)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Oct 2010 18:20:01 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB7785.22D1D2BB"
Date: Fri, 29 Oct 2010 18:19:28 +0200
Message-ID: <9ECCF01B52E7AB408A7EB85352642141020FD42F@ftrdmel0.rd.francetelecom.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sipcore] draft-shen-interaction-ind-07
Thread-Index: Act3hQ9/WduVCoSmSduo11QqzTsrSw==
From: <youssef.chadli@orange-ftgroup.com>
To: <sipcore@ietf.org>, <yuzhongshen@gmail.com>
X-OriginalArrivalTime: 29 Oct 2010 16:20:01.0575 (UTC) FILETIME=[233D0B70:01CB7785]
Subject: [sipcore] draft-shen-interaction-ind-07
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: Fri, 29 Oct 2010 16:18:11 -0000

Hello all, 

The proposal in this draft to create a new header to carry information
between SIP Application Servers to handle interactions between services
provided between different AS, (that may be in different domains) is
very interesting. 
In fact, there several cases where SIP Application Servers need to
exchange information on the features/services that has been executed for
the being established session and information on the feature/services
that are not compatible with the previously executed features/services.
Below some examples of such interactions:

Example 1:
"Service Phone Number" is a service that allows the user to dial a
unique phone number to join a commercial or public service. The "Service
Phone Number" Application Server determines to which destination the
call should be routed based on service logic criteria (e.g. location of
the calling user, wishes of the calling users obtained after voice
interaction, etc.).  
In some situations, the "Service Phone Number" Application Server needs
to inhibit call diversion of the routed-to destination. Let's take the
example of a service that allows the calling user to dial a unique
number to join the nearest and appropriate doctor. When the "Service
Phone Number" AS routes the call to a given doctor, it needs to indicate
that the call must not be diverted so that if this doctor is not
available it can re-route the call to another destination. 
>From the above examples, it appears that in order to handle conflicting
interactions between supplementary services, Application Servers need to
exchange the following information:
1) Indication of services or actions that must not be performed,
possibly under conditions.
2) Downstream Application Servers receive the list of previously
activated services with which they may have conflicting interactions.
This is needed in order to handle interactions where the upstream
Application Servers cannot determine all the features that are
incompatible with their service.

Example 2:
For interaction with voicemail:
- Some applications may needs to inhibit diversion of the call to
voicemail.
- Other applications may need to enforce the call to be diverted to
voicemail. 

Best regards, 

Youssef CHADLI
Orange Labs