Subject: Re: [Insipid] Are we ready to LC on the requirements?

From: James Polk <[email-masked]>
Date: Sun, 17 Feb 2013 23:41:10 -0600

Paul

see inline

At 02:34 PM 1/11/2013, Paul Kyzivat wrote:
>(Sorry that this is long. I don't know how to make it short.)
>
>Are we ready to LC? I don't think so. Specifically I don't think we 
>yet have an unambiguous definition of what is being identified.
>
>This version added some new text:
>
>    In this document, the word "session" refers to a "communication
>    session" that may exist between two SIP user agents and that may pass
>    through one or more intermediary devices, including B2BUAs or SIP
>    proxies. A communication session consists of one of more SIP
>    transactions. A very simple communication session may be a single
>    out-of-dialog SIP transaction (e.g., MESSAGE/200).  In the case of a
>    SIP dialog, the SIP message exchange includes a dialog creating
>    INVITE transaction, and zero of more subsequent SIP transactions
>    within the same dialog (e.g., ACK, re-INVITE, BYE).  Due to the
>    existence of middle boxes, there may be multiple related SIP
>    transactions or dialogs chained together along the path from one end
>    of the communication session to the other. For example:
>
>                   A               Middlebox               B
>                   SIP trans1 -----------------> SIP trans 2
>                   SIP dialog 1 <-------------- SIP dialog 2
>
>              Figure 1 - Communication Session through a Middlebox
>
>    In such cases, the two SIP transactions or dialogs are part of a
>    single communication session.
>
>    The term "end-to-end" in this document means the communication
>    session from the point of origin, passing through any number of
>    intermediaries, to the ultimate point of termination. It is
>    recognized that legacy devices may not support the "end-to-end"
>    session identifier, though an identifier might be created by an
>    intermediary when it is absent from the session signaling.
>
>IMO this is a big improvement.

I'm glad

>But it still isn't as precise as I would like.

grrrr... I knew there was a catch  :-)

>What I find lacking in the above is:
>
>o  parsing the above, the properties of a communication session are:
>    - connects *two* UAs
>    - optionally includes one or more intermediary devices
>    - one or more transactions
>    - one out-of-dialog transaction,
>      OR a dialog including the dialog establishing transaction
>      and some transactions within the dialog.
>    - middle boxes may result in chaining dialogs or transactions.
>
>    Exactly how all these properties "plug together" fuzzy.
>    I'm not at all certain that all readers would reach
>    the same conclusion about which cases meet these criteria
>    and which don't.

that's why we have incorporating a series of amazing color pict... oh 
yeah... IETF docs are still limited to B&W ASCII art.

;-)

>o  I'm also not certain that these criteria match all the cases
>    people expect, and exclude all the cases people think should
>    be excluded.

Are we talking the WG requirements doc, or our solution doc.

Any WG solution doc has to cover all the requirements, but once it 
does that, it's not limited to only follow what the requirements doc 
has it in, and that's it. If there is low hanging fruit, grab it.

>    - I think people expect that a conference is *not* a single
>      communications session. But a conference with only two
>      participants would seem to qualify according to all of the
>      above criteria. So that suggests that another criterion is
>      needed to exclude that case.

Again = are we talking the WG requirements doc, or our solution doc.

>    - A topologically similar case to the conference is a
>      click-to-dial case where a web server makes outward INVITEs
>      to two UAs and connects them. I think people believe this
>      case *should* be a communications session.

that sounds to me like 3PCC, which a vocal minority of the WG 
definitely want excluded, at least from the reqs doc.

>    - Another case is described in
>      http://www.ietf.org/mail-archive/web/insipid/current/msg00429.html
>      and debated in the replies to that. Arguments are made for
>      different answers to what should get a common session id and what
>      should not. For this case I think we need to decide:
>      . do we mandate exactly how this should be treated?
>      . or do we leave it to the discretion of the B2BUA to decide?

I've described my take on that, and I included pictures (ok, a ASCII 
diagram) and in a nutshell, that's a B2BUA forking into a conference 
two different UAs on Bob's side and what does Alice see? Does she see 
Bob's phone as a separate dialog from that to Bob's computer? Alice 
only sent one INVITE, which was suggested the B2BUA went in a spliced 
apart the SDP (something SIP intermediaries aren't supposed to do). 
In my feeble mind, the B2BUA because not only dialog stateful, but 
media terminating (because it needs to adjust where Alice's audio and 
video samples go). This is conferencing my friend, and we don't have 
that in our reqs doc or charter.

>      Either way we need to decide what the criteria are that lead
>      to the decision.

we need to get conferencing in scope of the charter. I've tried and 
failed. Maybe you should now try...

>o  IIRC Hadriel suggested (in a meeting?) that where media
>    originates and terminates has something to do with this.
>    That doesn't work all the time (e.g. MESSAGE), but it might help
>    in some cases. I think he used this to justify that:
>
>    - the Conference Bridge Transcoding Model (RFC5369 section 3.2)
>      is a single communications session.

charter says this is out of scope, and we have no requirements to do this...

>    - the 3PCC Transcoding Model (RFC5369 section 3.1) is *not*
>      a single communications session.

Charter doesn't say whether this is in or out of scope (usually that 
means out), plus a vocal minority want it removed from the reqs doc.

>    (I'm not convinced - this seems like a distinction without
>    a difference.)
>
>Fundamentally we should be able to classify all cases into:
>- those that *should* be communications sessions,
>- those that *shouldn't* be communication sessions,
>- those we don't care about - could be either way.

are we going to take another year to have this exhaustive discussion, 
or can we have this be a short discussion that everyone can live 
with? I'm for the latter.

>When we are done, we should be able to apply the definition of 
>communication session to any case. When applied to the cases we 
>explicitly care about it should deliver the answer we expect.

?

>The more weird cases we care about, the more complex and unintuitive 
>the criteria will be. I suspect that the path we are on will lead to 
>complex criteria. (We can have a really crisp definition of 
>communications session if we don't care much about which cases qualify.)
>
>One idea I considered is to define some new terms that build on 
>normal sip concepts but extend them to allow B2BUA intermediaries 
>where sip allows proxies. E.g.
>- Transaction++ is either a sip transaction, or a series of sip
>   transactions linked by B2BUA intermediaries.
>
>- Dialog++ is either a sip dialog, or a series of sip dialogs
>   linked by B2BUA intermediaries.
>
>Then would need to define the behavior of a B2BUA intermediary.

...ok, two to five years ... and maybe we can restart the Session-ID 
work again...

Seriously though, a B2BUA is mentioned in 3261, authored 11 years 
ago, hundreds of folks working on defining the protocol and its 
entities, and you think now we need to define an entity that is in 
the old of a doc is realistic in the next little while?

(psst, our milestones are already two months old)

James

>It needs to relay transactions from one "side" to the other, 
>preserving certain invariants (TBD). Presumably it can also 
>originate certain transactions, but there must be constraints on 
>what it can do. There must also be some rules on how media is 
>handled across one of these intermediaries.
>
>If that was done, then a communication session could be defined as a 
>Transaction++ for an out-of-dialog request, or a Dialog++.
>
>But that makes the definition of communication session the first 
>priority and the cases that happen to qualify as a communication 
>session a consequence. It probably won't match people's intuitive 
>feelings about what *should* be a communication session. So it might 
>not satisfy people.
>
>         Thanks,
>         Paul
>
>
>On 1/10/13 6:04 PM, Charles Eckel (eckelcu) wrote:
>> From my point of view, the draft looks good. The changes 
>> incorporated in this updated version directly address this open issue.
>>
>>Cheers,
>>Charles
>>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] On
>>>Behalf Of Gonzalo Salgueiro (gsalguei)
>>>Sent: Thursday, January 10, 2013 12:39 PM
>>>To: Paul E. Jones
>>>Cc: [email-masked]
>>>Subject: Re: [Insipid] Are we ready to LC on the requirements?
>>>
>>>Thanks for submitting this, Paul.  The biggest open issue in regards to the
>>>requirements document was to clearly define what it is we are identifying
>>>(i.e., "communication session") within the scope of this document and
>>>ensure that clearly defined language is used consistently throughout the
>>>document.  Prior to any consensus on moving to WGLC, the chairs would
>>>appreciate hearing the group's thoughts on where we are on this issue in
>>>the current version.
>>>
>>>Cheers,
>>>
>>>Gonzalo & Keith
>>>
>>>
>>>
>>>On Jan 9, 2013, at 9:23 PM, Paul E. Jones wrote:
>>>
>>>>Folks,
>>>>
>>>>Dialog has been extremely light on the requirements document.  Do
>>>people feel generally OK with it as it is now?  Can we move on to the
>>>solution document now or are there other changes needed in the
>>>requirements document?
>>>>
>>>>I just posted the -04 version with changes proposed on the list over the
>>>past month or so.
>>>>
>>>>Paul
>>>>
>>>>_______________________________________________
>>>>insipid mailing list
>>>>[email-masked]
>>>>https://www.ietf.org/mailman/listinfo/insipid
>>>
>>>_______________________________________________
>>>insipid mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/insipid
>>_______________________________________________
>>insipid mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/insipid
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 21 Feb 2013 21:51:33 -0500

Paul,

I read your message, but was left unsure of exactly how we could improve the
definition over what we have already.

If there is something concrete that you can propose that would help lend to
clarity of the text, I'm definitely willing to put it in.  I would like to
move the requirements along and the submission deadline is Monday.  Do you
have text you would like to add before the deadline?

Paul

> Behalf Of Paul Kyzivat
> Sent: Friday, January 11, 2013 3:34 PM
> To: [email-masked]
> Are we ready to LC? I don't think so. Specifically I don't think we yet
> have an unambiguous definition of what is being identified.
> 
> IMO this is a big improvement. But it still isn't as precise as I would
> like. What I find lacking in the above is:
> 
> The more weird cases we care about, the more complex and unintuitive the
> criteria will be. I suspect that the path we are on will lead to complex
> criteria. (We can have a really crisp definition of communications
> session if we don't care much about which cases qualify.)
> 
> One idea I considered is to define some new terms that build on normal
> sip concepts but extend them to allow B2BUA intermediaries where sip
> allows proxies. E.g.
> Then would need to define the behavior of a B2BUA intermediary. It needs
> to relay transactions from one "side" to the other, preserving certain
> invariants (TBD). Presumably it can also originate certain transactions,
> but there must be constraints on what it can do. There must also be some
> rules on how media is handled across one of these intermediaries.
> 
> priority and the cases that happen to qualify as a communication session
> a consequence. It probably won't match people's intuitive feelings about
> what *should* be a communication session. So it might not satisfy people.
> 
> 	Thanks,
> 	Paul
> 
> 
> >>From my point of view, the draft looks good. The changes incorporated
> in this updated version directly address this open issue.
> >
> > Cheers,
> > Charles
> >
> >> Thanks for submitting this, Paul.  The biggest open issue in regards
> >> to the requirements document was to clearly define what it is we are
> >> identifying (i.e., "communication session") within the scope of this
> >> document and ensure that clearly defined language is used
> >> consistently throughout the document.  Prior to any consensus on
> >> moving to WGLC, the chairs would appreciate hearing the group's
> >> thoughts on where we are on this issue in the current version.
> >>
> >> Cheers,
> >>
> >> Gonzalo & Keith
> >>
> >>
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 23 Feb 2013 19:58:41 -0500

> have text you would like to add before the deadline?

I'm traveling on business and have limited internet access, and limited 
time, so I probably can't.

In any case, ISTM that the problem isn't that we don't have the right 
words. Rather, we still don't have clear *concepts* that distinguish 
what should be covered from what should not. We have some use cases, but 
lack basic principles that can be applied to any case to determine if it 
should be a communication session or not. It still seems to be more in 
the realm of "I know one when I see it."

If we had the principles, then it would probably be straightforward to 
come up with words.

I don't yet see a suitable general principle here that fits the use 
cases and seems to make sense.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 24 Feb 2013 00:33:58 -0500

Paul,

So what concept is vague?

In terms of an H.323 device, I would consider two terminals with users at each end to be a communication session. I would consider a terminal and an MCU to have a communication session.

The collection of communication sessions on an MCU to which one or more terrminals are a party is a conference. And I would like to relate all those sessions by the UUID the MCU uses in each of those sessions. That value could even be the Conference ID in H.323.

There are gateway devices that connect to the PSTN that I would count as equal to a terminal. But, there are gateway devices that bridge IP networks (SBCs) that should just pass the UUIDs through. The difference between the two really is whether it bridges an IPMC device to another or to something else.

There are call flows like the one you highlighted in the threads where voice comes from one terminal and video from another. That's an MCU, really. The session ID exists between Alice and MCU (or PBX). The other devices Bob uses might share the UUID of the MCU/PBX, but those are distinct communication sessions like the typical MCU case. Yeah, such topologies do make it hard to do debugging and the number of UUIDs makes it a pain, too, but at least there is consistency in the assignments. So, it is doable.

So, how can we make progress here?

Paul

-------- Original Message --------
From: Paul Kyzivat <[email-masked]>
Sent: Sat Feb 23 19:58:41 EST 2013
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Insipid] Are we ready to LC on the requirements?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 24 Feb 2013 01:43:57 -0500

On 2/24/13 12:33 AM, Paul E. Jones wrote:
> In terms of an H.323 device, I would consider two terminals with users
> at each end to be a communication session. I would consider a terminal
> and an MCU to have a communication session.
>
> The collection of communication sessions on an MCU to which one or more
> terrminals are a party is a conference. And I would like to relate all
> those sessions by the UUID the MCU uses in each of those sessions. That
> value could even be the Conference ID in H.323.
>
> There are gateway devices that connect to the PSTN that I would count as
> equal to a terminal. But, there are gateway devices that bridge IP
> networks (SBCs) that should just pass the UUIDs through. The difference
> between the two really is whether it bridges an IPMC device to another
> or to something else.
>
> There are call flows like the one you highlighted in the threads where
> voice comes from one terminal and video from another. That's an MCU,
> really. The session ID exists between Alice and MCU (or PBX). The other
> devices Bob uses might share the UUID of the MCU/PBX, but those are
> distinct communication sessions like the typical MCU case. Yeah, such
> topologies do make it hard to do debugging and the number of UUIDs makes
> it a pain, too, but at least there is consistency in the assignments.
> So, it is doable.
>

We write some rules that any device that terminates more than one dialog 
can use to decide when one dialog should share a session-id with another 
dialog. The rules should get the "right" answer for all the use cases, 
and should be specific enough so that when applied to any device, no 
matter how weird, most reasonable people would agree with the answer. 
That way we can have a way of judging conformance to this specification.

I realize this bridges the gap between what the requirements are 
responsible for and what the mechanism is responsible for. But the 
mechanism is about marking communications sessions, not defining them.

OR I suppose the requirements could kick the can down the road, simply 
say that the mechanism must work for the specified use cases and itself 
must specify the algorithm for making the decision in other cases. But 
that just puts it off.

	Thanks,
	Paul K

> Paul
>
>
>
> ------------------------------------------------------------------------
> *From:* Paul Kyzivat <[email-masked]>
> *Sent:* Sat Feb 23 19:58:41 EST 2013
> *To:* "Paul E. Jones" <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Insipid] Are we ready to LC on the requirements?
>
> !
>   what
> should be covered from what should not. We have some use cases, but
>         existenc! e of middle boxes, there may be multiple related SIP
>         IMO this is a big improvement. But it still isn't as prec! ise
>         as I would
>         participants would! seem to qualify according to all of the
>         o! IIRC Hadriel suggested (in a meeting?) that where media
>         explicitly care about it should deliver the an! swer we expect.
>
>         normal
>         It needs
>         but there must be constraints ! on what it can do. There must
>         also be some
>         session
>                 consistently through! out the document. Prior to any
>                 consensus on
>                     I just posted the -04 version with changes proposed
>                     on the list over
>                     the
>
>                 past month or so.
>
>                     Paul
>
>                     ------------------------------------------------------------------------
>
>                     insipid mailing list
>                     [email-masked]
>                 ------------------------------------------------------------------------
>
>                 insipid mailing list
>                 [email-masked]
>             ------------------------------------------------------------------------
>
>             insipid mailing list
>             [email-masked]
>         ------------------------------------------------------------------------
>
>         insipid mailing list
>         [email-masked]
> ------------------------------------------------------------------------
>
> insipid mailing list
> [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 24 Feb 2013 09:38:32 -0500

Paul,

That still begs the question of "what language do we need to add or change to make this clear?" In my mind, I know exactly what an endpoint needs to do and what an SBC needs to do. But, I'll not say it does not need more charity for those that do not have it clear in their minds.

But, perhaps being too close to the work, I'm having trouble seeing where it is vague. Can you suggest text?

Paul

-------- Original Message --------
From: Paul Kyzivat <[email-masked]>
Sent: Sun Feb 24 01:43:57 EST 2013
To: "Paul E. Jones" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Insipid] Are we ready to LC on the requirements?

	Thanks,
	Paul K