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