Subject: [dispatch] (no subject)

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Jul 2010 09:05:47 -0400

Howdy,
During the upcoming DISPATCH f2f meeting I will be asking for a WG to handle the session-id stuff, with the following charter.  The charter has been sent before on this list, but I'm repeating the notice again in hopes folks have a chance to review it before the DISPATCH meeting. 

-hadriel

SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCOTCH) Charter:
----------------------------------
The SIPSCOTCH working group is chartered to define a mechanism that allows operators and monitoring equipment to correlate SIP messages and dialogs of the same higher-level end-to-end "session" across multiple SIP device hops for the same "message-flow", for the purpose of troubleshooting.  In particular, the mechanism must be able to allow such correlation across SIP B2BUAs of as many functional types as possible, such as Application Servers, Softswitches, PBXs, SBCs, etc.

The definition of a higher-layer "session" of the same "message-flow" is not defined by SIP when it involves a B2BUA, and is difficult to normatively define in practice.  For the purposes of this WG charter's scope, two or more dialogs of a B2BUA are correlated under any conditions where correlation might aid troubleshooting, by identifying them as belonging to the same higher-level session.  Any solution documents from this working group may expand or constrain the scope of their mechanism's correlation, if the working group so decides.

Although other solutions may be possible, this working group will focus on defining a new SIP Header field for such a purpose, similar to the Call-ID header field, in order to provide a simple, easily deployable mechanism which can work across SIP domains. The SIP Call-ID header field value itself is not usable for such correlation, because many B2BUAs must create a new Call-ID value on their UAC "side" in order to function properly, and to comply with the rules of RFC 3261. 

It should be noted that certain SIP B2BUAs perform a "topology-hiding" function, as described in RFC 5853.  The working group will take such functions into account for the correlation mechanism, as well as provide guidance for implementers of the mechanism to avoid triggering such a function for the mechanism's header field value.

Lastly, although in certain environments such a mechanism may be usable for dialog correlation in SIP state machines, it is not the goal of this working group to address that usage.

Goals and Milestones
====================
Dec 2010 - New header specification to IESG (PS)

[Sorry for duplicates if any - tried sending this multiple times, this is the third try]

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Jul 2010 09:07:19 -0400

Sorry, forgot subject line.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hadriel Kaplan
> Sent: Monday, July 26, 2010 9:06 AM
> To: [email-masked]
> Subject: [dispatch] (no subject)
> 
> Howdy,
> During the upcoming DISPATCH f2f meeting I will be asking for a WG to
> handle the session-id stuff, with the following charter.  The charter has
> been sent before on this list, but I'm repeating the notice again in hopes
> folks have a chance to review it before the DISPATCH meeting.
> 
> -hadriel
> 
> 
> The SIPSCOTCH working group is chartered to define a mechanism that allows
> operators and monitoring equipment to correlate SIP messages and dialogs
> of the same higher-level end-to-end "session" across multiple SIP device
> hops for the same "message-flow", for the purpose of troubleshooting.  In
> particular, the mechanism must be able to allow such correlation across
> SIP B2BUAs of as many functional types as possible, such as Application
> Servers, Softswitches, PBXs, SBCs, etc.
> 
> The definition of a higher-layer "session" of the same "message-flow" is
> not defined by SIP when it involves a B2BUA, and is difficult to
> normatively define in practice.  For the purposes of this WG charter's
> scope, two or more dialogs of a B2BUA are correlated under any conditions
> where correlation might aid troubleshooting, by identifying them as
> belonging to the same higher-level session.  Any solution documents from
> this working group may expand or constrain the scope of their mechanism's
> correlation, if the working group so decides.
> 
> Although other solutions may be possible, this working group will focus on
> defining a new SIP Header field for such a purpose, similar to the Call-ID
> header field, in order to provide a simple, easily deployable mechanism
> which can work across SIP domains. The SIP Call-ID header field value
> itself is not usable for such correlation, because many B2BUAs must create
> a new Call-ID value on their UAC "side" in order to function properly, and
> to comply with the rules of RFC 3261.
> 
> It should be noted that certain SIP B2BUAs perform a "topology-hiding"
> function, as described in RFC 5853.  The working group will take such
> functions into account for the correlation mechanism, as well as provide
> guidance for implementers of the mechanism to avoid triggering such a
> function for the mechanism's header field value.
> 
> Lastly, although in certain environments such a mechanism may be usable
> for dialog correlation in SIP state machines, it is not the goal of this
> working group to address that usage.
> 
> Goals and Milestones
> ====================
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch