Subject: [Insipid] Comments on draft-jones-insipid-session-id-reqts-00

From: Hendrik Scholz <[email-masked]>
Date: Thu, 19 Apr 2012 11:39:02 +0200

Hi!

Here are a few comments on the -00 version:

REQ-5:
I've seen Media Gateway Controllers which constructed the
Call-ID using the A and B party phone numbers.
Obviously this turned anonymous calls into not-so-anonymous
calls.
I suggest adding 'subscriber ID' and/or 'phone number'
to the list of prohibited identifiers.

REQ-9:
An RFC 5576 (RTP SSRC) style SDP attribute would fulfill
the requirement. It would require boxes to parse SDP
and SDP is only present in few messages.
I believe we all know that by SIP we mean 'SIP and outside
SDP' but I just wanted to utter my opinion on this ;)

In order to implement conferencing and transfers there might
be a need to have a) multiple Session-IDs attached to
a single session or b) re-negotiate the Session-ID.

Sample call case:
Alice calls Bob. Session-ID is 'ab'.
Carol calls Dave. Session-ID is 'cd'.

Scenario One:
Alice (while still on the phone with Bob) calls Carol.
There is a new 'ac' Session-ID. Now she joins the
two 'ab' and 'ac' calls into a single conference call
in which her phone is mixing audio.
What would the Session ID look like?

Scenario Two:
Based on the previous scenario Carol now also bridges
Dave (Session 'cd') into the conference.

Which segments (both participant- and time-wise) should
the Session-ID describe?

Regards,
  Hendrik

-- 
Hendrik Scholz <[email-masked]>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 19 Apr 2012 14:41:56 -0400

Hendrik,

> REQ-5:
> I've seen Media Gateway Controllers which constructed the Call-ID using
> the A and B party phone numbers.
> Obviously this turned anonymous calls into not-so-anonymous calls.

Noting these are all example, but I certainly have no objection.  I will add
"Subscriber ID" to the -01 draft.
 
> REQ-9:
> An RFC 5576 (RTP SSRC) style SDP attribute would fulfill the requirement.
> It would require boxes to parse SDP and SDP is only present in few
> messages.
> I believe we all know that by SIP we mean 'SIP and outside SDP' but I just
> wanted to utter my opinion on this ;)

I don't understand this one.  The Session-ID is not a media-level element.
In SIP, I would expect it to be carried in the SIP header and in H.323 it
would be in the H.225.0 call signaling messages.  Most likely, INVITE and
SETUP messages, but perhaps also UPDATE and FACILITY messages.  (Mixing
protocols here; hopefully it's not confusing.)

Requirement 9 says that whatever the Session-ID is, it's something suitable
for insertion in other protocols.  It does not say where we insert it.  I
doubt we would put it in SDP, since it is in SIP already.  We might want to
include it in RTCP or RSVP, though.  Those are companion protocols that
could potentially make use of the Session ID.
 
> In order to implement conferencing and transfers there might be a need to
> have a) multiple Session-IDs attached to a single session or b) re-
> negotiate the Session-ID.

If we follow the approach we propose in the
draft-jones-insipid-session-id-00 draft, it would be possible for the MCU
(Conference Focus) to assign the same "half" value to all participants and
then each individual participant would contribute the other half.  It would
be immediately clear that all of the participants in a conference are
somehow related, though the relationship is not clear.  We do not have a
requirement to define that clear relationship.

When we do a transfer, we could fabricate an entirely new session ID.  I'd
personally like Alice to retain the value she was using, though, because
this allows one to trace calls in the network.  We could see, for example,
that Alice was interacting with Bob and is then later interacting with
Carol.  I think this could aid in troubleshooting.  Perhaps not, but we can
certainly have that discussion.
 
> There is a new 'ac' Session-ID. Now she joins the two 'ab' and 'ac' calls
> into a single conference call in which her phone is mixing audio.

If Alice calls Carol, neither would reuse 'a' or 'c'.  For any new call that
is initiated or any new call accepted (or even acknowledged), the calling or
called endpoint MUST produce a new Session-ID-UUID.  In our draft, we were
only suggesting that we retain a value as a call is transferred or joined.
The challenge we've had is describing this in SIP terms, but in human terms
it's like this:

>From the time I pick up my phone to call Bob to the time I hang up my phone
call with Bob (regardless if my call to Bob got transferred or joined
somehow to another call), my phone should use the same Session-ID-UUID for
that call.  If I put Bob on hold and place a separate call to Carol, my
phone would use a different UUID, as those are two entirely separate
communication sessions.

The challenge we've had is that "session" is an overloaded or ill-defined
term... I'm still not sure which.  How can we have a "Session Initiation
Protocol" if we cannot define "session" or "communication session"? :-)
 
> Scenario Two:
> Based on the previous scenario Carol now also bridges Dave (Session 'cd')
> into the conference.
> 
> Which segments (both participant- and time-wise) should the Session-ID
> describe?

Carol bridges Dave into what conference?  You mean Carol brings together the
call with her, Alice, and Dave?

If so, it depends.  If she transfers the call to an MCU, then I'd expect the
MCU to use a UUID 'm' to each of Carol, Bob, and Dave.  We'd see three
session IDs.

If Carol locally bridges media and mixes it, there may be two Session-IDs:
one between Alice and Carol and one between Carol and Dave.  Locally merging
a call has no effect on session signaling, so we should not see that
reflected in SIP in any way, IMO.

Paul

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 19 Apr 2012 23:59:14 -0500

Hendrik

this would cause the original 'a' to become 'a1' between alice and 
bob. then when alice calls carol, this session-id is a2-c. It all 
comes down to where is the media mixing, i.e., at alice's UA or at an 
MCU. What you described is a case of independent calls from alice to 
bob (a1-b) and also alice to carol (a2-b). That is different than if 
bob transfers alice to carol, which we prefer for alice to keep her 
half key for session tracking purposes (resulting in the original 
alice to bob (ab) becoming alice to carol (ac)).

> > Based on the previous scenario Carol now also bridges Dave (Session 'cd')

where is the media mixing?

if at carol's UA, then there are two independent calls or sessions 
with different session-ids, (ac) and (cd).

if in an MCU alice's half key would marry with the MCU's half key for 
that conference (am), carol's session-id would become (cm), and 
dave's would be (dm).

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Apr 2012 10:25:59 -0400

> this would cause the original 'a' to become 'a1' between alice and bob.
> then when alice calls carol, this session-id is a2-c. It all comes down
> to where is the media mixing, i.e., at alice's UA or at an MCU. What you
> described is a case of independent calls from alice to bob (a1-b) and
> also alice to carol (a2-b). That is different than if bob transfers
> alice to carol, which we prefer for alice to keep her half key for
> session tracking purposes (resulting in the original alice to bob (ab)
> becoming alice to carol (ac)).
>

If an INVITE/replaces is accepted, are you proposing that the half-id 
from the replaced call be reused?

>> phone would use a different UUID, as those are two entirely separate

The problem with the latter is that there are two different scenarios 
covered by this case:

- You complete the call with Carol, end it, and resume the call
   with Bob. It makes sense that the two calls a labeled differently.

- You verify that Carol is available, fill her in on what you have been
   discussing with Bob, and then join the two calls into a conference.
   You would probably prefer that your end of both calls be labeled the
   same.

If your UI is structured so that your phone knows, at the time you 
initiate the call to Carol, that you intend to form a conference, or 
not, then it could do the "right" thing in both cases.

But there are common examples where this is not known at the time the 
call to Carol is initiated. (You might not even know yet.) If so, then 
it becomes impossible to satisfy both cases.

>> Protocol" if we cannot define "session" or "communication session"? :-)

IMO its *both* overloaded and ill-defined. :-)

The solution is to recognize this and either avoid the word entirely, or 
else always use it with a qualifying adjective.

> where is the media mixing?

Why does it matter?

> if at carol's UA, then there are two independent calls or sessions with
> different session-ids, (ac) and (cd).

ISTM you are confusing your assumed mechanism with the intended result.

	Thanks,
	Paul

---

From: Hendrik Scholz <[email-masked]>
Date: Mon, 23 Apr 2012 11:52:18 +0200

Hi,

thanks for all the input. The requirements document did not state
that the construction of the Session-ID must be based on the UUID
from both endpoints. That's what made it confusing.

I'll read the implementation description and will come back
if there are any open questions.

Hendrik

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 23 Apr 2012 10:29:06 -0400

Hendrik,

Hopefully I did not confuse you further.  The requirements document does not
mention UUIDs since that is one proposed solution, not a requirement.

The requirements should, indeed, stand on their own independent of a
particular solution.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hendrik Scholz
> Sent: Monday, April 23, 2012 5:52 AM
> To: [email-masked]
> Subject: Re: [Insipid] Comments on draft-jones-insipid-session-id-reqts-00
> 
> Hi,
> 
> thanks for all the input. The requirements document did not state that the
> construction of the Session-ID must be based on the UUID from both
> endpoints. That's what made it confusing.
> 
> I'll read the implementation description and will come back if there are
> any open questions.
> 
> Hendrik
> 
> --
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid