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

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 30 Jan 2011 12:07:47 -0500

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

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 31 Jan 2011 18:37:51 +0530

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.

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 Kyzivat <[email-masked]>
Date: Mon, 31 Jan 2011 11:11:58 -0500

I think this is somewhat clearer than the earlier discussed version.

I still have some comments/questions about this:

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

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

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

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

   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.

   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?

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

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.

	Thanks,
	Paul (K)

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 31 Jan 2011 21:34:31 -0500

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

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

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 1 Feb 2011 10:58:43 +0530

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

> One of the usecase of UUID is SIPREC CS group id (CSG) mechanism . 
> Here, Session Recording Client (SRC) shall create one portion of UUID,

> I just wanted to draw your attention to the revised Session ID draft 
> we just submitted.  Following the discussion we had on this topic

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 1 Feb 2011 08:40:16 +0100

> media flows, signaling exchanges, associating devices in a conference, etc.

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