Subject: [dispatch] SIPSCOTCH/session-id charter scope

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Jul 2010 04:07:48 -0400

Howdy,
One of the objections to the currently proposed SIPSCOTCH charter is on how one knows whether to use the same session-id or not - i.e., what defines the same higher layer session.  

In particular, the following paragraph of the 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 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."

This objection was also raised on the DISPATCH mailing list thread starting here:
http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html

I believe the available options to handle this issue are:

1) Defer it to the new WG's solution doc to specify.

2) Try to articulate rules in the charter for when two messages/dialogs are part of the same "session".  This was actually attempted in a previous incarnation of the charter, in an email thread starting here:
http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html

3) Instead of defining "rules", try to enumerate examples/use-cases which are and are-not in scope to be the same session.

Any comments/preferences?

-hadriel

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 28 Jul 2010 10:19:57 +0200

Hi Hadriel,

I guess I favour a mix of (1) and (2). I don't think a charter needs
to define the rules (that's what the doc is for!) I think the issue is
to ensure that the charter does not leave an opening for this to
become a 'rat hole' and devolve into a long discussion about dialog
correlation (which is in principle not technically possible).

How about a charter statement of:
"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, simple rules for conveyance of session-ID will be defined for
the common cases of through calls, forked calls, Refer and Join. These
rules will be selected based on maximizing their value to
troubleshooting in the common cases. "

Peter Musgrave

On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan <[email-masked]> wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Laura Liess <[email-masked]>
Date: Wed, 28 Jul 2010 16:20:14 +0200

+1
I fully agree with Peter's text proposal. From my point of view, the
correlation rules are part of the problem we need to solve in the WG. We can
not state the rules in the charter, we can state that the WG should define
such rules. And because it may be not possible to define clear general rules
working for the most general case, the proposal to define rules for the
common use cases seems quite reasonable to me. 

Thanks  a lot,
Laura

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im
> Auftrag von Peter Musgrave
> Gesendet: Mittwoch, 28. Juli 2010 10:20
> An: Hadriel Kaplan
> Cc: [email-masked]
> Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope
> 
> Hi Hadriel,
> 
> > One of the objections to the currently proposed SIPSCOTCH charter is
> on how one knows whether to use the same session-id or not - i.e., what
> defines the same higher layer session.
> >
> > "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."
> >
> > 2) Try to articulate rules in the charter for when two
> messages/dialogs are part of the same "session".  This was actually
> attempted in a previous incarnation of the charter, in an email thread
> starting here:
> > 3) Instead of defining "rules", try to enumerate examples/use-cases
> which are and are-not in scope to be the same session.
> >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 28 Jul 2010 16:47:13 +0200

+1

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Laura Liess
> Sent: 28 July 2010 15:20
> To: 'Peter Musgrave'; 'Hadriel Kaplan'
> Cc: [email-masked]
> Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope
> 
> 
> +1

---

From: <[email-masked]>
Date: Wed, 28 Jul 2010 16:50:58 +0200

+1
I support this too.

Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Laura Liess
Gesendet: Mittwoch, 28. Juli 2010 16:20
An: 'Peter Musgrave'; 'Hadriel Kaplan'
Cc: [email-masked]
Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope

+1

Thanks  a lot,
Laura

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 28 Jul 2010 17:01:29 +0200

+1

-- 
Victor Pascual Ávila

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 29 Jul 2010 03:13:20 +0530

Hadriel,

Session is a misnomer as it may be related to two or more dialogs depend upon the B2BUA, Focus behavior. As you mentioned in point 3, it is better to focus on the complex use cases document where the troubleshooting is really tough in the SIP networks. Existing 3PCC, BLISS callflow, conference callflow shall be referenced. The common industry standard call services like Call transfer, call hold shall be added as usecase. This will help in creating the clear session-id charter. 

I'm sort of thinking that B2BUA will not abuse this session-id but SBC *may*.  

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Pascual Avila
Sent: Wednesday, July 28, 2010 8:31 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope

+1

On Wed, Jul 28, 2010 at 4:50 PM,  <[email-masked]> wrote:
> Auftrag von Laura Liess
> correlation rules are part of the problem we need to solve in the WG. 
> We can not state the rules in the charter, we can state that the WG 
> should define such rules. And because it may be not possible to define 
> clear general rules working for the most general case, the proposal to 
> define rules for the common use cases seems quite reasonable to me.
>
> Thanks  a lot,
> Laura
>
>
>
>> to define the rules (that's what the doc is for!) I think the issue 
>> is to ensure that the charter does not leave an opening for this to 
>> normatively define in practice.  For the purposes of this WG 
>> charter's scope, simple rules for conveyance of session-ID will be 
>> defined for the common cases of through calls, forked calls, Refer 
>> and Join. These rules will be selected based on maximizing their 
>> value to troubleshooting in the common cases. "
>>
>>
>> Peter Musgrave
>>
>> on how one knows whether to use the same session-id or not - i.e., 
>> what defines the same higher layer session.
>> >
>> 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."
>> >
>> attempted in a previous incarnation of the charter, in an email 
>> thread starting here:

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 29 Jul 2010 07:39:22 +0200

HI Partha,

I think is better to focus on the common use cases (whether they are
complex or simple). IMHO the majority of them are usually not more
complicated than a REFER.

I think as part of the doc review we can evaluate cases from 3PCC and
BLISS callflow examples and see what interest there is them. I do not
see the need to make this specific in the charter.

I think (to channel JDR) "Let's not let the perfect be the enemy of
the good". I think the existing charter text does discusses the
mechanics (REFER, forking) which are basic to SIP and the specific use
cases can be discussed in the contexts you are suggesting without a
change to the charter text I suggested.

Peter

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 29 Jul 2010 13:41:30 +0530

Hi Peter/Hadriel,

IMO, we are far from perfection as SBC which is a industry accepted SIP entity not considered in this charter. SBC is a complex entity compares to simple IETF defined entities like B2BUA. I'm making the point that IETF WG (SIPSCOTCH) has to atleast consider creating the session identity which satisfy all IETF SIP defined entities like B2BUA, Focus for this new session-id. This will be helpful for complex entity like SBC to scale the proposed mechanism.

I'm not looking for perfect solution but I don't want to see the multiple version of session-ids RFCs in the forthcoming years as we narrow down too much now. The session-id has to be extensible or scalable. As a B2BUA implementer, I'll come with some of the commonly deployment industry callflows like REFER handling by 3PCC B2BUA and also, expect the other implementers to provide the input on the same line for better troubleshooting using session-id.

BTW, I never thought that the troubleshooting B2BUA/SBC has protocol dependency as the troubleshooting is being done with receiving/sending SIP messages even in the complex customer deployment. Also, B2BUA/SBC entity which I'm talking about interop with most of the B2BUA/SBC in the Enterprise/Service provider network. ISTM, I'm using the industry best practices/tools to troubleshoot/debug without protocol dependency.

Having said that, I'm in agreement for this WG as the proposed session-id will facilitate for innovative application/service in SIP. 

Thanks
Partha

-----Original Message-----
From: Peter Musgrave [mailto:[email-masked]] 
Sent: Thursday, July 29, 2010 11:09 AM
To: Parthasarathi R (partr)
Cc: Victor Pascual Avila; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope

HI Partha,

I think is better to focus on the common use cases (whether they are complex or simple). IMHO the majority of them are usually not more complicated than a REFER.

I think as part of the doc review we can evaluate cases from 3PCC and BLISS callflow examples and see what interest there is them. I do not see the need to make this specific in the charter.

I think (to channel JDR) "Let's not let the perfect be the enemy of the good". I think the existing charter text does discusses the mechanics (REFER, forking) which are basic to SIP and the specific use cases can be discussed in the contexts you are suggesting without a change to the charter text I suggested.

Peter

On Wed, Jul 28, 2010 at 11:43 PM, Parthasarathi R (partr) <[email-masked]> wrote:
>> should define such rules. And because it may be not possible to 
>> define clear general rules working for the most general case, the 
>> proposal to define rules for the common use cases seems quite reasonable to me.
>>
>> Thanks  a lot,
>> Laura
>>
>>
>>
>>> 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."
>>> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Jul 2010 08:15:12 -0400

Hi Partha,
I'm not sure exactly what you mean.  This discussion is just about the SIPSCOTCH charter.  As far as the *charter* is concerned, it has the following sentence:
"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."  So as far as the charter's concerned, SBC's are included.

With Peter's changes, the charter would also specify that the solution "will be defined for the common cases of through calls, forked calls, Refer and Join."

Note that the session-id draft, which is a proposed potential solution for SIPSCOTCH, goes into actual detail with regards to B2BUA behavior, forking, REFER, and Replaces behavior.  

So what *exactly* is missing from the *charter* that you'd like us to add?  Can you suggest text?

-hadriel

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: Thursday, July 29, 2010 4:12 AM
> To: Peter Musgrave
> Cc: Victor Pascual Avila; [email-masked]; [email-masked]; Hadriel
> Kaplan
> Subject: RE: [dispatch] SIPSCOTCH/session-id charter scope
> 
> Hi Peter/Hadriel,
> 
> IMO, we are far from perfection as SBC which is a industry accepted SIP
> entity not considered in this charter. SBC is a complex entity compares to
> simple IETF defined entities like B2BUA. I'm making the point that IETF WG
> (SIPSCOTCH) has to atleast consider creating the session identity which
> satisfy all IETF SIP defined entities like B2BUA, Focus for this new
> session-id. This will be helpful for complex entity like SBC to scale the
> proposed mechanism.
> 
> I'm not looking for perfect solution but I don't want to see the multiple
> version of session-ids RFCs in the forthcoming years as we narrow down too
> much now. The session-id has to be extensible or scalable. As a B2BUA
> implementer, I'll come with some of the commonly deployment industry
> callflows like REFER handling by 3PCC B2BUA and also, expect the other
> implementers to provide the input on the same line for better
> troubleshooting using session-id.
> 
> BTW, I never thought that the troubleshooting B2BUA/SBC has protocol
> dependency as the troubleshooting is being done with receiving/sending SIP
> messages even in the complex customer deployment. Also, B2BUA/SBC entity
> which I'm talking about interop with most of the B2BUA/SBC in the
> Enterprise/Service provider network. ISTM, I'm using the industry best
> practices/tools to troubleshoot/debug without protocol dependency.
> 
> Having said that, I'm in agreement for this WG as the proposed session-id
> will facilitate for innovative application/service in SIP.
> 
> Thanks
> Partha
> 
> BLISS callflow examples and see what interest there is them. I do not see
> the need to make this specific in the charter.
> 
> I think (to channel JDR) "Let's not let the perfect be the enemy of the
> good". I think the existing charter text does discusses the mechanics
> (REFER, forking) which are basic to SIP and the specific use cases can be
> discussed in the contexts you are suggesting without a change to the
> charter text I suggested.
> 
> Peter
> 
> > Session is a misnomer as it may be related to two or more dialogs depend
> upon the B2BUA, Focus behavior. As you mentioned in point 3, it is better
> to focus on the complex use cases document where the troubleshooting is
> really tough in the SIP networks. Existing 3PCC, BLISS callflow,
> conference callflow shall be referenced. The common industry standard call
> services like Call transfer, call hold shall be added as usecase. This
> will help in creating the clear session-id charter.
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Jul 2010 08:33:08 -0400

Hi Peter,
I like it too.

One question - when you say "rules" in the sentence:
"For the purposes of this WG charter's scope, simple rules for conveyance of session-ID will be defined for the common cases of through calls, forked calls, Refer and Join." 

...do you mean rules that may end up to be "these are not the same identifier"?  In other words, would this charter text allow us to define something like session-id and say a Join call does NOT use the same session-id, and still comply with the charter because we defined a rule for Join?

-hadriel

> Sent: Wednesday, July 28, 2010 4:20 AM
> To: Hadriel Kaplan
> Cc: [email-masked]
> > One of the objections to the currently proposed SIPSCOTCH charter is on
> how one knows whether to use the same session-id or not - i.e., what
> 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
> > 2) Try to articulate rules in the charter for when two messages/dialogs
> are part of the same "session".  This was actually attempted in a previous
> incarnation of the charter, in an email thread starting here:

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 29 Jul 2010 15:12:04 +0200

Precisely.

I mean that we define what happens to the session id (use the same,
use A or B, make a new one etc.) for each of the actions (through
call, fork, REFER etc.)

Peter

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Jul 2010 10:15:44 -0400

Ooops, sorry I didn't notice your email's last line (below).

So do you think the charter as written provides enough scope, or would you like to suggest some addition to it?

Thanks!
-hadriel