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

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 9 Jan 2013 21:23:55 -0500

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

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 10 Jan 2013 15:38:31 -0500

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 10 Jan 2013 23:04:22 +0000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2013 15:34:10 -0500

(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. But it still isn't as precise as I would 
like. 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.

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.

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

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

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

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

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.

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

    (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.

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