Subject: Re: [dispatch] new charter version for Session-id

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Nov 2011 12:41:58 -0600

At least one major thread in the conversation in quebec isn't included in the proposed changes below.
As you consider the other feedback you're receiving, please go back and look at (or better, listen to)
the discussion around whether "aims to identify a Dialog" is really what you are trying to do. Given
the answers to some of the questions in the earlier discussion, it's not a dialog (at least it's not the thing
that has a dialog identifier). Perhaps you could try different text at "aims to identify a <?>".

Consider in particular the case of a call I have with a B2BUA that starts off relaying my media to one endpoint,
and then (for whatever reason) shifts it to another. I heard folks say they want that whole conversation to have 
one session identifier, but there were 3 different dialogs there.

RjS

On Oct 7, 2011, at 7:50 AM, Salvatore Loreto wrote:

> Hi,
> 
> in Quebec we got a strong consensus on moving the Session-ID work forward,
> but in order to do so we have been asked
> to work on improving the charter so to make more clear and focused the aim of the mini-working group.
> 
> Together with all the proponents of the initial charter [1] we have worked on it
> and we hope it now satisfy all the concerns we listened as well as all the questions/feedback we got
> during the Quebec presentation.
> (the charter is below)
> 
> comments and feedback are really welcome
> 
> cheers
> /Sal
> -- 
> Salvatore Loreto
> www.sloreto.com
> [1] http://www.ietf.org/mail-archive/web/dispatch/current/msg03647.html
> 
> 
> 
> End-to-end Session Identifier in SIP (NEW charter proposal)
> The end-to-end Session Identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediary devices, management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices and hops.
> 
> Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification.  Perhaps the most important factor worth describing is that in real-world deployments devices like Back-to-Back User Agents (B2BUAs) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through.
> 
> An end-to-end Session Identifier aims to identify a Dialog (as defined in RFC 3261 Section 5), but does so in such a way as to overcome the limitations of the present means of Dialog identification.  The Session Identifier allows for the possibility of uniquely identifying the communication session from the originating endpoint, passing through any number of intermediaries, to the terminating endpoint.  The Session Identifier will address issues related to transferring or forwarding of sessions, as well as changes during mid-call of either of the endpoints by an intermediary (e.g., “joining” two calls at a B2BUA).
> 
> As for Dialogs, an end-to-end Session Identifier should be “created through the generation of non-failure responses to requests with specific methods” (RFC 3261 Section 12.1).  That said, the end-to-end Session Identifier may change if an endpoint receives an INVITE or other request indicating through some means that the remote endpoint has changed.  This may occur, for example, when a B2BUA performs a call “join” or otherwise re-routes one end of the communication session.  Taking note of such changes is important to ensure a new end-to-end Session Identifier can be constructed.
> 
> Further, the Session Identifier must be constructed so that it may be used by other session control protocols, such as H.323 or XMPP, to improve interworking between protocols.  The ITU-T has identified a need for an end-to-end session Identifier and is progressing work to be aligned with the output of this Working Group.
> 
> The end-to-end Session Identifier has been considered as possible solution to different use cases like media and signaling correlation, session tracking, troubleshooting, billing, session recording, and so forth. Some of these requirements have also been identified and come directly from other existing working group within the RAI area (e.g., SIPRec and Splices).  The requirements document shall deliver the possible scenarios where the Session Identifier would be used.
> 
> This group will first focus on a document that will identify, collect and discuss all the requirements and use cases. Once the needs are clear and identified, the working group will specify the end-to-end Session Identifier mechanism.
> 
> The working group will produce the following deliverables:
> 
> 1. A requirement and use case document with key consideration for SIP Session End-to-End Identification
> 
> 2. Specification of new end-to-end Session Identifier mechanism
> 
> Goal and Milestone:
> 
> March 2012 - Requirement and use case document sent to the IESG (Information)
> 
> November 2012 – Specification of the new mechanism sent to the IESG
> 
>   
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 8 Nov 2011 14:17:59 -0500

Robert,

What I would expect is that we identifier the session end-to-end from one
endpoint to another endpoint.  If that passes through one or more B2BUAs,
that would still be a single communication session for the purposes of this
work.

We need to get that wording right, but I assume there agreement on
identifying the communication session end-to-end across zero or more B2BUAs.
Do folks agree?

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Robert Sparks
Sent: Tuesday, November 08, 2011 1:42 PM
To: Salvatore Loreto
Cc: [email-masked]
Subject: Re: [dispatch] new charter version for Session-id

At least one major thread in the conversation in quebec isn't included in
the proposed changes below.

As you consider the other feedback you're receiving, please go back and look
at (or better, listen to)

the discussion around whether "aims to identify a Dialog" is really what you
are trying to do. Given

the answers to some of the questions in the earlier discussion, it's not a
dialog (at least it's not the thing

that has a dialog identifier). Perhaps you could try different text at "aims
to identify a <?>".

Consider in particular the case of a call I have with a B2BUA that starts
off relaying my media to one endpoint,

and then (for whatever reason) shifts it to another. I heard folks say they
want that whole conversation to have 

RjS

Hi,

in Quebec we got a strong consensus on moving the Session-ID work forward,
but in order to do so we have been asked
to work on improving the charter so to make more clear and focused the aim
of the mini-working group.

Together with all the proponents of the initial charter [1] we have worked
on it
and we hope it now satisfy all the concerns we listened as well as all the
questions/feedback we got
during the Quebec presentation.
(the charter is below)

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com <http://www.sloreto.com/> 

The end-to-end Session Identifier in SIP-based multimedia communication
networks refers to the ability for endpoints, intermediary devices,
management and monitoring system to identify and correlate SIP messages and
dialogs of the same higher-level end-to-end "communication session" across
multiple SIP devices and hops. 

Unfortunately, there are a number of factors that contribute to the fact
that the current dialog identifiers defined in SIP are not suitable for
end-to-end session identification.  Perhaps the most important factor worth
describing is that in real-world deployments devices like Back-to-Back User
Agents (B2BUAs) often change the call identifiers (e.g., the From-tag and
To-tag that are used in conjunction with the Call-ID header to make the
dialog-id) as the session signaling passes through.

An end-to-end Session Identifier aims to identify a Dialog (as defined in
RFC 3261 Section 5), but does so in such a way as to overcome the
limitations of the present means of Dialog identification.  The Session
Identifier allows for the possibility of uniquely identifying the
communication session from the originating endpoint, passing through any
number of intermediaries, to the terminating endpoint.  The Session
Identifier will address issues related to transferring or forwarding of
sessions, as well as changes during mid-call of either of the endpoints by
an intermediary (e.g., "joining" two calls at a B2BUA).

As for Dialogs, an end-to-end Session Identifier should be "created through
the generation of non-failure responses to requests with specific methods"
(RFC 3261 Section 12.1).  That said, the end-to-end Session Identifier may
change if an endpoint receives an INVITE or other request indicating through
some means that the remote endpoint has changed.  This may occur, for
example, when a B2BUA performs a call "join" or otherwise re-routes one end
of the communication session.  Taking note of such changes is important to
ensure a new end-to-end Session Identifier can be constructed.

Further, the Session Identifier must be constructed so that it may be used
by other session control protocols, such as H.323 or XMPP, to improve
interworking between protocols.  The ITU-T has identified a need for an
end-to-end session Identifier and is progressing work to be aligned with the
output of this Working Group.

The end-to-end Session Identifier has been considered as possible solution
to different use cases like media and signaling correlation, session
tracking, troubleshooting, billing, session recording, and so forth. Some of
these requirements have also been identified and come directly from other
existing working group within the RAI area (e.g., SIPRec and Splices).  The
requirements document shall deliver the possible scenarios where the Session
Identifier would be used.

This group will first focus on a document that will identify, collect and
discuss all the requirements and use cases. Once the needs are clear and
identified, the working group will specify the end-to-end Session Identifier
mechanism.

1. A requirement and use case document with key consideration for SIP
Session End-to-End Identification 

Goal and Milestone:

March 2012 - Requirement and use case document sent to the IESG
(Information)

November 2012 - Specification of the new mechanism sent to the IESG

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Nov 2011 12:44:43 -0700

On Nov 8, 2011, at 12:17 PM, Paul E. Jones wrote:

>  
> We need to get that wording right, but I assume there agreement on identifying the communication session end-to-end across zero or more B2BUAs. Do folks agree?

The point people have tried to make is it depends on the type of B2BUA and what it is trying to do. In a typically SBC like case where there is exactly one dialog on the left side corresponding to exactly one dialog on the right side, then yes, I suspect lots of people agree. In the case of a conference bridge with multiple dialog then no, I think most people think that they don't want it the same. In some other cases, it's complicated. But overall, I doubt people agree with a blanket statement like that towards B2BUA.

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 8 Nov 2011 15:08:22 -0500

Cullen,

In the case where we have multiple calls in a conference as you describe,
this is not a B2BUA: it's an endpoint (an MCU, in particular).  So in this
case, the session originate at an endpoint and terminate on the
MCU/endpoint.  In a conference, each endpoint connected to a conference will
have a unique Session-ID.  The Session-ID is not a conference ID.  (That
said, we might be able to identify all participants in the same conference
if we do something along the line of what we described in our draft, since
we propose using a UUID at the MCU that would be the same for each
participant in the same conference.  We need some discussion on that, but if
it proved unworkable it should not derail the work on a Session-ID.)

Paul

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, November 08, 2011 2:45 PM
> To: Paul E. Jones
> Cc: 'Robert Sparks'; 'Salvatore Loreto'; [email-masked]
> identifying the communication session end-to-end across zero or more
> B2BUAs. Do folks agree?
> 
> The point people have tried to make is it depends on the type of B2BUA
> and what it is trying to do. In a typically SBC like case where there is
> exactly one dialog on the left side corresponding to exactly one dialog
> on the right side, then yes, I suspect lots of people agree. In the case
> of a conference bridge with multiple dialog then no, I think most people
> think that they don't want it the same. In some other cases, it's
> complicated. But overall, I doubt people agree with a blanket statement
> like that towards B2BUA.
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Nov 2011 15:26:22 -0500

On 11/8/11 3:08 PM, Paul E. Jones wrote:
> this is not a B2BUA: it's an endpoint (an MCU, in particular).

This is part of the difficulty in having this discussion.
"Endpoint" has no formal definition in 3261. And IMO a conference focus 
*is* a B2BUA. (I find it to fully agree with the definition of B2BUA in 
3261.) Its just a different kind of B2BUA than you have in mind.

How do you feel about a 3PCC controller? Is it a B2BUA? If it does a 
transfer then it goes through stages when it has two dialogs, then 
three, then two. From past discussions, I think you expect there will be 
more than one session-id covering that.

> So in this

To achieve this you will have to define what you mean by "endpoint", and 
how to decide when something is an endpoint and not a B2BUA.

	Thanks,
	Paul

---

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Nov 2011 15:24:12 -0600

On Nov 8, 2011, at 1:17 PM, Paul E. Jones wrote:

> Robert,
>  
> What I would expect is that we identifier the session end-to-end from one endpoint to another endpoint.  If that passes through one or more B2BUAs, that would still be a single communication session for the purposes of this work.
>  

I can't agree because I can't tell yet what you mean by "the communication session". That's what I'm asking you to clarify. Your response indicates you are still focusing only on a model
where  one-dialog-into a B2BUA results in exactly one-dialog-out-of that B2BUA.

The scenario I call out below does not fit in that model. Do you think there's one session identifier or two? 
If it's one, then it's not an identifier from one endpoint to another endpoint, its an identifier from one endpoint to one-or-more other endpoints.

>  
> Paul
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Sparks

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 8 Nov 2011 20:43:02 -0500

Robert,

A Session-ID is intended to be unique between any two communicating
endpoints.  So, if Alice makes a call and connects to Bob, there would be a
Session-ID that is end-to-end unique between Alice and Bob.  If an
intermediary re-routes the call such that Alice is now in communication with
Sue, then there would be a new unique Session-ID between Alice and Sue.
Likewise, if Alice calls Bob, but there is a forking proxy that causes the
call to be forked to 15 "Bobs", then there would be 15 Session-IDs, one for
each pair of { Alice, Bob(i) }.  The Session-ID is unique between any two
communicating endpoints.  An endpoint includes "terminal" devices, "MCU"
devices, etc.  It would not include SBCs, as those are intermediary devices,
not terminating devices.

I agree that wording this is a challenge, and I'm definitely open to input
on appropriate wording.

Paul

From: Robert Sparks [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2011 4:24 PM
To: Paul E. Jones
Cc: 'Salvatore Loreto'; [email-masked]
Subject: Re: [dispatch] new charter version for Session-id

Robert,

I can't agree because I can't tell yet what you mean by "the communication
session". That's what I'm asking you to clarify. Your response indicates you
are still focusing only on a model

where  one-dialog-into a B2BUA results in exactly one-dialog-out-of that
B2BUA.

The scenario I call out below does not fit in that model. Do you think
there's one session identifier or two? 

If it's one, then it's not an identifier from one endpoint to another
endpoint, its an identifier from one endpoint to one-or-more other
endpoints.

Paul

RjS

Hi,

cheers
/Sal

Goal and Milestone:

---

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Nov 2011 19:55:25 -0600

So, if I call Frobgnobitz  and get connected to their b2bua, which sets up a dialog to a media server to play me
a message while I'm in the queue to talk to an agent, and then when an agent comes available, that B2BUA
sets up a second dialog and replumbs itself internally so I'm getting media from the agent instead of from the
media server (as far as my endpoint is concerned, it's only ever been in one dialog),  you're saying I have 
two session IDs.

I have heard others say it's only one.

RjS

On Nov 8, 2011, at 7:43 PM, Paul E. Jones wrote:

> Robert,
>  
> A Session-ID is intended to be unique between any two communicating endpoints.  So, if Alice makes a call and connects to Bob, there would be a Session-ID that is end-to-end unique between Alice and Bob.  If an intermediary re-routes the call such that Alice is now in communication with Sue, then there would be a new unique Session-ID between Alice and Sue.  Likewise, if Alice calls Bob, but there is a forking proxy that causes the call to be forked to 15 “Bobs”, then there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) }.  The Session-ID is unique between any two communicating endpoints.  An endpoint includes “terminal” devices, “MCU” devices, etc.  It would not include SBCs, as those are intermediary devices, not terminating devices.
>  
> I agree that wording this is a challenge, and I’m definitely open to input on appropriate wording.
>  
> Paul
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 8 Nov 2011 20:56:08 -0500

Paul,

> > In the case where we have multiple calls in a conference as you
> > describe, this is not a B2BUA: it's an endpoint (an MCU, in
> particular).
> 

I understand.  Lacking those definitions makes it difficult, though I'm
surprised people would agree that an MCU is a B2BUA.  I'm scratching my head
over this one.
 
> more than one session-id covering that.

A PBX-type device would be a B2BUA in my mind and, yes, there would be
different Session-IDs since there would be different devices end-to-end.  In
this case, the B2BUA truly is just an intermediary device, not a terminating
device.  MCUs, on the other hand, are terminating devices.  Yes, they might
switch media vs. terminate, decode, re-encode, etc., but it is nonetheless
an endpoint device.
 
> > MCU/endpoint.  In a conference, each endpoint connected to a
> > conference will have a unique Session-ID.  The Session-ID is not a
> > conference ID.  (That said, we might be able to identify all
> > participants in the same conference if we do something along the line
> > of what we described in our draft, since we propose using a UUID at
> > the MCU that would be the same for each participant in the same
> > conference.  We need some discussion on that, but if it proved
> > unworkable it should not derail the work on a Session-ID.)
> 

Help me out here :-)  We do not need to invent new device types, but perhaps
you can articulate a definition that is a subset of a user agent that
properly represents an endpoint.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 8 Nov 2011 21:03:15 -0500

Robert,

I would say it is two session IDs, because the end device changed: there was
a media server and then there was an agent.  If there is some device (and it
does not matter if it is the B2BUA or media server in this case) that
originates an offer or an answer, then it is terminating the call
(effectively).  When re-routed, there is another device that originates an
offer or answer.

It would be nice if the Session-ID never changed, but reality is that it has
to.  Any kind of forking or service interaction by intermediaries (like this
one you described) means that session changed end-to-end, thus we need a new
end-to-end Session-ID.  What I would hope we can do is note such transitions
(e.g., Alice would continue to use the same Session-UUID in the document we
submitted) for logging purposes, debugging, tracing, etc.  However, what is
most important is that we can identify a session end-to-end at any given
point in time, even if that time is relatively short.

Paul

From: Robert Sparks [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2011 8:55 PM
To: Paul E. Jones
Cc: 'Salvatore Loreto'; [email-masked]
Subject: Re: [dispatch] new charter version for Session-id

So, if I call Frobgnobitz  and get connected to their b2bua, which sets up a
dialog to a media server to play me

a message while I'm in the queue to talk to an agent, and then when an agent
comes available, that B2BUA

sets up a second dialog and replumbs itself internally so I'm getting media
from the agent instead of from the

media server (as far as my endpoint is concerned, it's only ever been in one
dialog),  you're saying I have 

two session IDs.

RjS

Robert,

Paul

 

Robert,

 

Paul

RjS

Hi,

cheers
/Sal

Goal and Milestone:

---

From: Adam Roach <[email-masked]>
Date: Tue, 08 Nov 2011 20:58:48 -0600

> switch media vs. terminate, decode, re-encode, etc., but it is nonetheless

It's not that cut and dried.

Let's imagine that I place a call, through our office PBX, to you. It's 
acting like a B2BUA in this context, and is proxying the media.

I think you believe that this would be one session.

Now, halfway through our conversation, Robert sends an INVITE/Join 
(RFC3911) to the PBX to add himself to the conversation. It becomes a 
three-way conversation, with the PBX mixing media and sending it to all 
three of us.

According to what you've said before, a three way conference constitutes 
three sessions, one between each endpoint and the mixer. How would you 
imagine this working? Does the session ID that represents the session 
between us get terminated, and we each get brand new session IDs that 
represent our session to the PBX? Or does the session ID between us 
remain, but Robert gets a new one? Or do we propagate the existing 
session ID to include Robert's part of the call?

Then, when Robert hangs up and we continue talking, what happens? It's 
now a two party call with a B2BUA in the middle. Do we go back to using 
the session ID that we had in the first place? Do we create a new one? 
Or do we keep using the two session IDs that represent our respective 
sessions with the PBX?

How about if *I* hang up and you continue to talk to Robert? What 
identifiers apply then?

The problem is that you're using terms as if a SIP node can do one, and 
exactly one, thing. And that it can never transition roles. And that 
those roles are very tightly constricted. Unfortunately, the reality of 
actually deployed systems is nowhere near that regimented.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 9 Nov 2011 11:19:31 +0100

I would note that if you call it a session identifier, that is presumably a unique identifier of something called a "session", which is currently defined in RFC 3261 as:

      Session: From the SDP specification: "A multimedia session is a
         set of multimedia senders and receivers and the data streams
         flowing from senders to receivers.  A multimedia conference is
         an example of a multimedia session." (RFC 2327 [1]) (A session
         as defined for SDP can comprise one or more RTP sessions.)  As
         defined, a callee can be invited several times, by different
         calls, to the same session.  If SDP is used, a session is
         defined by the concatenation of the SDP user name, session id,
         network type, address type, and address elements in the origin
         field.

That looks to be something different to the way this thread is going.

Regards

Keith

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: 09 November 2011 02:03
To: 'Robert Sparks'
Cc: [email-masked]
Subject: Re: [dispatch] new charter version for Session-id

Robert,

I would say it is two session IDs, because the end device changed: there was a media server and then there was an agent.  If there is some device (and it does not matter if it is the B2BUA or media server in this case) that originates an offer or an answer, then it is terminating the call (effectively).  When re-routed, there is another device that originates an offer or answer.

It would be nice if the Session-ID never changed, but reality is that it has to.  Any kind of forking or service interaction by intermediaries (like this one you described) means that session changed end-to-end, thus we need a new end-to-end Session-ID.  What I would hope we can do is note such transitions (e.g., Alice would continue to use the same Session-UUID in the document we submitted) for logging purposes, debugging, tracing, etc.  However, what is most important is that we can identify a session end-to-end at any given point in time, even if that time is relatively short.

Paul

RjS

Robert,
 
A Session-ID is intended to be unique between any two communicating endpoints.  So, if Alice makes a call and connects to Bob, there would be a Session-ID that is end-to-end unique between Alice and Bob.  If an intermediary re-routes the call such that Alice is now in communication with Sue, then there would be a new unique Session-ID between Alice and Sue.  Likewise, if Alice calls Bob, but there is a forking proxy that causes the call to be forked to 15 "Bobs", then there would be 15 Session-IDs, one for each pair of { Alice, Bob(i) }.  The Session-ID is unique between any two communicating endpoints.  An endpoint includes "terminal" devices, "MCU" devices, etc.  It would not include SBCs, as those are intermediary devices, not terminating devices.
 
I agree that wording this is a challenge, and I'm definitely open to input on appropriate wording.
 
Paul

Robert,

 

 
Paul

 
 
RjS

Hi,

cheers
/Sal

An end-to-end Session Identifier aims to identify a Dialog (as defined in RFC 3261 Section 5), but does so in such a way as to overcome the limitations of the present means of Dialog identification.  The Session Identifier allows for the possibility of uniquely identifying the communication session from the originating endpoint, passing through any number of intermediaries, to the terminating endpoint.  The Session Identifier will address issues related to transferring or forwarding of sessions, as well as changes during mid-call of either of the endpoints by an intermediary (e.g., "joining" two calls at a B2BUA).
As for Dialogs, an end-to-end Session Identifier should be "created through the generation of non-failure responses to requests with specific methods" (RFC 3261 Section 12.1).  That said, the end-to-end Session Identifier may change if an endpoint receives an INVITE or other request indicating through some means that the remote endpoint has changed.  This may occur, for example, when a B2BUA performs a call "join" or otherwise re-routes one end of the communication session.  Taking note of such changes is important to ensure a new end-to-end Session Identifier can be constructed.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 9 Nov 2011 08:30:06 -0500

Adam,

> I think you believe that this would be one session.

Yes, that would be one session, with the B2BUA acting as an intermediary.
 
> three-way conversation, with the PBX mixing media and sending it to all

At this point, it would appear the PBX changed roles from acting as an
intermediary to acting as an MCU, since it is doing the mixing.  I assume
the PBX also responded to the JOIN.  I assume this might also mean that the
PBX/MCU sends a re-INVITE to the original  two endpoints.
 
> session ID to include Robert's part of the call?

Assuming the PBX is acting as an MCU, I would expect that the original
Session-ID would go away.  The PBX would send a Re-INVITE to each of the
original two participants and assign part or all of the Session-ID.
Following the draft we wrote, it would send a Session-UUID header that
replaces the previous value.  So, we would have the following three
Session-IDs in the conference (where each component below is a Session-UUID
value):
  [ Adam   || MCU ]
  [ Paul   || MCU ]
  [ Robert || MCU ]

Note that we're proposing that the MCU/PBX use the same Session-UUID value
for each participant in a conference.  The concatenated strings are all
globally unique, but the "MCU" UUID would be the same and allow one to
relate sessions.  (Note the order of concatenation is prescribed, but
certainly subject to discussion.)

> Or do we keep using the two session IDs that represent our respective

I assume that the MCU/PBX transitions back to just being an intermediary
device, taking itself out of the loop as a media mixer or processor and just
acting like an SBC.  In that case, I would assume the PBX would forward the
Session-UUID for the opposite party in the call as it had originally done.
So, we would have a single end-to-end Session-ID value that actually matched
the original value:
  [ Adam || Paul ]

If the PBX/MCU still remained in the role of MCU ("focus"), then we might
have two Session-IDs:
  [ Adam || MCU ]
  [ Paul || MCU ]

It really depends on the behavior of the PBX/MCU.  If it acts like an MCU
(an endpoint), then we would have two Session-IDs, because the remote
endpoint is, in fact, the MCU.

> How about if *I* hang up and you continue to talk to Robert? What

Assuming the PBX/MCU transitions its role from MCU to serving as an
intermediary B2BUA, then it would send an INVITE to both of us and we would
have a single Session-ID of the form:
  [ Paul || Robert ]

Again, if the PBX/MCU remained in the role of MCU where it acts as an
endpoint, then we might have two Session-IDs:
  [ Paul   || MCU ]
  [ Robert || MCU ]

> actually deployed systems is nowhere near that regimented.

I fully appreciate that roles can and do change.  This is the reason, in
fact, that we abandoned the idea of defining a Session-ID that is assigned
by Alice in the original INVITE and would persist throughout a call.  There
are simply too many possible service interactions like this one you
discussed.  You're entirely right that the system must be flexible to
accommodate those transitions.  As the communication sessions transition,
the end-to-end identifier must change.  We do lose the original Session-ID
sometimes, but what I think is important is that at any given point in time
where we have a steady state, it is possible to identify a call end-to-end.
By using UUIDs at each endpoint, though, we at least have a means of
correlating information.

Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 09 Nov 2011 07:40:06 -0600

> PBX/MCU sends a re-INVITE to the original  two endpoints.

In my experience, devices acting in the PBX role in this scenario do not 
do this; the two existing endpoints are not made aware of the third 
party joining the call (although presumably the users of those endpoints 
become aware of it <G>). While they certainly *could* issue a re-INVITE 
in this situation in order to construct/communicate a new Session-ID, 
this would be new behavior required to support Session-ID usage, and is 
potentially significantly more complicated to implement than just 
communicating some header values between sessions.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 9 Nov 2011 13:42:58 +0000

Kevin,

Could you please clarify whether UPDATE or any other method in your mind to communicate in case RE-INVITE is complicated.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Kevin P. Fleming
>Sent: Wednesday, November 09, 2011 7:10 PM
>To: [email-masked]

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 09 Nov 2011 08:04:40 -0600

> Could you please clarify whether UPDATE or any other method in your mind to communicate in case RE-INVITE is complicated.

It isn't the choice of SIP request method that is the issue; it's that 
the PBX would need to implement logic to notify endpoints in an existing 
call that a party has joined or left the call. In the case of Asterisk, 
for example, if we were to plan to support this Session-ID mechanism as 
proposed, our MeetMe/ConfBridge applications would have to start to 
provide indications to call connected parties (over signaling, not just 
in the audio path) when this sort of change in the structure of the call 
occurs. It's certainly possible (it's just software, after all), but 
it's significantly more work than just carrying a Session-UUID value 
from an incoming session to an outgoing session.

>> become aware of it<G>). While they certainly *could* issue a re-INVITE
>> Check us out at www.digium.com&  www.asterisk.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 9 Nov 2011 09:06:03 -0500

Keith,

The term "session" is a bit overloaded (SIP session, RTP session, SDP
session, RSVP session).  In my opinion, the "session" should closely track
the collection of RTP sessions that comprise and SIP session.

I'm not opposed to any name for the end-to-end session ID work, but use of a
different term may not remove the confusion.  It's especially appropriate
since we're referring to the "Session Initiation Protocol".  Whatever it is
we're initiating, we'd like to identify. ;-)

Paul

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Wednesday, November 09, 2011 5:20 AM
> To: Paul E. Jones; 'Robert Sparks'
> Cc: [email-masked]
> Subject: RE: [dispatch] new charter version for Session-id
> 
> I would note that if you call it a session identifier, that is
> presumably a unique identifier of something called a "session", which is
> currently defined in RFC 3261 as:
> 
> Behalf Of Paul E. Jones
> I would say it is two session IDs, because the end device changed: there
> was a media server and then there was an agent.  If there is some device
> (and it does not matter if it is the B2BUA or media server in this case)
> that originates an offer or an answer, then it is terminating the call
> (effectively).  When re-routed, there is another device that originates
> an offer or answer.
> 
> It would be nice if the Session-ID never changed, but reality is that it
> has to.  Any kind of forking or service interaction by intermediaries
> (like this one you described) means that session changed end-to-end,
> thus we need a new end-to-end Session-ID.  What I would hope we can do
> is note such transitions (e.g., Alice would continue to use the same
> Session-UUID in the document we submitted) for logging purposes,
> debugging, tracing, etc.  However, what is most important is that we can
> identify a session end-to-end at any given point in time, even if that
> time is relatively short.
> 
> Paul
> 
> So, if I call Frobgnobitz  and get connected to their b2bua, which sets
> up a dialog to a media server to play me a message while I'm in the
> queue to talk to an agent, and then when an agent comes available, that
> B2BUA sets up a second dialog and replumbs itself internally so I'm
> getting media from the agent instead of from the media server (as far as
> my endpoint is concerned, it's only ever been in one dialog),  you're
> saying I have two session IDs.
> 
> endpoints.  So, if Alice makes a call and connects to Bob, there would
> be a Session-ID that is end-to-end unique between Alice and Bob.  If an
> intermediary re-routes the call such that Alice is now in communication
> with Sue, then there would be a new unique Session-ID between Alice and
> Sue.  Likewise, if Alice calls Bob, but there is a forking proxy that
> causes the call to be forked to 15 "Bobs", then there would be 15
> Session-IDs, one for each pair of { Alice, Bob(i) }.  The Session-ID is
> unique between any two communicating endpoints.  An endpoint includes
> "terminal" devices, "MCU" devices, etc.  It would not include SBCs, as
> those are intermediary devices, not terminating devices.
> 
> What I would expect is that we identifier the session end-to-end from
> one endpoint to another endpoint.  If that passes through one or more
> B2BUAs, that would still be a single communication session for the
> purposes of this work.
> 
> I can't agree because I can't tell yet what you mean by "the
> communication session". That's what I'm asking you to clarify. Your
> response indicates you are still focusing only on a model where  one-
> dialog-into a B2BUA results in exactly one-dialog-out-of that B2BUA.
> 
> there's one session identifier or two? If it's one, then it's not an
> identifier from one endpoint to another endpoint, its an identifier from
> one endpoint to one-or-more other endpoints.
> 
> 
> 
> Paul
> 
> Behalf Of Robert Sparks
> As you consider the other feedback you're receiving, please go back and
> look at (or better, listen to) the discussion around whether "aims to
> identify a Dialog" is really what you are trying to do. Given the
> answers to some of the questions in the earlier discussion, it's not a
> dialog (at least it's not the thing that has a dialog identifier).
> Perhaps you could try different text at "aims to identify a <?>".
> 
> Consider in particular the case of a call I have with a B2BUA that
> starts off relaying my media to one endpoint, and then (for whatever
> reason) shifts it to another. I heard folks say they want that whole
> conversation to have one session identifier, but there were 3 different
> dialogs there.
> 
> RjS
> 
> in Quebec we got a strong consensus on moving the Session-ID work
> forward, but in order to do so we have been asked to work on improving
> the charter so to make more clear and focused the aim of the mini-
> working group.
> 
> Together with all the proponents of the initial charter [1] we have
> worked on it and we hope it now satisfy all the concerns we listened as
> well as all the questions/feedback we got during the Quebec
> presentation.
> (the charter is below)
> 
> management and monitoring system to identify and correlate SIP messages
> and dialogs of the same higher-level end-to-end "communication session"
> across multiple SIP devices and hops.
> end-to-end session identification.  Perhaps the most important factor
> worth describing is that in real-world deployments devices like Back-to-
> Back User Agents (B2BUAs) often change the call identifiers (e.g., the
> From-tag and To-tag that are used in conjunction with the Call-ID header
> to make the dialog-id) as the session signaling passes through.
> An end-to-end Session Identifier aims to identify a Dialog (as defined
> in RFC 3261 Section 5), but does so in such a way as to overcome the
> sessions, as well as changes during mid-call of either of the endpoints
> by an intermediary (e.g., "joining" two calls at a B2BUA).
> As for Dialogs, an end-to-end Session Identifier should be "created
> through the generation of non-failure responses to requests with
> specific methods" (RFC 3261 Section 12.1).  That said, the end-to-end
> Session Identifier may change if an endpoint receives an INVITE or other
> request indicating through some means that the remote endpoint has
> changed.  This may occur, for example, when a B2BUA performs a call
> "join" or otherwise re-routes one end of the communication
> session.  Taking note of such changes is important to ensure a new end-
> to-end Session Identifier can be constructed.
> Further, the Session Identifier must be constructed so that it may be
> used by other session control protocols, such as H.323 or XMPP, to
> improve interworking between protocols.  The ITU-T has identified a need
> for an end-to-end session Identifier and is progressing work to be
> aligned with the output of this Working Group.
> The end-to-end Session Identifier has been considered as possible
> solution to different use cases like media and signaling correlation,
> session tracking, troubleshooting, billing, session recording, and so
> forth. Some of these requirements have also been identified and come
> directly from other existing working group within the RAI area (e.g.,
> SIPRec and Splices).  The requirements document shall deliver the
> possible scenarios where the Session Identifier would be used.
> This group will first focus on a document that will identify, collect
> and discuss all the requirements and use cases. Once the needs are clear
> and identified, the working group will specify the end-to-end Session
> Identifier mechanism.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Nov 2011 10:06:47 -0500

Paul J,

Based on your recent replies, I am coming to the conclusion that at 
least part of the distinction you are drawing between "endpoint" and 
"intermediary" is based on the extent to which the device processes media.

Is that right? If so, then how much processing must it do to be declared 
an endpoint? If it terminates and then simply forwards packets to a 
single destination, is it an intermediary? What if it acts as a 
transcoder, which does a lot of processing of the media?

Does this have to do with whether the media has *one* final destination?

What if there is no media? (E.g. a subscription.)

I'm looking for a clear definition of when you class a box as an 
endpoint, and when you class it as an intermediary. Once we have a clear 
definition we can discuss what to call the intermediary.

	Thanks,
	Paul K

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 9 Nov 2011 10:19:32 -0500

Kevin,

I think one could easily build a case for why Asterisk might always have two
session-ids (one on the left and one on the right), then one for any
additional participants.  I would not personally be unhappy with that, since
the PBX is arguably an endpoint device.  If a phone other than a SIP phone
was connected to it (e.g., one controlled via a device control protocol),
then one would definitely not argue that the PBX is the endpoint device.

As with any protocol feature, some decisions must be left up to the
implementer.  I'd personally prefer two communicating SIP phones have a
common understanding of the session ID, of course.  This is particularly
important if this might be communicated directly between each other through
protocols like RSVP.  But, if Asterisk is handling all of the media, that
also presents no issue for RSVP (since those would terminate on Asterisk).

Paul

> Sent: Wednesday, November 09, 2011 9:05 AM
> To: Ravindran, Parthasarathi
> Cc: [email-masked]
> > Could you please clarify whether UPDATE or any other method in your
> mind to communicate in case RE-INVITE is complicated.
> 
> >>>> (RFC3911) to the PBX to add himself to the conversation. It becomes
> >>>> a three-way conversation, with the PBX mixing media and sending it
> >>>> to
> >> all
> >>>> three of us.
> >>>
> >>> At this point, it would appear the PBX changed roles from acting as
> >>> an intermediary to acting as an MCU, since it is doing the mixing.
> >>> I
> >> assume
> >> In my experience, devices acting in the PBX role in this scenario do
> >> not do this; the two existing endpoints are not made aware of the
> >> third party joining the call (although presumably the users of those
> >> endpoints become aware of it<G>). While they certainly *could* issue
> >> a re-INVITE in this situation in order to construct/communicate a new
> >> Session-ID, this would be new behavior required to support Session-ID
> >> usage, and is potentially significantly more complicated to implement
> >> than just communicating some header values between sessions.
> >>
> >> --
> >> Kevin P. Fleming
> >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at
> >> www.digium.com&  www.asterisk.org
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at
> www.digium.com & www.asterisk.org

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 09 Nov 2011 09:24:35 -0600

> also presents no issue for RSVP (since those would terminate on Asterisk).

I don't disagree; having Asterisk construct Session-UUID values on each 
side of a two-channel bridge would certainly be compliant with your 
proposal. However, in the interests of enabling users to achieve what 
the Session-ID proposal is designed to achieve, we'd probably want to 
strive to be transparent when possible (and I'd think it would be 
encouraged for other B2BUAs to do the same). I wouldn't really want to 
publicize that Asterisk version X.Y is 'compliant with RFC ZZZZ', but in 
a real-world deployment calls passing through Asterisk would lose the 
ability to tracked through their Session-ID values. Compliant yes... 
helpful, not so much :-)

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 9 Nov 2011 11:28:18 -0500

Paul,

> transcoder, which does a lot of processing of the media?

Media processing is one measure, though admittedly not entirely perfect. An
SBC that performs transcoding would still be classified as an intermediary
to me, for example.  A device that brings together multiple calls and mixes
or switches media would be acting as an endpoint (specifically, and MCU).
 
> Does this have to do with whether the media has *one* final destination?

First having been asked that question, I'm thinking "yes".
 
> What if there is no media? (E.g. a subscription.)

See, you just went and broke the above answer ;-)

If there is no media, there is still a SIP session.  I don't think the logic
would change.  A device in the middle of the network is either acting as a
more-or-less pass-through device or it's acting as a termination point, even
if there is no media.

For subscriptions, I do not have an answer.  I've only personally been
focused on exchanges where we establish sessions.
 
> definition we can discuss what to call the intermediary.

This does get challenging, because there are so many exceptions to any rule.
In the general case, I would say an endpoint is an entity that is callable
or can be called.  That would include physical devices like phones, MCUs,
and gateways. However, an SBC is a gateway, but it does not terminate a
call: it merely interconnects to a different network (same or different
protocol).  As such, an SBC I would classify as an intermediary.  A PBX is
sometimes the endpoint and sometimes an intermediary: it depends on whether
that is where the SIP or H.323 signaling terminates.  In the case where the
PBX is acting as the MCU, the signaling effectively terminates there,
because it takes full control over the multipoint conference.

Somewhere out of all of this, perhaps a definition can materialize.
However, I think we will always find an exception to any rule and something
that does not strictly fit a given definition.

Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 9 Nov 2011 13:56:18 -0500

If we're gong to make progress, I think we will have to include
"Working out a good definition of 'session'." as one of the tasks
for the WG.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Nov 2011 14:10:27 -0500

> "Working out a good definition of 'session'." as one of the tasks

Yes. It would be ideal if the definition was complete - able to classify 
all possible cases, with the classification for the "common" ones being 
something that we can agree is reasonable.

This is fundamental problem I have had with all the attempts to define a 
session id - its *hard* to come up with a widely agreeable definition of 
session.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 9 Nov 2011 20:19:54 +0100

There was one definition I used to like in ITU-T which was one of the their "call" definitions, which was something along the lines of "the association between two or more end users". Now if we use that definition to be the terminal (or UA) associated with that end user, it has the following characteristics:

1)	It enshrines the path into PSTN, or whatever else, that lies beyond the SIP gateway

2)	It enshrines all the users attached to a conference focus, and the conference focus itself.

3)	All the forks in a reguest would be part of the same "call".

While this may not be what we are trying to achieve with this new identifier, it may help identify what it is not.

Regards

Keith

> Behalf Of Paul Kyzivat
> Sent: 09 November 2011 19:10
> To: [email-masked]

---

From: Mary Barnes <[email-masked]>
Date: Wed, 9 Nov 2011 13:31:58 -0600

What is the definition used by the SIPREC (SIP (Session) Recording)
WG?  It would seem that you all should have struggled with the same
problem.  From the requirements, where the word is used 100 times in
that document.  Although, it looks like you all finagled your way out
of it by defining "Communication Session" as:
Communication Session (CS): A session created between two or more SIP
      User Agents (UAs) that is the subject of recording.

Mary.

On Wed, Nov 9, 2011 at 1:10 PM, Paul Kyzivat <[email-masked]> wrote:
> Yes. It would be ideal if the definition was complete - able to classify all
> possible cases, with the classification for the "common" ones being

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 9 Nov 2011 21:59:49 +0100

>      User Agents (UAs) that is the subject of recording.

I would like to avoid "session" - it will be confusing for my SIP students...

Do I open a can of worms if I ask how a "Session-ID" or "Dialog-group-ID" will relate to "SIP-history" ?

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Nov 2011 17:07:28 -0500

>        User Agents (UAs) that is the subject of recording.

We did (intentionally) leave the definition of Communication Session 
(CS) loose in siprec. In general the SRC is then free to represent a 
particular situation as one CS or multiple as it sees fit. There is 
(currently) no expectation that the (mythical) session-id is used as the 
way to determine which things are part of the same CS.

*If* the session-id mechanism was suitably defined, and widely 
implemented, then maybe it could be used as one input to the 
identification of a CS. But I am far from convinced that a definition 
useful to siprec would be useful for everybody else.

	Thanks,
	Paul

> Mary.
>
> On Wed, Nov 9, 2011 at 1:10 PM, Paul Kyzivat<[email-masked]>  wrote:

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 11 Nov 2011 12:04:18 -0500

Agreed!  And I don't care if we pick a different word other than "session"
if that causes too much confusion.  I just have no better word to offer at
the moment.

> Behalf Of Worley, Dale R (Dale)
> Sent: Wednesday, November 09, 2011 1:56 PM
> To: [email-masked]
> If we're gong to make progress, I think we will have to include "Working
> out a good definition of 'session'." as one of the tasks for the WG.
> 
> Dale

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 11 Nov 2011 12:15:08 -0500

Keith,

With that definition, I think we would re-define the "conference
identifier".  A single identifier associated with a conference focus and all
entities that are a part of that focus would be a conference identifier.
We're not trying to tackle that problem, though we tough on it in the
Session-ID draft.  If a conference focus uses the same UUID for all
participants, we would be able to see an association between those different
sessions.  However, that use is not a proper replacement for a conference ID
and isn't intended to be.  I do want to be careful not to mix these too
much: the focus is on identifying a session end-to-end, and a conference
focus might be one end.

Paul

> Behalf Of DRAGE, Keith (Keith)
> Sent: Wednesday, November 09, 2011 2:20 PM
> To: Paul Kyzivat; [email-masked]
> There was one definition I used to like in ITU-T which was one of the
> their "call" definitions, which was something along the lines of "the
> association between two or more end users". Now if we use that
> definition to be the terminal (or UA) associated with that end user, it
> has the following characteristics:
> 
> While this may not be what we are trying to achieve with this new
> identifier, it may help identify what it is not.
> 
> Regards
> 
> Keith
> 
> > Yes. It would be ideal if the definition was complete - able to
> > classify all possible cases, with the classification for the "common"
> > ones being something that we can agree is reasonable.
> >
> > This is fundamental problem I have had with all the attempts to define
> > a session id - its *hard* to come up with a widely agreeable
> > definition of session.
> >
> > 	Thanks,
> > 	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Nov 2011 04:20:13 +0000

One thing I'd suggest is that if a solution such as draft-jones-ipmc-session-id-00 is adopted by the new WG, that it not treat the ID as one value, but in fact make them explicitly two separate value tokens: similar to the current from/to tags being unique tag values.  I'm not suggesting it be From/To header parameters - just that it be two separately encoded values, one generated by Alice, one by Bob - and their combination be session identifiers or whatever we call them.

-hadriel

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 12 Nov 2011 23:58:20 -0500

They definitely are two values.  The concatenation of the two under that
proposal is the "Session-ID".

Paul

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Saturday, November 12, 2011 11:20 PM
> To: Paul E. Jones
> Cc: Worley, Dale R (Dale); <[email-masked]>
> One thing I'd suggest is that if a solution such as draft-jones-ipmc-
> session-id-00 is adopted by the new WG, that it not treat the ID as one
> value, but in fact make them explicitly two separate value tokens:
> similar to the current from/to tags being unique tag values.  I'm not
> suggesting it be From/To header parameters - just that it be two
> separately encoded values, one generated by Alice, one by Bob - and
> their combination be session identifiers or whatever we call them.
> 
> -hadriel
> 
> 
> > if that causes too much confusion.  I just have no better word to
> > offer at the moment.
> >
> >> "Working out a good definition of 'session'." as one of the tasks for
> the WG.
> >>
> >> Dale

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 13 Nov 2011 19:03:00 +0100

Understood, but if there is no conference and only two parties, the two definitions converge to one.

And we do need to understand that relationship.

Keith

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: 11 November 2011 17:15
> To: DRAGE, Keith (Keith); 'Paul Kyzivat'; [email-masked]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 13 Nov 2011 19:11:04 +0100

I'd just note that is not a requirement.

It is part of a solution to achieving uniqueness.

I suspect we need to get the requirements nailed down first.

Keith

> Sent: 13 November 2011 04:58
> To: 'Hadriel Kaplan'
> Cc: [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 13 Nov 2011 13:14:31 -0500

Keith,

Not necessarily.  In H.323, for example, there is both a "conference
identifier" and a "call identifier", even if there are only two
participants.  The intent is that if the call does expand into a conference
where there are more than two people, all participants would share the same
conference identifier, but each call to the MC would have its own call
identifier.

I'm personally favorable to keeping a conference identifier separate from
Session Identifier, as they are quite different in purpose. 

Paul

> Sent: Sunday, November 13, 2011 1:03 PM
> To: Paul E. Jones; 'Paul Kyzivat'; [email-masked]
> > identifier".  A single identifier associated with a conference focus
> > and all entities that are a part of that focus would be a conference
> > identifier.
> > participants, we would be able to see an association between those
> > different sessions.  However, that use is not a proper replacement for
> > a conference ID and isn't intended to be.  I do want to be careful not
> > to mix these too
> > much: the focus is on identifying a session end-to-end, and a
> > conference focus might be one end.
> >
> > Paul
> >
> > > From: [email-masked] [mailto:[email-masked]]
> > > On Behalf Of DRAGE, Keith (Keith)
> > > There was one definition I used to like in ITU-T which was one of
> > > the their "call" definitions, which was something along the lines of
> > > "the association between two or more end users". Now if we use that
> > > definition to be the terminal (or UA) associated with that end user,
> > > it has the following characteristics:
> > >
> > > 2)	It enshrines all the users attached to a conference focus,
> and the
> > > conference focus itself.
> > >
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > On Behalf Of Paul Kyzivat
> > > > > "Working out a good definition of 'session'." as one of the
> > > > > tasks for the WG.
> > > >
> > > > This is fundamental problem I have had with all the attempts to
> > > > define a session id - its *hard* to come up with a widely
> > > > agreeable definition of session.
> > > >
> > > > 	Thanks,
> > > > 	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 13 Nov 2011 13:15:38 -0500

Agreed.  The requirements document we have put forward does not prescribe
the method, but Hadriel commented specifically about our proposed solution.

Paul

> Sent: Sunday, November 13, 2011 1:11 PM
> To: Paul E. Jones; 'Hadriel Kaplan'
> Cc: [email-masked]
> > They definitely are two values.  The concatenation of the two under
> > that proposal is the "Session-ID".
> >
> > Paul
> >
> > > session-id-00 is adopted by the new WG, that it not treat the ID as
> > > one value, but in fact make them explicitly two separate value
> tokens:
> > > similar to the current from/to tags being unique tag values.  I'm
> > > not suggesting it be From/To header parameters - just that it be two
> > > >> From: [email-masked]
> > > >> [mailto:[email-masked]] On Behalf Of Worley, Dale R
> > > >> (Dale)
> > > >> for