Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt

<marianne.mohali@orange.com> Tue, 29 March 2016 06:34 UTC

Return-Path: <marianne.mohali@orange.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FD712D0E3 for <dispatch@ietfa.amsl.com>; Mon, 28 Mar 2016 23:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMefbaFNlQHV for <dispatch@ietfa.amsl.com>; Mon, 28 Mar 2016 23:34:39 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56FDC12D0C5 for <dispatch@ietf.org>; Mon, 28 Mar 2016 23:34:39 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 76CF922C42F; Tue, 29 Mar 2016 08:34:37 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 55AAC35C048; Tue, 29 Mar 2016 08:34:37 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0279.002; Tue, 29 Mar 2016 08:34:37 +0200
From: marianne.mohali@orange.com
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Thread-Topic: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt
Thread-Index: AQHRhGkLD+IuHzAGKUaPUdte2w2GWJ9mhbuAgAB/r4CACO1f4A==
Date: Tue, 29 Mar 2016 06:34:36 +0000
Message-ID: <22571_1459233277_56FA21FD_22571_6152_1_8B970F90C584EA4E97D5BAAC9172DBB81A975829@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <21379_1458588251_56F04A5B_21379_5094_1_8B970F90C584EA4E97D5BAAC9172DBB81A970D51@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <56F18F74.9050504@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37F040EE@ESESSMB209.ericsson.se> <56F2A6C3.6020403@alum.mit.edu>
In-Reply-To: <56F2A6C3.6020403@alum.mit.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.29.55718
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/aO1yz2jY6s-RCL6RSj60XoVqzRY>
Subject: Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Mar 2016 06:34:42 -0000

Hi Paul,

Thank you for your feedback!

From my view, I was thinking that only one P-Served-User (with one session-case) can be present in a request at the same time.
Eg: A calls B which has a CDIV service. The incoming request to B will contain a P-Served-User with the session case 'term', then the AS triggering CDIV service will remove this entry containing the 'term' session case and replace it by a P-Served-User (with the same user) but the 'orig-cdiv' session case to indicate to the S-CSCF which iFC apply.

For that, I'm not sure we can have the P-Served-User repeated. How does the receiving entity will know what to do and for "who" if there are several choices?

BR,
Marianne

-----Message d'origine-----
De : dispatch [mailto:dispatch-bounces@ietf.org] De la part de Paul Kyzivat
Envoyé : mercredi 23 mars 2016 15:23
À : Christer Holmberg; dispatch@ietf.org
Objet : Re: [dispatch] New draft draft-mohali-dispatch-originating-cdiv-parameter-00.txt

On 3/23/16 2:45 AM, Christer Holmberg wrote:
> Hi,
>
> As far as I remember, in SIP all "repeatable" header fields shall also 
> be "comma separabable".
>
> I can't think of a header field where that would not be the case.

The header fields with that property have syntax to match.

The syntax in 5502 doesn't support that for this header field. If that was then intent then the syntax should be revised.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ----------------------------------------------------------------------
> --
> From: Paul Kyzivat <mailto:pkyzivat@alum.mit.edu>
> Sent: ‎22/‎03/‎2016 20:31
> To: dispatch@ietf.org <mailto:dispatch@ietf.org>
> Subject: Re: [dispatch] New draft
> draft-mohali-dispatch-originating-cdiv-parameter-00.txt
>
> Marianne,
>
> Thank you. This draft is a huge improvement over the prior proposal 
> for this purpose!
>
> I don't have a problem with this approach. The draft seems in 
> reasonable shape. (I didn't read it for nits, as doing that seems 
> premature.)
>
> One thing I noticed, which is really an issue with rfc5502:
>
> The P-Served-User header field doesn't seem to have the usual 
> provision of headers like this for comma-separated repetition. And 
> there is no mention pro or con regarding whether this header field can be repeated.
> Since it can already have both orig and term options, that presumably 
> can coexist, I guess it can be repeated, but not using comma. Is that 
> how it is being used in practice?
>
> It would be wise to clarify the ways in which this header field may be 
> repeated. (E.g., every usage must have a distinct value of
> sessioncase-param.) And if multiple values separated by comma are 
> being used in practice then the syntax ought to be corrected to allow that.
>
>          Thanks,
>          Paul
>
> On 3/21/16 3:24 PM, marianne.mohali@orange.com wrote:
>> Hello,
>>
>> Please find hereafter a new Internet-Draft  "P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)".
>> The purpose of the draft is to register a new SIP parameter for the P-Served-User header field defined as per RFC5502.
>>
>> Abstract:
>>     This specification defines a new Session Initiation Protocol (SIP) P-
>>     Served-User header field parameter, "orig-cdiv-param", which defines
>>     the session case used by a proxy when handling an originating session
>>     after Call Diversion (CDIV) services has been invoked for the served
>>     user.  The P-Served-User header field is defined in [RFC5502].  The
>>     P-Served-User header field conveys the identity of the served user
>>     and the session case that applies to this particular communication
>>     session and application invocation.
>>     This document updates [RFC5502] in order to add the originating after
>>     CDIV session case.
>>
>> The draft can be found in :
>> URL:https://www.ietf.org/internet-drafts/draft-mohali-dispatch-origin
>> ating-cdiv-parameter-00.txt 
>> Status:https://datatracker.ietf.org/doc/draft-mohali-dispatch-origina
>> ting-cdiv-parameter/
>> Htmlized:https://tools.ietf.org/html/draft-mohali-dispatch-originatin
>> g-cdiv-parameter-00
>>
>> Best Regards,
>> Marianne Mohali
>>
>>
>> _____________________________________________________________________
>> ____________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
>> exploites ou copies sans autorisation. Si vous avez recu ce message 
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>>https://www.ietf.org/mailman/listinfo/dispatch
>>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.