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

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 7 Jun 2010 09:51:03 -0400

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)

---

From: Laura Liess <[email-masked]>
Date: Wed, 9 Jun 2010 09:32:59 +0200

+1
I think the charter is consistent to what is needed in the field.

Thanks
Laura

2010/6/7 Hadriel Kaplan <[email-masked]>:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 9 Jun 2010 11:26:10 +0200

> If you have any comments regarding the charter, please speak now.  Thanks!

I'm fine with this charter, it's addressing a real problem and the
scope is clear.

Cheers,
-- 
Victor Pascual Ávila

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 9 Jun 2010 05:47:05 -0400

I'd like to see this go forward too.

Peter

---

From: Dan York <[email-masked]>
Date: Wed, 9 Jun 2010 06:42:50 -0400

+1

--
Dan York
http://www.voxeo.com/
http://blogs.voxeo.com/
http://www.danyork.com/
http://twitter.com/danyork

---

From: David Schwartz <[email-masked]>
Date: Wed, 9 Jun 2010 15:25:38 +0300

+1

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Jun 2010 08:53:26 -0600

I have a problem with this proposed charter. 

> 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 W…

I think the above text is way too vague and impossible to reduce to engineering practice. If you have 10 calls going to a PSTN GWs that is having voice quality problems, clearly having all of them grouped together is useful in debugging. Yet I doubt we want all the calls from a given PSTN GW to have the same correlation ID. Our lack of any solid definition of what it is we are trying to correlate is a strong indication to me that we have not yet come to any consensus about what the problem is this WG would be trying to fix.
 
I would like to see a WG charted in this area but I would expect the IESG to more or less laugh at a problem statement that reduced down to "uh might be useful for debuggin". Can some people please try and propose a more concrete definition of when two sip dialogs will be correlated?

Cullen

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 10 Jun 2010 11:37:20 +0530

Here is an initial attempt:

If there is a dialog between A and B then A and B are in a session.
If there is a dialog between A and B and a dialog between B and C at the
same time then A, B and C are in a session.
More generally, if two or more participants are part of a session S and
at the same time there is a dialog between one of the participants of S
and another participant Z who is not part of S, then S (union) Z is a
session.

I think this would cover most of SBC, 3PCC an app server cases. People
can add cases like park/retrieve if they think they should be considered
as part of a single session.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf
|Of Cullen Jennings (fluffy)
|Sent: Wednesday, June 09, 2010 8:23 PM
|To: DISPATCH list
|Subject: Re: [dispatch] Final Charter for Session-ID?
|
|I have a problem with this proposed charter.
|
|On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote:
|
|>
|> 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.
|
|I think the above text is way too vague and impossible to reduce to
|engineering practice. If you have 10 calls going to a PSTN GWs that is
|having voice quality problems, clearly having all of them grouped
together
|is useful in debugging. Yet I doubt we want all the calls from a given
PSTN
|GW to have the same correlation ID. Our lack of any solid definition of
what
|it is we are trying to correlate is a strong indication to me that we
have
|not yet come to any consensus about what the problem is this WG would
be
|trying to fix.
|
|I would like to see a WG charted in this area but I would expect the
IESG to
|more or less laugh at a problem statement that reduced down to "uh
might be
|useful for debuggin". Can some people please try and propose a more
concrete
|definition of when two sip dialogs will be correlated?
|
|Cullen
|
|_______________________________________________
|dispatch mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jun 2010 08:53:36 -0400

> and another participant Z who is not part of S, then S (union) Z is a

The above just reiterates the problem that Cullen was raising.
Just because B has a dialog with A and a dialog with C does not mean 
that there is a session between A and C. A gateway provides a perfect 
example of that.

There needs to be some semantic link between the dialogs. The question 
is defining what sorts of semantic links should be used to share a 
session id.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Jun 2010 14:57:44 +0200

Hi,

Isn't the linkage the fact that C is the person A addressed for this specific session?

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 10. kesäkuuta 2010 15:54
> To: Muthu ArulMozhi Perumal (mperumal)
> Cc: DISPATCH list
> Subject: Re: [dispatch] Final Charter for Session-ID?
> 
> 
> 
> > If there is a dialog between A and B and a dialog between B 
> and C at 
> > the same time then A, B and C are in a session.
> > More generally, if two or more participants are part of a session S 
> > and at the same time there is a dialog between one of the 
> participants 
> > of S and another participant Z who is not part of S, then S 
> (union) Z 
> > is a session.
> 
> Just because B has a dialog with A and a dialog with C does 
> not mean that there is a session between A and C. A gateway 
> provides a perfect example of that.
> 
> There needs to be some semantic link between the dialogs. The 
> question is defining what sorts of semantic links should be 
> used to share a session id.
> 
> 	Thanks,
> 	Paul
> 
> > can add cases like park/retrieve if they think they should be 
> > considered as part of a single session.
> > 
> > Muthu
> > 
> > |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
> > |engineering practice. If you have 10 calls going to a PSTN 
> GWs that 
> > |is having voice quality problems, clearly having all of 
> them grouped
> > together
> > |is useful in debugging. Yet I doubt we want all the calls from a 
> > |given
> > PSTN
> > |GW to have the same correlation ID. Our lack of any solid 
> definition 
> > |of
> > what

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 10 Jun 2010 18:52:00 +0530

Yes, the fact that A and C are communicating is the linkage -- B is just facilitating that communication.

thanks,
Muthu 

|-----Original Message-----
|From: Christer Holmberg [mailto:[email-masked]]
|Sent: Thursday, June 10, 2010 6:28 PM
|To: Paul Kyzivat (pkyzivat); Muthu ArulMozhi Perumal (mperumal)
|Cc: DISPATCH list
|Subject: RE: [dispatch] Final Charter for Session-ID?
|
|
|Hi,
|
|Isn't the linkage the fact that C is the person A addressed for this
|specific session?
|
|Regards,
|
|Christer
|
|> -----Original Message-----
|> From: [email-masked]
|> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
|> Sent: 10. kesäkuuta 2010 15:54
|> To: Muthu ArulMozhi Perumal (mperumal)
|> Cc: DISPATCH list
|> Subject: Re: [dispatch] Final Charter for Session-ID?
|>
|>
|>
|> Muthu ArulMozhi Perumal (mperumal) wrote:
|> > Here is an initial attempt:
|> >
|> > If there is a dialog between A and B then A and B are in a session.
|> > If there is a dialog between A and B and a dialog between B
|> and C at
|> > the same time then A, B and C are in a session.
|> > More generally, if two or more participants are part of a session S
|> > and at the same time there is a dialog between one of the
|> participants
|> > of S and another participant Z who is not part of S, then S
|> (union) Z
|> > is a session.
|>
|> The above just reiterates the problem that Cullen was raising.
|> Just because B has a dialog with A and a dialog with C does
|> not mean that there is a session between A and C. A gateway
|> provides a perfect example of that.
|>
|> There needs to be some semantic link between the dialogs. The
|> question is defining what sorts of semantic links should be
|> used to share a session id.
|>
|> 	Thanks,
|> 	Paul
|>
|> > I think this would cover most of SBC, 3PCC an app server
|> cases. People
|> > can add cases like park/retrieve if they think they should be
|> > considered as part of a single session.
|> >
|> > Muthu
|> >
|> > |-----Original Message-----
|> > |From: [email-masked]
|> [mailto:[email-masked]] On
|> > Behalf
|> > |Of Cullen Jennings (fluffy)
|> > |Sent: Wednesday, June 09, 2010 8:23 PM
|> > |To: DISPATCH list
|> > |Subject: Re: [dispatch] Final Charter for Session-ID?
|> > |
|> > |I have a problem with this proposed charter.
|> > |
|> > |On Jun 7, 2010, at 7:51 AM, Hadriel Kaplan wrote:
|> > |
|> > |>
|> > |> 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.
|> > |
|> > |I think the above text is way too vague and impossible to
|> reduce to
|> > |engineering practice. If you have 10 calls going to a PSTN
|> GWs that
|> > |is having voice quality problems, clearly having all of
|> them grouped
|> > together
|> > |is useful in debugging. Yet I doubt we want all the calls from a
|> > |given
|> > PSTN
|> > |GW to have the same correlation ID. Our lack of any solid
|> definition
|> > |of
|> > what
|> > |it is we are trying to correlate is a strong indication to
|> me that we
|> > have
|> > |not yet come to any consensus about what the problem is
|> this WG would
|> > be
|> > |trying to fix.
|> > |
|> > |I would like to see a WG charted in this area but I would
|> expect the
|> > IESG to
|> > |more or less laugh at a problem statement that reduced down to "uh
|> > might be
|> > |useful for debuggin". Can some people please try and propose a more
|> > concrete
|> > |definition of when two sip dialogs will be correlated?
|> > |
|> > |Cullen
|> > |
|> > |_______________________________________________
|> > |dispatch mailing list
|> > [email-masked]
|> > |https://www.ietf.org/mailman/listinfo/dispatch
|> > _______________________________________________
|> > dispatch mailing list
|> > [email-masked]
|> > https://www.ietf.org/mailman/listinfo/dispatch
|> >
|> _______________________________________________
|> dispatch mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/dispatch
|>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jun 2010 10:14:42 -0400

> Yes, the fact that A and C are communicating is the linkage -- B is just facilitating that communication.

Then that needs to be specified.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Jun 2010 08:28:50 -0600

I'm not following what you mean but it seems like this might lead to a workable definition. Can you propose something a bit more specific?

>>> |definition of when two sip dialogs will be correlated?

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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Jun 2010 15:44:47 +0200

When Cullen raised the question, I was wondering whether two dialogs are related if the media from the session associated with one dialog is forwarded to the session associated with the other dialog. But then I realised that this would not apply if you wanted to correlate two dialogs that are not session-related, e.g., two SUBSCRIBE-initiated dialogs. But on the other hand, the term session-ID hardly seems the right term for two related SUBSCRIBE-initiated dialogs, since there is no session involved.

So the first question to be asked is whether the work should really be limited to sessions, or whether it could apply to other types of dialog, or even to non-dialog-forming transactions such as MESSAGE and PUBLISH when they cross a B2BUA. Depending on the answer to this, the name and definition of the object we are trying to describe can be selected.

John

> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: 15 June 2010 15:29
> To: Christer Holmberg
> Cc: DISPATCH list
> I'm not following what you mean but it seems like this might 
> lead to a workable definition. Can you propose something a 
> bit more specific?
> 
>