Subject: [dispatch] Final Charter for Session-ID?

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Thu, 10 Jun 2010 12:28:03 +0200

Hello Hadriel, All,
I believe that the session-ID header field is very useful and should be
described in an RFC. However, for troubleshooting across many network
entities where the message path is not known beforehand,
http://www.ietf.org/id/draft-dawes-sipping-debug-02.txt describes a
targetted approach that avoids having to look for session-ID in all
messages everywhere in the network. I believe that my draft is a
specialization of session-ID and could be written as an extension to it.

Does the proposed charter text allow my draft to be added to SIPSCOTCH
working group discussions? If not, I would like to propose adding it to
the charter. Thanks.

Regards,
Peter

-------------------------------------------------------------------

Howdy,
I have heard no objections to this version of the charter (other than a
debate about how to solve it).  
If you have any comments regarding the charter, please speak now.
Thanks!

-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)

Peter Dawes 
Group R&D
 
Tel: +44 (0)7717 275009
Fax: +44 (0)1635 234873

E-mail: [email-masked]
 
www.betavine.net  - Web
betavine.mobi  - Mobile Web
 
Vodafone Group Services Limited 
Registered Office: Vodafone House, The Connection, Newbury, Berkshire
RG14 2FN Registered in England No 3802001