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

[Gonzalo Camarillo <[e-mail]>]

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 <[e-mail]>
>>   Keith Drage <[e-mail]>
>>
>> Assigned Area Director:
>>   Gonzalo Camarillo <[e-mail]>
>>
>> Mailing list
>>   Address: [e-mail]
>>   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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/insipid
>>
>