Subject: [Insipid] Use case for association of session signaling and media flows

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 6 Jul 2012 11:48:19 +0200

(As WG cochair)

We have taken out the text:

" * Association of session signaling and media flows, made possible
      by including the session identifier in media-related messages
      (e.g., RSVP or RTCP)"

In order to keep text that has full consensus as a working group draft.

That however does not mean we have consensus not to include it.

So I would like people to discuss this use case and whether there is merit or not in such a use case.

I would also note that we need to expand both this text, and the text the originally surrounded it, into some more complete text about a use case, and maybe one of the ways forward in this discussion is for someone to do this.

Regards

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jul 2012 11:19:19 -0400

> I would also note that we need to expand both this text, and the text the originally surrounded it, into some more complete text about a use case, and maybe one of the ways forward in this discussi…

I have an open mind about this one. But I have questions about it:

Is the thought that there is already a suitable field in RSVP, and one 
in RTCP, for carrying this? Or is this implying that extensions should 
be made to those to carry this data?

If the thinking is that extensions are needed, then I think we should 
rule this out of scope.

If the intent is to use existing fields, then they should be spelled 
out, with whatever limitations those would imply on this work.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 7 Jul 2012 01:00:56 -0400

Paul,

> Is the thought that there is already a suitable field in RSVP, and one in
> RTCP, for carrying this? Or is this implying that extensions should be
> made to those to carry this data?

There is no suitable field presently, though we could introduce extensions.
What form? I do not know right now.  I like the thought of inserting it into
a PATH message, though, since systems that are logging information could log
that value.  The correlation could be done in real-time or later.  If a user
reports poor voice/video quality, for example, one might know the precise
path of the media through the network or other information about the call,
more than just where the signaling went.
 
> If the thinking is that extensions are needed, then I think we should rule
> this out of scope.

Extensions would be needed to other protocols, but we're definitely not
suggesting this group undertake work on anything related to RTP, RTCP, RSVP,
or anything else media related.  What missing in that snippet of text above
is that the preceding text.  What we had written was that the Session-ID
should be defined so as to enable its use in other protocols.  To do that is
not hard.  A UUID is workable.  Two UUIDs is workable.  A 2048-byte string
is out of the question.  We should not use a value that in any way allows
association with a particular person, since the RTCP or RSVP packet might
reveal information in the clear.  Thus, a Session-ID that is comprised of
certain values in SIP headers would be a bad choice.

In any case, this is a forward-looking use case, but I can see the benefit
in associating signaling and media flows.  I just wanted to make sure we did
not make a poor choice and then later if we decide we really want that kind
of capability, find ourselves stuck and need to define yet another
identifier.
 
> If the intent is to use existing fields, then they should be spelled out,
> with whatever limitations those would imply on this work.

We would not propose use of existing fields, even if something existed.  The
use case is just that: what we might want to do with it.  We're not
specifying how to do it, nor is it clear whether we will.  (That said, I'd
like to think about this, but one step at a time.)

Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 7 Jul 2012 10:21:02 +0200

6 jul 2012 kl. 17:19 skrev Paul Kyzivat:

> Is the thought that there is already a suitable field in RSVP, and one in RTCP, for carrying this? Or is this implying that extensions should be made to those to carry this data?
RTCP has application specific fields that can be used for this type of data, like the APP packet type. But that may be seen as misuse. There is an IANA registry for
new fields. Or... Hmm.

According to RFC 3550 there should be a registry for RTCP packet types at IANA, but I can't find it.

/O

> 
> If the thinking is that extensions are needed, then I think we should rule this out of scope.
> 
> If the intent is to use existing fields, then they should be spelled out, with whatever limitations those would imply on this work.
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Jul 2012 23:12:50 +0200

Hi,

I think there are cases where it would be useful to explicitly associate media and signalling, and if the session-id somehow can be used for that - fine.

However, isn't such mechanism outside the current charter of INSIPID?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: 7. heinäkuuta 2012 11:21
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Insipid] Use case for association of session signaling and media flows

> Is the thought that there is already a suitable field in RSVP, and one in RTCP, for carrying this? Or is this implying that extensions should be made to those to carry this data?
RTCP has application specific fields that can be used for this type of data, like the APP packet type. But that may be seen as misuse. There is an IANA registry for new fields. Or... Hmm.

/O

---

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 9 Jul 2012 23:46:40 -0400

Christer,

The mechanisms certainly are our of scope.  All I was hoping for at this
point was to ensure that we do not make it difficult or impossible to one
day associate media and signaling by making a poor choice in how we
construct the Session-ID.

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christer Holmberg
> Sent: Monday, July 09, 2012 5:13 PM
> To: 'Olle E. Johansson'; Paul Kyzivat
> Cc: [email-masked]
> I think there are cases where it would be useful to explicitly associate
> media and signalling, and if the session-id somehow can be used for that -
> fine.
> 
> >> I would also note that we need to expand both this text, and the text
> the originally surrounded it, into some more complete text about a use
> case, and maybe one of the ways forward in this discussion is for someone
> to do this.
> >
> in RTCP, for carrying this? Or is this implying that extensions should be
> RTCP has application specific fields that can be used for this type of
> data, like the APP packet type. But that may be seen as misuse. There is
> an IANA registry for new fields. Or... Hmm.
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Jul 2012 21:52:03 +0200

Hi, 

>The mechanisms certainly are our of scope.  All I was hoping for at this point was to ensure that we do not make it difficult or impossible to one day associate media and signaling by making a poor 
>choice in how we construct the Session-ID.

But, how would you be able to determine whether the requirement has been fulfilled?

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
> I think there are cases where it would be useful to explicitly 
> associate media and signalling, and if the session-id somehow can be 
> used for that - fine.
> 
> >> So I would like people to discuss this use case and whether there 
> >> is
> merit or not in such a use case.
> >>
> case, and maybe one of the ways forward in this discussion is for 
> someone to do this.
> >
> data, like the APP packet type. But that may be seen as misuse. There 
> is an IANA registry for new fields. Or... Hmm.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 10 Jul 2012 23:05:02 -0400

> >The mechanisms certainly are our of scope.  All I was hoping for at
> >this point was to ensure that we do not make it difficult or impossible
> to one day associate media and signaling by making a poor choice in how we

We probably cannot absolutely.  However, if we do know of constraints placed
on certain protocols, we could ensure we meet those constraints.  For
example, if we were to encode the Session-ID in RTCP, we might place it an
SDES packet.  That imposes a length limit of 255 octets.

The best we can do is to try to avoid making a bad choice.  I do not think
we can guarantee it.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 14:51:32 -0400

I suggest replacing these requirements with ones that constrain the form 
of the id - its encoding and length. These can say *why* these 
constraints are applied, but in the end we will have something that we 
can measure. But the constraints should be as liberal as they can be 
while meeting the need.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Jul 2012 21:09:11 +0200

Hi,

I agree with Paul.

Regards,

Christer

________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: Wednesday, July 11, 2012 9:51 PM
To: Paul E. Jones
Cc: Christer Holmberg; 'Olle E. Johansson'; [email-masked]
Subject: Re: [Insipid] Use case for association of session      signaling       and     media flows

        Thanks,
        Paul

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 11 Jul 2012 23:54:02 -0400

[as individual]

I completely agree. IMO the requirement is valuable and should remain simply as a best practice to future-proof the Session-ID we're developing.  We all agree that defining the mechanisms/extensions to handle the Session-ID in other protocols like RSVP/RTCP/H323/etc is out of scope for this WG, but as discussed during the last interim this requirement needs hardening to something more practically achievable. As Paul suggests, putting our heads together and coming up with some construction requirements/restrictions based on our collective knowledge of those other protocols seems the best way forward. This would maintain the original spirit of the requirement but allows it to be reworded less nebulously.

Gonzalo

On Jul 11, 2012, at 2:51 PM, Paul Kyzivat wrote:

> I suggest replacing these requirements with ones that constrain the form of the id - its encoding and length. These can say *why* these constraints are applied, but in the end we will have something that we can measure. But the constraints should be as liberal as they can be while meeting the need.
> 
> 	Thanks,
> 	Paul
>