Subject: [Insipid] A definition of "session" for the purposes of Insipid

From: Robert Sparks <[email-masked]>
Date: Wed, 03 Apr 2013 16:22:00 -0500

To make some progress on the discussion around defining what we are 
trying to identify, I propose adding the following to the requirements 
document as a section before "Terminology" and modifying the rest of the 
document text to be consistent with what's said here.

------

3. What does the Session-ID Identify?

The identifier this document places requirements on identifies a set of 
signaling messages associated with exactly two endpoints that, from each 
endpoint's perspective, are related to a single invocation of a 
communication application.

How the endpoints determine which signaling messages share a given 
identifier (that is, what constitutes a single invocation of a 
communication application) is intentionally left loosely defined.

The term "call" is often used as an example of such an invocation for 
voice and video communication, but different protocols and deployments 
define the scope of a "call" in different ways. For instance, some 
systems would associate all of the activity between all three parties 
involved in a transfer a single "call".

Similarly, the term "session" is often used as an example of such an 
invocation, but this term is overloaded to describe both signaling and 
media level interaction.  A single invocation of the communication 
application, as described above, may involve multiple RTP "sessions" as 
described by RFC3550, possibly even multiple concurrent sessions.

In this document, unless otherwise qualified, the term "session" will 
refer only to the set of of signaling messages identified by the common 
Session-ID identifier. That is, a "session" is a set of signaling 
messages associated with exactly two endpoints that, from each 
endpoint's perspective, are related to a single invocation of a 
communication application.

The requirements in this document put some constraint on what an 
endpoint will consider the same, or a different, invocation of a 
communication session. They also ensure that related sessions (as this 
document is using the term) can be correlated using only the session 
identifiers for each session. Again, what constitutes a "related" 
session is intentionally left loosely defined.

The definition speaks of messages associated with exactly two endpoints 
instead of messages sent between two endpoints to allow for 
intermediaries that create messages on an endpoints behalf. It is 
possible that an endpoint may not see all of the messages in a session 
(as this document is using the term) associated with it.

This definition, and the requirements in this document that put some 
constraint on what an endpoint should consider the same, or a different, 
invocation of a communication session facilitates specifying an 
identifier that allows the two endpoints to be using two entirely 
different protocols (hence potentially have different ideas of what a 
single invocation means) or be using two applications that have a 
different idea of what a single invocation means.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 9 Apr 2013 18:50:12 -0400

Robert,

This sounds good.  Now, given this, is there text in the "new" section 4 you
think needs to change?

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Robert Sparks
Sent: Wednesday, April 03, 2013 5:22 PM
To: [email-masked]
Subject: [Insipid] A definition of "session" for the purposes of Insipid

To make some progress on the discussion around defining what we are trying
to identify, I propose adding the following to the requirements document as
a section before "Terminology" and modifying the rest of the document text
to be consistent with what's said here. 

------ 

How the endpoints determine which signaling messages share a given
identifier (that is, what constitutes a single invocation of a communication
application) is intentionally left loosely defined. 

The term "call" is often used as an example of such an invocation for voice
and video communication, but different protocols and deployments define the
scope of a "call" in different ways. For instance, some systems would
associate all of the activity between all three parties involved in a
transfer a single "call". 

Similarly, the term "session" is often used as an example of such an
invocation, but this term is overloaded to describe both signaling and media
level interaction.  A single invocation of the communication application, as
described above, may involve multiple RTP "sessions" as described by
RFC3550, possibly even multiple concurrent sessions. 

In this document, unless otherwise qualified, the term "session" will refer
only to the set of of signaling messages identified by the common Session-ID
identifier. That is, a "session" is a set of signaling messages associated
with exactly two endpoints that, from each endpoint's perspective, are
related to a single invocation of a communication application. 

The requirements in this document put some constraint on what an endpoint
will consider the same, or a different, invocation of a communication
session. They also ensure that related sessions (as this document is using
the term) can be correlated using only the session identifiers for each
session. Again, what constitutes a "related" session is intentionally left
loosely defined. 

The definition speaks of messages associated with exactly two endpoints
instead of messages sent between two endpoints to allow for intermediaries
that create messages on an endpoints behalf. It is possible that an endpoint
may not see all of the messages in a session (as this document is using the
term) associated with it. 

This definition, and the requirements in this document that put some
constraint on what an endpoint should consider the same, or a different,
invocation of a communication session facilitates specifying an identifier
that allows the two endpoints to be using two entirely different protocols
(hence potentially have different ideas of what a single invocation means)
or be using two applications that have a different idea of what a single
invocation means.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 09 Apr 2013 19:03:58 -0500

On 4/9/13 5:50 PM, Paul E. Jones wrote:
>
> Robert,
>
> This sounds good.  Now, given this, is there text in the "new" section 
> 4 you think needs to change?
>
Definitely - the section can be simplified, and there are places that 
need to be adjusted to use this definition instead of try to define it 
itself by example. I hope you can see those spots.
>
> Paul
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Robert Sparks
> *Sent:* Wednesday, April 03, 2013 5:22 PM
> *To:* [email-masked]
> *Subject:* [Insipid] A definition of "session" for the purposes of Insipid
>
> document as a section before "Terminology" and modifying the rest of 
> the document text to be consistent with what's said here.
>
> ------
>
> The identifier this document places requirements on identifies a set 
> of signaling messages associated with exactly two endpoints that, from 
> each endpoint's perspective, are related to a single invocation of a 
> application, as described above, may involve multiple RTP "sessions" 
> as described by RFC3550, possibly even multiple concurrent sessions.
>
> refer only to the set of of signaling messages identified by the 
> common Session-ID identifier. That is, a "session" is a set of 
> signaling messages associated with exactly two endpoints that, from 
> each endpoint's perspective, are related to a single invocation of a 
> The definition speaks of messages associated with exactly two 
> endpoints instead of messages sent between two endpoints to allow for 
> constraint on what an endpoint should consider the same, or a 
> different, invocation of a communication session facilitates 
> specifying an identifier that allows the two endpoints to be using two 
> entirely different protocols (hence potentially have different ideas 
> of what a single invocation means) or be using two applications that 
> have a different idea of what a single invocation means.
>