Subject: Re: [dispatch] Revised Proposed Session-ID Charter

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Mon, 20 Feb 2012 18:21:00 +0100

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 <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] Revised Proposed Session-ID Charter
Message-ID:
	
<CACWXZj3th3ewDOa_rjCX7ekwLFoDM6t+yW-gr_Lh7vunWQAJ=[email-masked]>
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 <[email-masked]>:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

------------------------------

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 20 Feb 2012 14:12:15 -0500

Peter,

I looked over the draft quickly (so perhaps I missed it), but how does Alice
learn the address of d1.foocorp.com?

Paul

> -----Original Message-----
> From: Dawes, Peter, VF-Group [mailto:[email-masked]]
> Sent: Monday, February 20, 2012 12:21 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> aware of related to this topic. I hope we can proceed soon with the work.
> 
> Regards,
> Peter

---

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Tue, 21 Feb 2012 15:58:09 +0100

Hi Paul,
Thanks for reading the draft. It is expected (clause 6.) that the
configuration framework in RFC 6080 will be used with a profile type of
"User Profile", so subscription to d1.foocorp.com would be as below
(from RFC 6080).

Regards,
Peter

(RFC 6080)
5.1.4.3.  User Profile Type

   To create a Subscription URI to request the user profile on behalf of
   a user, the device needs to know the user's AoR.  This can be
   statically or dynamically configured on the device (e.g., user input,
   or propagated as part of the device profile).  Similar to device
   profiles, the content and propagation of user profiles may differ,
   based on deployment scenarios (i.e., users belonging to the same
   domain may -- or may not -- be provided the same profile).  To create
   a Subscription URI, the following rules apply:

Petrie & Channabasappa       Standards Track                   [Page 21]
RFC 6080               SIP Configuration Framework            March 2011

   o  The device MUST set the Request-URI to the user AoR.

   o  The device MUST populate the From field with the user AoR.

   An authoritative SIP proxy for a SIP provider's network that receives
   a profile enrollment request for the user profile type will route
   based on the Event Header field values, thus allowing a subscription
   to the user's AoR to be routed to the appropriate PDS.

-----Original Message-----
From: Paul E. Jones [mailto:[email-masked]] 
Sent: 20 February 2012 19:12
To: Dawes, Peter, VF-Group; [email-masked]
Cc: [email-masked]
Subject: RE: [dispatch] Revised Proposed Session-ID Charter

Peter,

I looked over the draft quickly (so perhaps I missed it), but how does
Alice learn the address of d1.foocorp.com?

Paul

> 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"

> 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.