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

Folks,

note that as a result of this rechartering, the milestones will be the
following:

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)

Dec 2013 Requirements for marking SIP sessions for logging to IESG
(Informational)

Mar 2014 Protocol for marking SIP sessions for logging to IESG
(Proposed standard)

Cheers,

Gonzalo


On 27/09/2013 7:08 PM, 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
>