Hi, a clarification in case somebody gets confused by the dates in the past. We are adding the last two additional milestones as a result of the rechartering. The dates of the two already-existing milestones (the first two on the list below) will be updated to reflect the current estimates for their completion. Cheers, Gonzalo On 29/09/2013 4:18 PM, Gonzalo Camarillo wrote: > 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@xxxxxxxxx> >> Keith Drage <keith.drage@xxxxxxxxxxxxxxxxxx> >> >> Assigned Area Director: >> Gonzalo Camarillo <gonzalo.camarillo@xxxxxxxxxxxx> >> >> Mailing list >> Address: insipid@xxxxxxxx >> 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@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/insipid >> >