Re: [Insipid] WG Review: INtermediary-safe SIP session ID (insipid)

The relevant mail was:

http://www.ietf.org/mail-archive/web/insipid/current/msg00642.html

Sent on 2nd August 2013.

If you go to the link in this message you will see a slide with a coloured version just for your benefit.

Not sure why the new milestones are missing - there should ultimately be two new ones. May Gonzalo Camarillo can comment.

regards

Keith

> -----Original Message-----
> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf
> Of James Polk
> Sent: 27 September 2013 19:54
> To: 'Gonzalo Salgueiro (gsalguei)'; DRAGE, Keith (Keith); Gonzalo
> Camarillo
> Cc: insipid@ietf.org
> Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID
> (insipid)
> 
> Chairs and AD
> 
> Lacking a good local diff tool, can you articulate what exactly is
> being proposed to change from the existing charter, and why was this
> necessary or needed or asked for?
> 
> I mean, the focus of the charter is still on the 2 drafts we've been
> working on for some time now, and that doesn't appear to have
> changed. Additionally, there are no new milestones.
> 
> I seemed to have missed the memo that brought this all about.
> 
> James
> 
> At 11:08 AM 9/27/2013, The IESG wrote:
> >The INtermediary-safe SIP session ID (insipid) working group in the
> >Real-time Applications and Infrastructure Area of the IETF is undergoing
> >rechartering. The IESG has not made any determination yet. The following
> >draft charter was submitted, and is provided for informational purposes
> >only. Please send your comments to the IESG mailing list (iesg at
> >ietf.org) by 2013-10-07.
> >
> >INtermediary-safe SIP session ID (insipid)
> >------------------------------------------------
> >Current Status: Active WG
> >
> >Chairs:
> >   Gonzalo Salgueiro <gsalguei@cisco.com>
> >   Keith Drage <keith.drage@alcatel-lucent.com>
> >
> >Assigned Area Director:
> >   Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
> >
> >Mailing list
> >   Address: insipid@ietf.org
> >   To Subscribe: https://www.ietf.org/mailman/listinfo/insipid
> >   Archive: http://www.ietf.org/mail-archive/web/insipid/
> >
> >Charter:
> >
> >An 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 are not suitable for end-to-end session
> >identification. Perhaps the most important factor worth describing is
> >that in real-world deployments of 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.
> >
> >A SIP end-to-end session identifier has been considered as possible
> >solution of different use cases like troubleshooting, billing, session
> >recording, media and signaling correlation, and so forth.  Some of
> >these requirements come from other working groups within the RAI area
> >(e.g., SIPRec).  Moreover, other standards organizations have
> >identified the need for SIP and H.323 to carry the same "session ID"
> >value so that it is possible to identify a call end-to-end even when
> >performing inter working between protocols.
> >
> >Troubleshooting SIP signalling end-to-end becomes impractical as
> >networks grow and become interconnected, including connection via
> >transit networks, because the path that SIP signalling will take
> >between clients cannot be predicted and the signalling volume and
> >geographical spread are too large.
> >
> >This group will focus on two documents:
> >
> >The first document will specify a SIP identifier that has the same aim
> >as the From-tag, To-tag and Call-ID conjunction, but is less likely to
> >be mangled by intermediaries.  In doing this work, the group will pay
> >attention to the privacy implications of a "session ID", for example
> >considering the possibility to make it intractable for nodes to
> >correlate "session IDs" generated by the same user for different
> >sessions.
> >
> >The second document will define an indicator that can be added to the
> >SIP protocol to indicate that signalling should be logged. The
> >indicator will typically be applied as part of network testing
> >controlled by the network operator and not used in regular client
> >signalling.  However, such marking can be carried end-to-end including
> >the SIP terminals, even if a session originates and terminates in
> >different networks.
> >
> >Milestones:
> >   Dec 2012 - Requirements and use cases for new identifier sent to IESG
> >(as informational)
> >   Feb 2013 - Specification of the new identifier sent to the IESG (PS)
> >
> >
> >_______________________________________________
> >insipid mailing list
> >insipid@ietf.org
> >https://www.ietf.org/mailman/listinfo/insipid
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid