Subject: [dispatch] Session-ID charter proposal

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 8 May 2010 16:35:59 -0400

Howdy,
I have asked the DISPATCH chairs what to do with Session-ID, given the feedback I received to make it a standards-track vs. individual informational submission.  There is no obvious current WG for this work, so they asked me to post a strawman charter proposal, which I propose as follows:

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" or "message-flow".  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.

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)

---

From: Peter Musgrave <[email-masked]>
Date: Sun, 9 May 2010 07:29:59 -0400

Hi Hadrial,

Draft charter seems to hit the right points.

Is it worth noting that the solution must ensure endpoint anonymity -
or is it ok to leave that for the draft?

(At first it seemed bizarre to create a WG for a single doc - but
after rereading a bunch of RAI charters I too could not really see
where else this could fit).

Peter Musgrave

On Sat, May 8, 2010 at 4:35 PM, Hadriel Kaplan <[email-masked]> wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 10 May 2010 13:35:53 +0200

Looks good to me. Just one quick question: will this WG produce a
single deliverable?

-Victor

-- 
Victor Pascual Ávila

---

From: Laura Liess <[email-masked]>
Date: Mon, 10 May 2010 13:44:58 +0200

Hi Hadriel,

this looks fine to me.

Laura

---

From: [email-masked]
Date: Mon, 10 May 2010 20:56:54 +0800

Hi,

I'd like to see the requirement of the header and typical use case for it 
in the charter.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Hadriel Kaplan <[email-masked]> 
发件人:  [email-masked]
2010-05-09 04:35

收件人
DISPATCH <[email-masked]>
抄送

主题
[dispatch] Session-ID charter proposal

Howdy,
I have asked the DISPATCH chairs what to do with Session-ID, given the 
feedback I received to make it a standards-track vs. individual 
informational submission.  There is no obvious current WG for this work, 
so they asked me to post a strawman charter proposal, which I propose as 
follows:

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" or "message-flow".  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.

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 May 2010 12:28:40 -0400

Hi Peter,
I think the sentence stating we must take topology-hiding into account should satisfy the anonymization issue.  Do you agree?

-hadriel

> -----Original Message-----
> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Sunday, May 09, 2010 7:30 AM
> To: Hadriel Kaplan
>

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 10 May 2010 12:31:03 -0400

I agree

Peter Musgrave

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 May 2010 12:31:25 -0400

Right now it has only one deliverable, under the Goals and Milestones section.  In theory one could always modify a charter of any WG to add more deliverables later, and I've never seen a charter which said "this charter must not be changed". :)
In practice changing a charter takes consensus anyway, and my guess is any attempt to do that for this charter would be squashed by consensus.

-hadriel

> From: Victor Pascual Avila [mailto:[email-masked]]
> Sent: Monday, May 10, 2010 7:36 AM
> To: Hadriel Kaplan
> Cc: DISPATCH
> Subject: Re: [dispatch] Session-ID charter proposal
> 
> > 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" or "message-
> flow".  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.
> >
> > 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.
> >

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 May 2010 07:03:23 -0600

So I think this could still use a bit more. This describes a solution, which is fine, but not the problem. 

What is that being correlated? What are the semantic meaning of two call legs being correlated? I'm trying to get at if phone A, B and C are all in talking on the same conference call are they correlated? what if A and B are in a breakout session? If A calls B and B puts A on hold them B calls C, are they correlated? If B now conferences all they are they correlated? If A is calls B and starts one of the many types of transfer to C?  I'm trying to get at what does it mean for two UA's to be in the same "session" or "message-flow" and who needs to know that and why. If the only purpose is troubleshooting, the charter should say that. Can a given SIP call leg be in multiple sessions at once? is correlation a transitive property? 

I think we need to get a little crisper about what the problem is in the charter or this WG is going to have a hard time moving forward.  Without some guiding architecture on this, I think the WG will find it very hard to produce anything useful. I think we should also consider if we want this WG to have a separate task of fixing the issues with Call-ID brought up in Hadriels other draft. 

> SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCOTCH) Charter:

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: [email-masked]
Date: Wed, 12 May 2010 21:13:33 +0800

+1

Cullen Jennings <[email-masked]> 
发件人:  [email-masked]
2010-05-12 21:03

收件人
Hadriel Kaplan <[email-masked]>
抄送
DISPATCH <[email-masked]>
主题
Re: [dispatch] Session-ID charter proposal

So I think this could still use a bit more. This describes a solution, 
which is fine, but not the problem. 

What is that being correlated? What are the semantic meaning of two call 
legs being correlated? I'm trying to get at if phone A, B and C are all in 
talking on the same conference call are they correlated? what if A and B 
are in a breakout session? If A calls B and B puts A on hold them B calls 
C, are they correlated? If B now conferences all they are they correlated? 
If A is calls B and starts one of the many types of transfer to C?  I'm 
trying to get at what does it mean for two UA's to be in the same 
"session" or "message-flow" and who needs to know that and why. If the 
only purpose is troubleshooting, the charter should say that. Can a given 
SIP call leg be in multiple sessions at once? is correlation a transitive 
property? 

I think we need to get a little crisper about what the problem is in the 
charter or this WG is going to have a hard time moving forward.  Without 
some guiding architecture on this, I think the WG will find it very hard 
to produce anything useful. I think we should also consider if we want 
this WG to have a separate task of fixing the issues with Call-ID brought 
up in Hadriels other draft. 

allows operators and monitoring equipment to correlate SIP messages and 
dialogs of the same higher-level end-to-end "session" or "message-flow". 
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.

Cullen Jennings

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 May 2010 10:42:47 -0400

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Wednesday, May 12, 2010 9:03 AM
> To: Hadriel Kaplan
> 
> talking on the same conference call are they correlated? 

No, not with respect to this charter's purpose/goal anyway.

> what if A and B
> C, are they correlated? 

No.

> If B now conferences all they are they correlated?

No.

> If A is calls B and starts one of the many types of transfer to C?

No.

>  I'm
> "session" or "message-flow" and who needs to know that and why. 

OK, I'll try to suggest text for the charter to make it clearer.

> If the
> only purpose is troubleshooting, the charter should say that. 

The charter does say that - the charter was modified slightly in a subsequent email: http://www.ietf.org/mail-archive/web/dispatch/current/msg01776.html

> Can a given

No.
 
> up in Hadriels other draft.

While I personally would like that, I don't think it's the same problem, nor same root cause, nor the same people who would care.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 May 2010 10:13:19 -0600

inline ...

>> SIP call leg be in multiple sessions at once? is correlation a transitive

OK - so I am getting the idea that the only time two dialogs are correlated is when they are two sides of an B2BUA and they both represent exactly the same media flowing over the RTP streams?  I'm not arguing the answer should or should not be this - I just want to be clear what it is). Can you try and craft some text to put in a charter about what when two things are correlated and when they are not?

> While I personally would like that, I don't think it's the same problem, nor same root cause, nor the same people who would care.

OK - I'll think about this some more once I have a better idea of what it is the WG going to do.

Cullen Jennings