Re: [dispatch] Revised Proposed Session-ID Charter

"Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com> Mon, 20 February 2012 17:21 UTC

Return-Path: <Peter.Dawes@vodafone.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 4677E21F876E for <dispatch@ietfa.amsl.com>; Mon, 20 Feb 2012 09:21:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmAM9RpYgkJT for <dispatch@ietfa.amsl.com>; Mon, 20 Feb 2012 09:21:34 -0800 (PST)
Received: from mailout03.vodafone.com (mailout03.vodafone.com [195.232.224.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E78F21F876F for <dispatch@ietf.org>; Mon, 20 Feb 2012 09:21:33 -0800 (PST)
Received: from mailint03 (localhost [127.0.0.1]) by mailout03 (Postfix) with ESMTP id 96F95116B0C for <dispatch@ietf.org>; Mon, 20 Feb 2012 18:21:31 +0100 (CET)
Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailint03 (Postfix) with ESMTPS id 893E9116B09; Mon, 20 Feb 2012 18:21:31 +0100 (CET)
Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Feb 2012 18:21:05 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Feb 2012 18:21:00 +0100
Message-ID: <C6A11A02FF1FBF438477BB38132E4741086FC1E8@EITO-MBX02.internal.vodafone.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] Revised Proposed Session-ID Charter
Thread-Index: Aczv8SHJQ7YezixqSP6CSJz6Zq9JLg==
From: "Dawes, Peter, VF-Group" <Peter.Dawes@vodafone.com>
To: dispatch@ietf.org
X-OriginalArrivalTime: 20 Feb 2012 17:21:05.0279 (UTC) FILETIME=[06D828F0:01CCEFF4]
Subject: Re: [dispatch] Revised Proposed Session-ID Charter
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 20 Feb 2012 17:21:40 -0000

Hello Laura, All,
The topic of Session-ID has interest from both IETF, 3GPP, and the Open
Mobile Alliance (OMA) and I am keen to contribute to any new WG. I have
just re-submitted my session-id related draft to label it "dispatch"
(not "sipping" as previously). 

http://datatracker.ietf.org/doc/draft-dawes-dispatch-debug/ 

To help track the various requirements and proposals, clause " 3.
Related Drafts and Specifications" has been added with a list of other
drafts (currently 5) and non-IETF specifications (currently 2) that I am
aware of related to this topic. I hope we can proceed soon with the
work.

Regards,
Peter

Message: 2
Date: Fri, 23 Dec 2011 14:45:49 +0100
From: Laura Liess <laura.liess.dt@googlemail.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Revised Proposed Session-ID Charter
Message-ID:
	
<CACWXZj3th3ewDOa_rjCX7ekwLFoDM6t+yW-gr_Lh7vunWQAJ=g@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252

Paul,

We already had a consensus in Dispatch that this work is needed and that
there are enough people willing to contribute. There were objections to
the initial charter but, as you already pointed out, the current charter
text seems to have reached general acceptance. I suggest you ask Gonzalo
how to proceed to start the WG.

Laura


2011/12/19 Paul E. Jones <paulej@packetizer.com>:
> Folks,
>
>
>
> I?ve not seen much discussion on this topic over the past month.? Even

> so, I?ve not seen any objection to proceeding work.? The only concern 
> raised recently is around the definition of the word ?session?, to 
> which we?re proposing to make that a part of the first deliverable.
>
>
>
> What do we need to do in order to move this work forward?
>
>
>
> Paul
>
>
>
> PS ? The charter text that seems to have reached general acceptance is

> below
>
>
>
>
>
> End-to-end Session Identifier in SIP (charter proposal)
>
>
>
> The end-to-end Session Identifier in SIP-based multimedia 
> communication networks refers to the ability for endpoints, 
> intermediate devices, and management and monitoring system to identify

> and correlate SIP messages and dialogs of the same higher-level 
> end-to-end "communication session" across multiple SIP devices, hops,
and administrative domains.
>
>
>
> Unfortunately, there are a number of factors that contribute to the 
> fact that the current dialog identifiers defined in SIP is not 
> suitable for end-to-end session identification. Perhaps the most 
> important factor worth describing is that in real-world deployments 
> Back-to-Back User Agents
> (B2BUAs) devices like Session Border Controllers (SBC) often change 
> the call identifiers (e.g., the From-tag and To-tag that are used in 
> conjunction with the Call-ID header to make the dialog-id) as the 
> session signaling passes through.
>
>
>
> An end-to-end Session Identifier should allow the possibility to 
> identify the communication session from the point of origin, passing 
> through any number of intermediaries, to the ultimate point of 
> termination. It should have the same aim as the From-tag, To-tag and 
> Call-ID conjunction, but should not be mangled by intermediaries.? 
> Consideration must be given to the fact that the entities involved in 
> a communication session might change as a result of service 
> interaction in the network, such as call transfers, joins, etc.
>
>
>
> A SIP end-to-end Session Identifier has been considered as possible 
> solution of different use cases like troubleshooting, billing, session

> tracking, session recording, media and signaling correlation, and so 
> forth.? Some of these requirements have also been identified and come 
> directly from other Existing working group within the RAI area (e.g.
SIPRec, Splices).
>
>
>
> Moreover, other standards organizations have identified the need for 
> SIP and
> H.323 to carry the same "session ID" value(s) so that it is possible 
> to identify a call end-to end even when performing interworking 
> between protocols.
>
>
>
> The working group will produce the following deliverables:
>
>
>
> 1. A requirement and use case document with key consideration for SIP 
> Session End-to-End Identification, including the definition of a
"session"
>
>
>
> 2. Specification of new end-to-end Session Identifier mechanism
>
>
>
> Goal and Milestone:
>
>
>
> August 2012 - Requirement and use case document sent to the IESG
> (Informational)
>
>
>
> March 2013 - Specification of the new mechanism sent to the IESG (PS)
>
>
>
>
>
>
>
>
> _______________________________________________
> 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


End of dispatch Digest, Vol 33, Issue 14
****************************************