Subject: Re: [dispatch] draft-jones-ipmc-session-id-01

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 1 Feb 2011 16:01:17 -0500

Partha,

Usage in other protocols should be documented elsewhere.  I intend to
introduce the same Session-UUID in H.323 so that we do not lose the
end-to-end identification when we cross protocol boundaries.  For other
protocols, I think we would need other documents.

Paul

> -----Original Message-----
> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: Tuesday, February 01, 2011 12:29 AM
> To: Paul E. Jones; [email-masked]
> Subject: RE: [dispatch] draft-jones-ipmc-session-id-01
> 
> Paul,
> 
> As multiple applications *may* use this Session-UUID, this draft has to
> be tracked in generic fashion instead of going into specific application
> or problem. SIPREC solution will be designed in a generic enough fashion
> to handle different CS grouping (CSG) mechanism wherein Session-UUID
> could be used as one of the CSG mechanism.
> 
> IMO, This draft has to be tracked as separate WG or individual draft as
> this draft claims for the usage of session-UUID in non-SIP protocols
> like RSVP, RTCP.
> 
> Thanks
> Partha
> 
> -----Original Message-----
> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Tuesday, February 01, 2011 8:05 AM
> To: Parthasarathi R (partr); [email-masked]
> Subject: RE: [dispatch] draft-jones-ipmc-session-id-01
> 
> Partha,
> 
> Thanks for the feedback.  The question is "where do we go from here?"  I
> have a number of applications for a unique end-to-end session ID.
> SIPREC is certainly one where we can use it.  I'd also like to use it
> for tracing media flows, signaling exchanges, associating devices in a
> conference, etc.
> 
> Would this need a new WG unto its own?  Could this be a part of the WG
> proposed for looking at the "debugging" problem?  Could we put this work
> in SIPREC?
> 
> Paul
> 
> > -----Original Message-----
> > From: Parthasarathi R (partr) [mailto:[email-masked]]
> > Sent: Monday, January 31, 2011 8:08 AM
> > To: Paul E. Jones; [email-masked]
> > Subject: RE: [dispatch] draft-jones-ipmc-session-id-01
> >
> > Paul,
> >
> > The draft looks good in the high level.
> >
> > In case UUID is provided in two parts, it will helpful for analysis of
> 
> > UUID as UUID composes of two parts from different devices and only one
> 
> > portion will be helpful identify whether it is belongs to the same
> > session.
> >
> > One of the usecase of UUID is SIPREC CS group id (CSG) mechanism .
> > Here, Session Recording Client (SRC) shall create one portion of UUID,
> 
> > multiple participants *may* change during the session, and SRC portion
> 
> > of UUID will help to track the session. IMO, the syntax with two UUID
> > part provides more clarity.
> >
> > Thanks
> > Partha
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Paul E. Jones
> > Sent: Sunday, January 30, 2011 10:38 PM
> > To: [email-masked]
> > Subject: [dispatch] draft-jones-ipmc-session-id-01
> >
> > Folks,
> >
> > I just wanted to draw your attention to the revised Session ID draft
> > we just submitted.  Following the discussion we had on this topic
> > previously, we introduced one important change: rather than using the
> > Contact header, we introduce a new header to convey the UUID used by
> > each endpoint that comprises the Session-ID.
> >
> > The revised draft is here:
> > http://tools.ietf.org/html/draft-jones-ipmc-session-id
> >
> > We welcome any additional comments and input on a way to move this
> > forward.
> >
> > Paul
> >
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 1 Feb 2011 17:52:06 -0500

Paul,

> - This seems much like a dialog id, which includes a to-tag and
>    from-tag. The UUIDs you describe are much like the tags.

Yes, similar, though a tag is not globally unique.
 
> - I guess the difference from tags is that the tags are supposed to
>    be unique for each new dialog, while the UUIDs you describe are
>    supposed to retain the same UUID across multiple dialogs in some
>    cases. Is that right?

An MCU might consider using the same UUID value for each participant in the
same conference: we probably need to discuss that a bit to see if it makes
sense.

For other endpoints, I'd expect the UUID to remain the same for a single
dialog.  If a call is forwarded (3xx), the same UUID would be retained.  If
the call is transferred via REFER, then we might want to keep the same value
or create a new one.  There are pros and cons with each approach.  We're
proposing to keep it unchanged across dialogs in this case.
 
> - I don't quite follow the rules for when a UUID should remain
>    the same across dialogs and when it should be changed. This seems
>    to be related to implied definition of "session". Can you nail
>    that down in more detail? (You say the UUID must be retained when
>    the session is REFERed or redirected. But does that mean that all
>    processing of REFER and 3xx result in retaining the UUID, or only
>    when that preserves as "session"?

If we agree there is value in retaining the session-UUID even when a call is
redirected or transferred, yes.  I think the 3xx is not a point of
confusion, but REFER is.  From a user perspective, a "session" lives from
the moment a user calls a remote user to the time he/she hangs up the phone.
The call might be redirected or forwarded any number of times.  We
can/should define this if folks agree that we should retain this value
throughout the life of the "session".
 
> - A particular case that seems to break your model is if you start
>    with a conference, where the focus has provided the same UUID to
>    all the participants, and then you partition that into two
>    independent conferences. (The same physical server may remain the
>    focus of both, but there is no mixing going on between the two.)
>    Do you expect in such a case that a new UUID would be assigned for
>    one (or both) of the resultant conferences?

If a conference is partitioned like that, I would expect at least one or
perhaps both partitions to assume a new UUID value.  The reason is that at
least one of these conferences is no longer the same conference.
 
>    There are even more complex examples of this - any time the mixing
>    is not the same for all participants. E.g. when some participants
>    move to a sidebar and then back to the main conference.

It depends on how this is realized.  Would those be separate distinct
dialogs?
 
>    Another case would be a call center, where you have an agent
>    talking to a customer, and a supervisor listening in, receive only.
>    Then the supervisor might fully join it so there is equal mixing
>    among all three. Does that entail a change of UUID?

In this case, there is a call A<->B and somehow C is receiving media.  I
assume B is forwarding that media to C in a separate B<->C session.  B could
have used the same UUID with C, since this is a form of a "conference".  Or,
B could have used a distinct UUID with C.  The question as to which way is
the right way to go is outside the scope of what we're defining.  The
Session-ID draft intends to define the UUID and composition.  The rules for
construction/conveyance under carious conferencing scenarios may need to be
documented in a conferencing document somewhere, but not here. Multipoint
conferencing can get complex in a hurry, which is likely a reason it's not
fully addressed in 3261.
 
> - You specify:
> 
>     "If performing interworking
>     between SIP and another session protocol, the intermediary MUST
>     convert the Session-ID-UUID header as necessary so that it preserves
>     the value of the UUID."
> 
>     But this is not always possible - it depends on the protocol
>     being interworked. This should at least be acknowledged. As stated,
>     a GW that can't do this would be non-conforming.

Agreed.  I'll make a note of this.

> Something to consider here is whether this could be accomplished with an
> extension pertaining to how the to/from-tags are assigned, rather than
> introducing new tags for this purpose.

We had it as a tag in the Contact header before, but folks preferred a
separate header.  I have no strong preference where it goes, so long as we
retain the property that when A places a call, it sends a UUID in every
message to the remote device for the duration of the "session".

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Feb 2011 20:13:14 -0500

> Yes, similar, though a tag is not globally unique.

au contraire - From 3261 section 19.3:

    When a tag is generated by a UA for insertion into a request or
    response, it MUST be globally unique and cryptographically random
    with at least 32 bits of randomness.

(Of course this is often violated, but then you can't lose too much 
sleep over those who fail to follow the rules. If it hurts, don't do it.)

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 2 Feb 2011 02:09:14 -0500

Sal,

What changes would we need to meet the requirements of those two WGs? Any
specifics in mind now?

Paul

> Behalf Of Salvatore Loreto
> Sent: Tuesday, February 01, 2011 2:40 AM
> To: [email-masked]
> Subject: Re: [dispatch] draft-jones-ipmc-session-id-01
> 
> On 2/1/11 3:34 AM, Paul E. Jones wrote:
> > Partha,
> >
> > Thanks for the feedback.  The question is "where do we go from here?"
> > I have a number of applications for a unique end-to-end session ID.
> actually the draft can also be adapted to be also used in both the
> loosely coupled sip devices (SPLICES wg)
>   and  in the SIP interwork with XMPP (sixpac)
> 
> /Sal
> 
> --
> Salvatore Loreto
> www.sloreto.com
>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 2 Feb 2011 16:57:33 +0100

> What changes would we need to meet the requirements of those two WGs?
nothing specific at moment

/Sal

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 2 Feb 2011 16:42:13 +0000

Hi, 

I find the lack of a some specific examples is leaving me with a question I cannot answer by reading the spec (unless I missed something). 

So in a dialog startup:
A sends Session-ID with just it's UUID in it.
Final endpoint B responds with the combined UUIDs in a Session-ID header (it's own plus A's in sorted order)

So in e.g. debugging - if I want to correlate the INVITE with the response I am comparing a one UUID header with a two UUID header?

I don't think that is a huge deal - although it seems a bit more awkward than just having the initiators UUID used throughout. It would be good to make the benefits of 2 UUIDs in a header very clear. 

Regards,

Peter Musgrave

On 2011-01-30, at 5:07 PM, Paul E. Jones wrote:

> Folks,
> 
> I just wanted to draw your attention to the revised Session ID draft we just
> submitted.  Following the discussion we had on this topic previously, we
> introduced one important change: rather than using the Contact header, we
> introduce a new header to convey the UUID used by each endpoint that
> comprises the Session-ID.
> 
> We welcome any additional comments and input on a way to move this forward.
> 
> Paul
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 2 Feb 2011 12:28:40 -0500

Paul,

>     with at least 32 bits of randomness.

Ah, I thought they were locally unique.  I stand corrected.  Would we want
to use these as a session ID?  What are the limitations?  They are not
re-used when a call is REFERred, AFAIK.  Are there other limitations (e.g.,
3xx)?  The tags are also unbounded in length, which gives me some concern
when trying to use it in a protocol like RSVP.
 
> sleep over those who fail to follow the rules. If it hurts, don't do

I think I've seen too many flows with rule violations ;-)
 
Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Feb 2011 13:32:37 -0500

> when trying to use it in a protocol like RSVP.

While the similarities are striking, so are the differences.
The text *requires* that the tags be unique in cases where you want your 
ID to be non-unique.

It might be helpful to specify your ids so that the same values could be 
used as tags too. Then when appropriate, the tag and the id could be the 
same - being different only when to *point* is to reuse an old one.

	Thanks,
	Paul (K)

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 3 Feb 2011 01:32:40 -0500

Peter,

The idea as currently presented is that A sends its UUID to B and B sends
its UUID to A.  A and B both compose the Session-ID locally for whatever
purpose they might have for it.

So, in debugging, you would look at the INVITE that goes out.  There may be
multiple messages coming back due to forking.  One would use current
approaches (e.g., Call-ID, tags) to relate a response with an initial
request.  While we didn't propose extracting the Session-ID directly from
any single message, it can be constructed and used in logging, recording,
etc.

We could insert a UUID in the INVITE and a complete Session-ID in response
messages.  I have no objection to describing the procedure in that way, but
I'm not sure how much value there is in doing that.  It might make it easier
to see the Session-ID more readily, but any application that might need to
use it would already know one UUID already.

The uses of the Session-ID are several, including functions like logging,
recording, and relating media flows to sessions (e.g., use in RTCP and
RSVP).

The reason for not using a single UUID is that, in real systems, call legs
get joined/spliced/diced/chopped.  A might call B and C might call B and a
PBX managing B might join the call legs A and C together.  In so doing, we
have a new end-to-end call, but there may not be any session signaling on
the wire.  There would be a new INVITE sent from B's server (I assume), but
we need to ensure that A and C have a common understanding as to what the
new end-to-end Session-ID value is.  By conveying A's UUID to C and C's UUID
to A, each endpoint would know the end-to-end session has changed (device
change) and could use that new value in RTCP, RSVP, logging, etc.  Billing
systems or logging systems could also record that change.

I welcome any proposed changes to make this clearer, or changes that might
make the Session-ID easier to use.  We felt transmitting two UUID values was
simple and consistent, but I can see how it might not be perceived as so
simple by an external entity looking at the exchanges on the wire.

Paul

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Wednesday, February 02, 2011 11:42 AM
> To: Paul E. Jones
> Cc: DISPATCH list
> I find the lack of a some specific examples is leaving me with a
> question I cannot answer by reading the spec (unless I missed
> something).
> 
> So in a dialog startup:
> So in e.g. debugging - if I want to correlate the INVITE with the
> response I am comparing a one UUID header with a two UUID header?
> 
> I don't think that is a huge deal - although it seems a bit more awkward
> than just having the initiators UUID used throughout. It would be good
> to make the benefits of 2 UUIDs in a header very clear.
> 
> Regards,
> 
> Peter Musgrave
>

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 3 Feb 2011 06:43:24 +0000

Hi Paul, 

Thanks for the clarification. Hopefully the next version of the draft can include some concrete examples. 
> use it would already know one UUID already.
I see strong value in this - since I can then look at 200 OKs heading back through a chain of B2BUAs and make an association with an INVITE sent from the far end. 

> simple by an external entity looking at the exchanges on the wire.
You're right, I do have the perspective of looking at packets on the wire when I look at these things...and if we can make that simple with no real impact on the kernel of your idea then I think that is worthwhile. 

Thanks, 

Peter Musgrave

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Feb 2011 09:31:03 -0500

As I mentioned earlier in this thread, this approach is coming very 
close to reinventing the dialog-id.

The dialog-id consists of three parts:
- call-id
- from-tag
- to-tag

All three are required to be globally unique when assigned, and the 
combination is unique to a single dialog. If you omit the to-tag, then 
the combination of call-id and from-tag identifies all early and final 
dialogs that may arise as the result of a single dialog-establishing 
request (such as INVITE) after it is forked.

The call-id is normally reused, with a different from-tag, to retry 
dialog establishment after a 3xx.

Its my impression that some implementations violate some of the 
uniqueness rules here, assuming that its not necessary for each of the 
parts to be unique in order to get the combination to be unique. But of 
course doing that means that some of the partial combinations won't be 
unique.

The existing rules for tags and callid won't give a way to do the 
correlations that Paul J is looking for. But there is so much similarity 
that I think it makes sense to consider some way to tie it all together. 
For instance, perhaps there could be an optional "correlation-tag", 
which is just the sender's from/to-tag from a related (e.g. by transfer) 
dialog. Or maybe there could be multiple correlation-tags.

We could also *think* (very carefully) about changing the rules for when 
from-tags, to-tags, and callids are reused. (Even small changes have the 
potential to break things.)

Of course that all depends on SBCs not messing with the tags, and that 
could be a problem. But any of these schemes depend on SBCs not messing 
with *some* id.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 7 Feb 2011 00:08:31 -0500

Paul,

The fact that, in practice, many of these values are changed is an issue.
The fact that any scheme that relies on these existing attributes will also
not allow tracking a call end-to-end when interworking with other session
protocols (e.g., H.323) is an issue.  We need something that allows us to
side-step current implementation issues and also allows us to work
cross-protocol.

What I'd like to be able to do, also, is have something that works with 3xx
and REFER.  I'd like to have something that will allow conference
correlation.  We'd have to bend a few existing rules to make that happen.

So, my opinion is that the best solution is to introduce a new identifier.
As Mary noted, this has come up a few times before and I suspect it will
again.  I don't care with this identifier is in a separate header or a
parameter of a header.  It's all the same to me.  I did have it in the
Contact header, but folks wanted it as its own header.

Paul

> Behalf Of Paul Kyzivat
> Sent: Thursday, February 03, 2011 9:31 AM
> To: [email-masked]
> > The idea as currently presented is that A sends its UUID to B and B
> > sends its UUID to A.  A and B both compose the Session-ID locally for
> > whatever purpose they might have for it.
> >
> > So, in debugging, you would look at the INVITE that goes out.  There
> > may be multiple messages coming back due to forking.  One would use
> > current approaches (e.g., Call-ID, tags) to relate a response with an
> > initial request.  While we didn't propose extracting the Session-ID
> > directly from any single message, it can be constructed and used in
> > logging, recording, etc.
> >
> > We could insert a UUID in the INVITE and a complete Session-ID in
> > response messages.  I have no objection to describing the procedure in
> > that way, but I'm not sure how much value there is in doing that.  It
> > might make it easier to see the Session-ID more readily, but any
> > application that might need to use it would already know one UUID
> already.
> >
> > The uses of the Session-ID are several, including functions like
> > logging, recording, and relating media flows to sessions (e.g., use in
> > RTCP and RSVP).
> >
> > The reason for not using a single UUID is that, in real systems, call
> > legs get joined/spliced/diced/chopped.  A might call B and C might
> > call B and a PBX managing B might join the call legs A and C together.
> > In so doing, we have a new end-to-end call, but there may not be any
> > session signaling on the wire.  There would be a new INVITE sent from
> > B's server (I assume), but we need to ensure that A and C have a
> > common understanding as to what the new end-to-end Session-ID value
> > is.  By conveying A's UUID to C and C's UUID to A, each endpoint would
> > know the end-to-end session has changed (device
> > change) and could use that new value in RTCP, RSVP, logging, etc.
> > Billing systems or logging systems could also record that change.
> >
> > I welcome any proposed changes to make this clearer, or changes that
> > might make the Session-ID easier to use.  We felt transmitting two
> > UUID values was simple and consistent, but I can see how it might not
> > be perceived as so simple by an external entity looking at the
> exchanges on the wire.
> >
> > Paul
> >
> >> Final endpoint B responds with the combined UUIDs in a Session-ID
> >> header (it's own plus A's in sorted order)
> >>
> >> I don't think that is a huge deal - although it seems a bit more
> >> awkward than just having the initiators UUID used throughout. It
> >> would be good to make the benefits of 2 UUIDs in a header very clear.
> >>
> >> Regards,
> >>
> >> Peter Musgrave
> >>
> >>> previously, we introduced one important change: rather than using
> >>> the Contact header, we introduce a new header to convey the UUID
> >>> used by each endpoint that comprises the Session-ID.
> >>>