Subject: [dispatch] Updates Session-ID charter

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 10 May 2010 14:22:04 -0400

Howdy,
Here is an updated charter, which I think addresses Gao's concern:

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.

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: [email-masked]
Date: Tue, 11 May 2010 11:20:18 +0800

As your charter is *honest* enough(your emphasizing of "other solutions 
may be possible"), then I am OK with this version.

And I guess you can do the antitheses later in your drafts.

Thanks,

Gao

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

Hadriel Kaplan <[email-masked]> 
发件人:  [email-masked]
2010-05-11 02:22

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

主题
[dispatch] Updates Session-ID charter

Howdy,

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.

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

--------------------------------------------------------
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: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 11 May 2010 14:52:51 +0530

Hi Hadriel,

When multiple B2BUA SIP entities exists, session-id may be used for
other services as well. The charter restricts only to troubleshooting
currently. The session-id has to be considered for other use cases as
well. For example, Media trombone (Media looping) in B2BUA(SBC) due to
call forward from previous B2BUA(3PCC) hop shall be identified by the
proposed session-id. I think that it is better to find the other use
cases for session-id and include in the charter. Any specific reason for
restricting only for troubleshooting only?

Thanks
Partha 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Monday, May 10, 2010 11:52 PM
To: DISPATCH
Subject: [dispatch] Updates Session-ID charter

Howdy,

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.

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. 

Goals and Milestones
====================

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 May 2010 11:02:33 -0400

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2010 5:23 AM
> To: Hadriel Kaplan; DISPATCH
> 
> currently. 

It's not so much "restricts", as much as that's the problem being solved.  I.e., it has a specific, defined problem and goal.  

If you have specific use-cases in mind we can certainly talk about whether they make sense for the charter.

> The session-id has to be considered for other use cases as
> proposed session-id. 

I'm not sure what you mean.  I know what media tromboning is, but I have no idea what that has to do with session-id.  Session-id is a signaling-layer header, not SDP.  In practice you can't really "detect" media tromboning correctly in the real world without looking at SDP.  

You could detect signaling hairpin, but usually you want to do that for media-layer reasons for which you need to look at SDP anyway.  

You could detect signaling loop errors, assuming you're very careful to allow legitimate spirals... but that is logically equivalent to having a built-in monitoring/troubleshooting device.  There are actually several things you can do with a session-id header which fall under that category, none of which change the header in any way at a SIP layer.  I don't think it's necessary in the charter to itemize every use a monitoring device would have for dialog/message correlation.

> I think that it is better to find the other use

Generally we don't work that way - we don't create a solution and then look for what problems it solves. :)  

When I started the session-id draft I was actually trying to solve two problems: troubleshooting, and dialog correlation/matching at the SIP level itself (e.g., for the dialog-event package and others).  But I removed the second use-case based on discussions on the mailing list because it became evident (to me at least) that we would (1) take a long time to converge on it if ever, (2) it was a much harder problem to solve, and (3) it may not be solvable in the same way at all.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 May 2010 11:49:26 -0400

Below is a copy of the email with the current proposed charter.
Cullen was concerned that without defining what end-to-end session or message-flow actually means in the charter, that we would not make progress in a WG.  Therefore, I propose the following text be added to the charter, after the first paragraph:

[begin]
Since the definition of a higher-layer "session" of the same "message-flow" is not already defined by SIP when it involves a B2BUA, the SIPSCOTCH charter's scope is more easily defined in terms of when two SIP dialogs of a B2BUA are so related.  For the purposes of this WG's charter, two or more SIP dialogs on a B2BUA are the same higher-layer session when the following conditions are ALL true:
- The B2BUA is a UAS for the dialog-forming transaction of one dialog, and a UAC for the dialog-forming transaction(s) of the other dialog(s)
- The B2BUA generates one or more dialog-forming requests on its UAC side based on receiving the one on its UAS side, before the UAS-based dialog is in an established state
- The B2BUA ties the fates of the dialogs, such that upon termination of the UAS-based dialog, the B2BUA would automatically terminate the UAC-based dialog(s); and vice-versa

For out-of-dialog SIP requests which do not form dialogs, such as an out-of-dialog SIP MESSAGE request, the same type of rules as stated above apply, but only as applicable to a SIP transaction.

Any solution documents from this working group may expand the scope of their mechanism's correlation, if the working group so decides.
[end]

Comments?  Good enough for now?

-hadriel

> Sent: Monday, May 10, 2010 2:22 PM
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 13 May 2010 11:29:34 -0500

> - The B2BUA ties the fates of the dialogs, such that upon termination of the UAS-based dialog, the B2BUA would automatically terminate the UAC-based dialog(s); and vice-versa

This may not be true; a B2BUA that is really a PBX may not terminate the
leftover dialog when it receives a termination indication for one of
them. If you replaced 'would automatically terminate' with 'would be
likely to terminate', that would probably take care of it.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 May 2010 12:44:08 -0400

> Behalf Of Kevin P. Fleming
> Sent: Thursday, May 13, 2010 12:30 PM
> 

Can you describe such a case?  

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 May 2010 11:56:26 -0500

> Can you describe such a case?

Think about how this kind of system would handle intra-PBX call transfer.

Alice (from outside of Bob's company) calls Bob through Bob's PBX (which 
is acting as a SIP B2BUA). You have two dialogs (Alice <-> PBX, PBX <-> 
Bob). Bob decides to transfer the call to Carol (who is served by the 
same PBX as Bob). While this could be done by REFERing all the way back 
to Alice, what I've seen PBXes typically do in these circumstances is to 
simply set up a new dialog with Carol (PBX <-> Carol), and associate it 
with the original Alice <-> PBX dialog.

So, while the PBX <-> Bob dialog has terminated, the PBX does not 
"automatically terminate" the associated Alice <-> PBX dialog.

See, this is the difficulty in specifying anything about protocol 
behavior *across* a B2BUA: in order to serve their purposes, B2BUAs 
inherently do whatever the heck they want. Positive statements about 
what they will or will not do (e.g., "would automatically terminate") 
are pretty much assured to be wrong for some subset of B2BUAs.

/a

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 13 May 2010 23:00:09 +0530

Here is another use-case that typically happens in center use-case: 
- A customer call lands on a B2BUA that runs an Interactive Voice
Response (IVR) application.
- The application presents a number of options to the user to reach
different departments.
- The customer selects a particular option. The B2BUA places an outbound
call to an agent and associates the two dialogs.
- The agent provides some information to the customer and disconnects.
- The application once again presents a number of options to the
customer to reach other departments.

A calling card application running on a B2BUA that provides an option
for the customer to press long '#' anytime during the call and connect
with a different person would be another use-case.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf
|Of Adam Roach
|Sent: Thursday, May 13, 2010 10:26 PM
|To: Hadriel Kaplan
|Cc: [email-masked]
|Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3
|
|On 5/13/10 11:44 AM, Hadriel Kaplan wrote:
|>
|>> -----Original Message-----
|>> From: [email-masked] [mailto:[email-masked]]
On
|>> Behalf Of Kevin P. Fleming
|>> Sent: Thursday, May 13, 2010 12:30 PM
|>>
|>> This may not be true; a B2BUA that is really a PBX may not terminate
the
|>> leftover dialog when it receives a termination indication for one of
|>> them. If you replaced 'would automatically terminate' with 'would be
|>> likely to terminate', that would probably take care of it.
|>>
|> Can you describe such a case?
|
|Think about how this kind of system would handle intra-PBX call
transfer.
|
|Alice (from outside of Bob's company) calls Bob through Bob's PBX
(which
|is acting as a SIP B2BUA). You have two dialogs (Alice <-> PBX, PBX <->
|Bob). Bob decides to transfer the call to Carol (who is served by the
|same PBX as Bob). While this could be done by REFERing all the way back
|to Alice, what I've seen PBXes typically do in these circumstances is
to
|simply set up a new dialog with Carol (PBX <-> Carol), and associate it
|with the original Alice <-> PBX dialog.
|
|So, while the PBX <-> Bob dialog has terminated, the PBX does not
|"automatically terminate" the associated Alice <-> PBX dialog.
|
|See, this is the difficulty in specifying anything about protocol
|behavior *across* a B2BUA: in order to serve their purposes, B2BUAs
|inherently do whatever the heck they want. Positive statements about
|what they will or will not do (e.g., "would automatically terminate")
|are pretty much assured to be wrong for some subset of B2BUAs.
|
|/a
|_______________________________________________
|dispatch mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 13 May 2010 23:04:47 +0530

missed a word -:)

typically happens in 'contact' center..

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf
|Of Muthu ArulMozhi Perumal (mperumal)
|Sent: Thursday, May 13, 2010 11:00 PM
|To: Adam Roach; Hadriel Kaplan
|Cc: [email-masked]
|Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3
|
|Here is another use-case that typically happens in center use-case:
|- A customer call lands on a B2BUA that runs an Interactive Voice
|Response (IVR) application.
|- The application presents a number of options to the user to reach
|different departments.
|- The customer selects a particular option. The B2BUA places an
outbound
|call to an agent and associates the two dialogs.
|- The agent provides some information to the customer and disconnects.
|- The application once again presents a number of options to the
|customer to reach other departments.
|
|A calling card application running on a B2BUA that provides an option
|for the customer to press long '#' anytime during the call and connect
|with a different person would be another use-case.
|
|Muthu
|
||-----Original Message-----
||From: [email-masked] [mailto:[email-masked]] On
|Behalf
||Of Adam Roach
||Sent: Thursday, May 13, 2010 10:26 PM
||To: Hadriel Kaplan
||Cc: [email-masked]
||Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3
||
||On 5/13/10 11:44 AM, Hadriel Kaplan wrote:
||>
||>> -----Original Message-----
||>> From: [email-masked] [mailto:[email-masked]]
|On
||>> Behalf Of Kevin P. Fleming
||>> Sent: Thursday, May 13, 2010 12:30 PM
||>>
||>> This may not be true; a B2BUA that is really a PBX may not
terminate
|the
||>> leftover dialog when it receives a termination indication for one
of
||>> them. If you replaced 'would automatically terminate' with 'would
be
||>> likely to terminate', that would probably take care of it.
||>>
||> Can you describe such a case?
||
||Think about how this kind of system would handle intra-PBX call
|transfer.
||
||Alice (from outside of Bob's company) calls Bob through Bob's PBX
|(which
||is acting as a SIP B2BUA). You have two dialogs (Alice <-> PBX, PBX
<->
||Bob). Bob decides to transfer the call to Carol (who is served by the
||same PBX as Bob). While this could be done by REFERing all the way
back
||to Alice, what I've seen PBXes typically do in these circumstances is
|to
||simply set up a new dialog with Carol (PBX <-> Carol), and associate
it
||with the original Alice <-> PBX dialog.
||
||So, while the PBX <-> Bob dialog has terminated, the PBX does not
||"automatically terminate" the associated Alice <-> PBX dialog.
||
||See, this is the difficulty in specifying anything about protocol
||behavior *across* a B2BUA: in order to serve their purposes, B2BUAs
||inherently do whatever the heck they want. Positive statements about
||what they will or will not do (e.g., "would automatically terminate")
||are pretty much assured to be wrong for some subset of B2BUAs.
||
||/a
||_______________________________________________
||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: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 13 May 2010 13:29:28 -0500

> are pretty much assured to be wrong for some subset of B2BUAs.

Yes, Adam hit it right on the nose. There are other cases as well...
Alice calls Bob's PBX, the PBX calls Bob, he answers, he chats her up
for a while, and then he hangs up and the PBX keeps Alice's dialog alive
to connect her call to a post-call 'customer service survey'. This sort
of thing happens without Alice's UA being involved except as part of the
initial dialog creation, partly because these devices have provided this
behavior for decades prior to the invention of SIP, when the calling
endpoint wasn't able to be REFERed to a different URI, and there's been
no particular reason to change the implementation of the mechanism just
because SIP endpoints are involved.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 May 2010 15:35:42 -0400

> From: Adam Roach [mailto:[email-masked]]
> Sent: Thursday, May 13, 2010 12:56 PM
> To: Hadriel Kaplan
> 

Ahh, but I *did* take that case into account (or at least I meant to). 

I'm explicitly ruling the new transferred-to dialog *out*, as not the same high-level session.  I'd argue that if Bob sent a REFER (or pressed some button, whatever) and the PBX created a new dialog to Carol out of it, it's not logically different for that new Carol-dialog than if the REFER went all the way back to Alice and she had created a new dialog to Carol from it.  It's not the same session, from the perspective of SIPSCOTCH's correlation scope. 

But it's true that the proposed charter rules wouldn't quite work for even the original dialog pair (Alice-PBX-Bob), because of the rule:
"-The B2BUA ties the fates of the dialogs, such that upon termination of the UAS-based dialog, the B2BUA would automatically terminate the UAC-based dialog(s); and vice-versa"

The problem is the word "upon" and "automatically" which imply instantaneously and under any condition, as Kevin was pointing out.  Maybe the rule would be better phrased as:
"-The B2BUA ties the fates of the dialogs, such that upon termination of the UAS-based dialog, the B2BUA would by-default terminate the UAC-based dialog(s), if it did not have any additional user-input; and vice-versa"?

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 May 2010 14:44:57 -0500

> "-The B2BUA ties the fates of the dialogs, such that upon termination of the UAS-based dialog, the B2BUA would by-default terminate the UAC-based dialog(s), if it did not have any additional user-i…

Actually, I think the most important part of my email was the part you 
chose not to address: once you start constraining what B2BUAs do, you've 
strayed off into territory that makes you automatically wrong. You can 
keep patching your description to try to accommodate the use cases 
people come up with over the next few days or weeks -- but unless your 
crystal ball is a whole heck of a lot more magic than everyone else's 
[1], you're going to miss some.

/a

[1] And if it is, I gander you'd have retired on stock market earnings 
by now.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 May 2010 15:47:11 -0400

> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
> Sent: Thursday, May 13, 2010 1:30 PM
> To: Adam Roach; Hadriel Kaplan
> 

Right, and my current proposal rules those cases out of being the same correlated "session". (the same session for purposes of SIPSCOTCH that is)
Because the original dialog would have gotten to the established state before making those other calls from the App server, and because of the automatic tear-down rule.

Is that an actual problem, though?  I mean do we need to be able to correlate such calls to every new dialog using a SIP header?

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 May 2010 14:48:55 -0500

On 5/13/10 2:35 PM, Hadriel Kaplan wrote:
> I'm explicitly ruling the new transferred-to dialog *out*, as not the 
> same high-level session. I'd argue that if Bob sent a REFER (or 
> pressed some button, whatever) and the PBX created a new dialog to 
> Carol out of it, it's not logically different for that new 
> Carol-dialog than if the REFER went all the way back to Alice and she 
> had created a new dialog to Carol from it. It's not the same session, 
> from the perspective of SIPSCOTCH's correlation scope.

And, upon further inspection, this seems extremely artificial also. What 
if the thing that Alice reaches first isn't Bob, but a "parked call 
queue server" that routes to Carol only when she becomes available? 
Without the PBX having some pretty intimate knowledge about what each 
extension does, I don't think you're going to be able to have any sane 
bright line between what is and what isn't semantically the "same 
session" (unless it is completely inclusive).

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 May 2010 15:52:08 -0400

> Behalf Of Adam Roach
> Sent: Thursday, May 13, 2010 3:45 PM
> 

Nope, I was going to respond to it separately, because it seemed to me to be a more general problem.  But I'll use this email as the vehicle. :)

Right, so we can either give up entirely, or live with not covering every possible thing.  Note that I'm not "constraining" what B2BAU's do - I know they do anything - I'm just constraining when the mechanism needs to be able correlate multiple dialogs.  I'm not preventing B2BAU's from doing whatever they want (nor could I).  This is to help troubleshooting - it's not a SIP state-machine dialog correlation.

Maybe a better alternative is to actually get rid of such rules and say "Two or more dialogs of a B2BUA are correlated under whatever conditions they feel would aid in troubleshooting the dialogs"? (or something along those lines)

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 May 2010 14:55:22 -0500

On 5/13/10 2:52 PM, Hadriel Kaplan wrote:
> Maybe a better alternative is to actually get rid of such rules and 
> say "Two or more dialogs of a B2BUA are correlated under whatever 
> conditions they feel would aid in troubleshooting the dialogs"? (or 
> something along those lines)

If we're going to do this work, that seems the most reasonable direction 
to take it to me.

/a

---

From: Laura Liess <[email-masked]>
Date: Thu, 13 May 2010 22:52:25 +0200

+1

Laura 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im
> Auftrag von Adam Roach
> Gesendet: Donnerstag, 13. Mai 2010 21:55
> An: Hadriel Kaplan
> Cc: [email-masked]
> Betreff: Re: [dispatch] Proposed update to Session-ID charter, round-3
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 May 2010 17:40:10 -0400

How about this...

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 whatever conditions they feel would aid in troubleshooting the dialogs, 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.

Goals and Milestones
====================

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 13 May 2010 17:27:58 -0500

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

This works for me.

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 13 May 2010 19:55:04 -0400

+1

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 May 2010 08:59:28 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 13 May 2010 22:40
> To: DISPATCH
> Subject: [dispatch] Proposed update to Session-ID charter, round-4
> 
> How about this...
> 
> 
> 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 
> 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 whatever conditions 
> they feel would aid in troubleshooting the dialogs,
[JRE] So dialogs have feelings?

I would suggest rewording "....under any conditions where correlation might aid troubleshooting."

John

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

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 14 May 2010 13:02:00 +0530

Yes, the domain of the problem is the same irrespective of whether the
initial dialog goes to an established state or not before the SBC/3PCC
initiates a new dialog and associates them -- we need a uniform SIP
header to correlate/associate all dialogs that are part of a multimedia
communication session and derive the sequence of messages/events that
lead to the problem.

Muthu

|-----Original Message-----
|From: Hadriel Kaplan [mailto:[email-masked]]
|Sent: Friday, May 14, 2010 1:17 AM
|To: Muthu ArulMozhi Perumal (mperumal); Adam Roach
|Cc: [email-masked]
|Subject: RE: [dispatch] Proposed update to Session-ID charter, round-3
|
|> -----Original Message-----
|> From: Muthu ArulMozhi Perumal (mperumal) [mailto:[email-masked]]
|> Sent: Thursday, May 13, 2010 1:30 PM
|> To: Adam Roach; Hadriel Kaplan
|>
|> Here is another use-case that typically happens in center use-case:
|> - A customer call lands on a B2BUA that runs an Interactive Voice
|> Response (IVR) application.
|> - The application presents a number of options to the user to reach
|> different departments.
|> - The customer selects a particular option. The B2BUA places an
outbound
|> call to an agent and associates the two dialogs.
|> - The agent provides some information to the customer and
disconnects.
|> - The application once again presents a number of options to the
|> customer to reach other departments.
|>
|> A calling card application running on a B2BUA that provides an option
|> for the customer to press long '#' anytime during the call and
connect
|> with a different person would be another use-case.
|
|Right, and my current proposal rules those cases out of being the same
|correlated "session". (the same session for purposes of SIPSCOTCH that
is)
|Because the original dialog would have gotten to the established state
|before making those other calls from the App server, and because of the
|automatic tear-down rule.
|
|Is that an actual problem, though?  I mean do we need to be able to
|correlate such calls to every new dialog using a SIP header?
|
|-hadriel

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 14 May 2010 13:31:59 +0530

|Maybe a better alternative is to actually get rid of such rules and 
|say "Two or more dialogs of a B2BUA are correlated under whatever 
|conditions they feel would aid in troubleshooting the dialogs"? 
|(or something along those lines)

Sounds more reasonable. I've a feeling that we should RECOMMEND that
this header be used for troubleshooting. However, if someone wants to
extent it in future and use it for some other purpose other than
troubleshooting, we shouldn't block it.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf
|Of Hadriel Kaplan
|Sent: Friday, May 14, 2010 1:22 AM
|To: Adam Roach
|Cc: [email-masked]
|Subject: Re: [dispatch] Proposed update to Session-ID charter, round-3
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Adam Roach
|> Sent: Thursday, May 13, 2010 3:45 PM
|>
|> Actually, I think the most important part of my email was the part
you
|> chose not to address: once you start constraining what B2BUAs do,
you've
|> strayed off into territory that makes you automatically wrong. You
can
|> keep patching your description to try to accommodate the use cases
|> people come up with over the next few days or weeks -- but unless
your
|> crystal ball is a whole heck of a lot more magic than everyone else's
|> [1], you're going to miss some.
|
|Nope, I was going to respond to it separately, because it seemed to me
to be
|a more general problem.  But I'll use this email as the vehicle. :)
|
|Right, so we can either give up entirely, or live with not covering
every
|possible thing.  Note that I'm not "constraining" what B2BAU's do - I
know
|they do anything - I'm just constraining when the mechanism needs to be
able
|correlate multiple dialogs.  I'm not preventing B2BAU's from doing
whatever
|they want (nor could I).  This is to help troubleshooting - it's not a
SIP
|state-machine dialog correlation.
|
|Maybe a better alternative is to actually get rid of such rules and say
"Two
|or more dialogs of a B2BUA are correlated under whatever conditions
they
|feel would aid in troubleshooting the dialogs"? (or something along
those
|lines)
|
|-hadriel
|_______________________________________________
|dispatch mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 May 2010 12:08:05 -0400

There are tradeoffs here.

If the decision is to say that B2BUAs can use the same session id to 
correlate dialogs whenever they feel that would correlate 
troubleshooting, then it is going to be very difficult to determine when 
it may also be suitable for any other purpose. Even for troubleshooting, 
it will only be useful for the sort of troubleshooting that the B2BUAs 
that did the marking had in mind. For instance, for some troubleshooting 
purposes you would want to correlate all the call legs in Adam's 
example. But somebody else might not want to.

It might be just as useful to say this can be associated with multiple 
dialogs when the thing doing the marking thinks it would be useful to 
correlate those things. (For whatever purpose.) But of course that will 
only be useful if you control all the things that do the marking.

IMO, to be generally useful in an interoperable way without explicit 
configuration, I think the criteria for applying the same session id to 
multiple dialogs will need to be defined in a more precise way. Hadriel 
wants this to be for "troubleshooting", so perhaps that purpose can be 
refined into some specific criteria.

	Thanks,
	Paul

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Fri, 14 May 2010 14:03:11 -0400

The basic intention of Hadriel's original proposal is actually easy to state (although every significant term in the statement is not well defined):

>> Session-Id is what Call-Id would be if a SIP purist replaced every B2BUA with a proper proxy.

In particular, two dialogs with the same Session-Id would carry the same media (possibly with transcoding).  So it is clear that the three legs coming from a conference focus would have different Session-Id.

This is a particularly narrow relationship, but is thus quite useful in the very common case where a dialog effectively passes through an SBC.

The opposite approach is used in the "References" header (draft-worley-references), marking dialogs as being related if there is any relationship at all between them.  But of course, that can lead to large clusters of dialogs being related in ways that don't form a linear string.  (This is made easier by relating dialogs by naming their Call-Ids rather than marking them with the same token.)

In any case, the current charter proposal moves in the right direction by leaving the decision of the concept and scope of "relatedness" to the working group.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 May 2010 15:16:51 -0400

I disagree. :)

If people feel this is only going to be usable across SBCs, they should say so right now - because the problem for just correlating across SBCs would be simpler, and the solution different I think.

The *intention* is to correlate dialogs that cross through other B2BUA's than just SBC's.  A classic example would be a PBX or Softswitch, which while arguably could be Proxies in theory, in practice are often B2BUA's and change the Call-ID.  Likewise App Servers, Feature Servers, and such which reside in the path of the initial "call".  

For media-based sessions, such B2BUA's actually can and do represent different media sources at different points in the call; for example app servers which generate specific tones/music to the UAC while they hunt for the called party.  I guess we could say "carry only one media session at any given time", as long as it's clear the intent is also to cover SUBSCRIBE-based dialogs and other transactions which have no associated media.

As for the conference server - that's the one I think where we really disagree the most.  Obviously to a human all the dialogs of a conference are "related", but I think that relationship is at a _much_ higher layer than a normal "call" (if one could describe such things in layers).  For example, each person makes an individual call to the server and can come and go without the conference "session" ending.  In fact, it seems to me that in practice most conference calls in SIP are not conference-aware at a SIP layer; I know some that are, and maybe it's more popular to do so in Enterprises, but there're a ton of conference calls which are just SIP calls, made to a common number, and all the "conferencing" is handled at a higher layer, purely through DTMF presses and media.  In theory they can even switch which conference they're in, during the same SIP session.

In some ways there really are different "layers" or "levels" of correlation/relationships.  I'm not convinced any one correlation mechanism can handle them all, or should.

-hadriel

> Behalf Of WORLEY, Dale R (Dale)
> Sent: Friday, May 14, 2010 2:03 PM
> 
> The basic intention of Hadriel's original proposal is actually easy to
> state (although every significant term in the statement is not well
> defined):
> 
> In particular, two dialogs with the same Session-Id would carry the same
> media (possibly with transcoding).  So it is clear that the three legs
> coming from a conference focus would have different Session-Id.
> 
> This is a particularly narrow relationship, but is thus quite useful in
> the very common case where a dialog effectively passes through an SBC.
> 
> The opposite approach is used in the "References" header (draft-worley-
> references), marking dialogs as being related if there is any relationship
> at all between them.  But of course, that can lead to large clusters of
> dialogs being related in ways that don't form a linear string.  (This is
> made easier by relating dialogs by naming their Call-Ids rather than
> marking them with the same token.)
> 
> In any case, the current charter proposal moves in the right direction by
> leaving the decision of the concept and scope of "relatedness" to the
> working group.
> 
> Dale

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Fri, 14 May 2010 16:23:31 -0400

From: Hadriel Kaplan [[email-masked]]
> I disagree. :)
> 
> If people feel this is only going to be usable across SBCs, they
> should say so right now - because the problem for just correlating
> across SBCs would be simpler, and the solution different I think.
> 
> The *intention* is to correlate dialogs that cross through other
> B2BUA's than just SBC's.  A classic example would be a PBX or
> Softswitch, which while arguably could be Proxies in theory, in
> practice are often B2BUA's and change the Call-ID.  Likewise App
> Servers, Feature Servers, and such which reside in the path of the
> initial "call".

> For media-based sessions, such B2BUA's actually can and do represent
> different media sources at different points in the call; for example
> app servers which generate specific tones/music to the UAC while they
> hunt for the called party.  I guess we could say "carry only one media
> session at any given time", as long as it's clear the intent is also
> to cover SUBSCRIBE-based dialogs and other transactions which have no
> associated media.

That's an interesting point -- despite all of the dialogs in a chain
being "the same call", they might not always carry the same media.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 May 2010 19:55:32 -0400

Hadriel Kaplan wrote:
> For media-based sessions, such B2BUA's actually can and do represent different media sources at different points in the call; for example app servers which generate specific tones/music to the UAC while they hunt for the called party. 

I find very little difference between this scenario and one where the 
call is first answered by a secretary and then transferred to the 
intended callee. (Does it matter that the secretary is automated?)

I'm a bit confused about how things should work if the transfer case 
does *not* share the same session-id:

	A ----------- B ----------- C
	              |
	              |------------ D

Initially from A via B2BUA B to C, and gets Session-ID X applied to both 
the A-B leg and the B-C leg. Then B replaces the B-C "leg" with the B-D 
"leg". If the B-D leg doesn't get session-id X, and instead gets 
session-ID Y, does A-B then also get a new session-id of Y??? It seems 
it must if the correlation is to work for that.

That then means that a single dialog, A-B has more than one session-id: 
X and Y. Is that what is intended???

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 May 2010 21:18:14 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, May 14, 2010 7:56 PM
> 
> Hadriel Kaplan wrote:
> >
> different media sources at different points in the call; for example app
> servers which generate specific tones/music to the UAC while they hunt for
> the called party.
> 

In the case I was describing, the first dialog leg doesn't reach an established state until the party is found.  If it *did*, which happens in some find-me-follow-me app servers, then I would think they're really separate session-ids.  I'm not super-tide to that position, just seems logical to me for some reason.

> X and Y. Is that what is intended???

In the current Session-ID draft, it makes no statement about that, iirc.  
I think that's one of the things the SIPSCOTCH WG must decide: whether A-B-D is in fact the same session-id as A-B-C.  If it *is*, then I'd argue a transferred call from A directly to D, replacing A-B-C, is also the same session-id.

I can see it both ways.  Arguably, if A-B-C got to the established state, that was higher-layer Call-1.  If B-C gets replaced with B-D, then A-B-D is Call-2.  On the other hand, from a troubleshooting perspective it would be nice to know those dialogs are all related.

Note that once you open the door for the session-id to go beyond the initial established call, it can get weird and complicated.

For example, what happens if you call a public-announcement broadcaster server; you press some special codes, record an announcement, and press "broadcast"; do the sessions it creates for you use the same session-id as your call?

Or take your example above, B-D could have replaced B-C by *D* sending an INVITE with replaces to *B*.  So we'd have to get the Session-ID value to D so it can use it in its INVITE to B, like by C passing it in the Refer-To of a REFER to D.  OK, so now imagine if B parked the call and Referred D to C, and you ended up with 2 dialogs A-B, C-D as below.  But they'd be using the same session-id.  Is that legit? (maybe, I dunno)

 	A ----------- B             C
 	                            |
 	                            D

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 15 May 2010 00:00:37 -0400

Hadriel,

I don't disagree with anything you say below.
But it is also what is troubling to me.

It seems there is no one obvious definition for which dialogs should be 
related - there are good reasons for each of several possible 
definitions. Yet its hard to imagine supporting them all. And leaving it 
to the discretion of each server seems even worse. So I don't see how to 
decide on a definition.

	Thanks,
	Paul