Subject: Re: [Insipid] INSIPID Req#9 - comments?

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 9 May 2012 12:43:12 +0200

Hi,

Regarding the requirement for making the identifier suitable for transmission in RTCP and the associated use case of associating signaling and media flows.

I doubt that it is a good idea to attempt to include the same identifier in the media/RTCP as the signaling as even if this is possible in some scenarios it is most likely not possible in many and will break in others.  

Is it really a requirement for the identifier to be used to associate signaling with media personally I am thinking it is not.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: 26 April 2012 21:06
> To: [email-masked]
> Subject: [Insipid] INSIPID Req#9 - comments?
> 
> Figure it is about time I sent these requirements out to the list.
> Comments, questions and wordsmithing are encouraged. Let's see if we
> can leave much of the wordsmithing till the end of the discussion,
> once we have agreed on the requirement's worthiness and contents.
> 
> Let's also keep the discussion on *this* thread to just *this*
> requirement for tracking purposes. There are 9 current requirements.
> Therefore, there will be 9 different messages sent to this list.
> 
> Here is REQ#9 as currently written in
> http://www.ietf.org/internet-drafts/draft-jones-insipid-session-id-
> reqts-00.txt
> 
>     REQ9: The identifier should be constructed in such a way as
>     to make it suitable for transmission in SIP, H.323, RSVP
>     [3], and RTCP [4].
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 9 May 2012 19:30:40 +0200

Just like to add that the INSIPID charter indicates that the group will focus on a SIP Identifier and does not say anything about a media level identifier. I assume that specifying something for RTCP is therefore out of scope.

Regards
Andy 

> Behalf Of Hutton, Andrew
> Sent: 09 May 2012 11:43
> To: James M. Polk; [email-masked]
> Subject: Re: [Insipid] INSIPID Req#9 - comments?
> 
> Hi,
> 
> Regarding the requirement for making the identifier suitable for
> transmission in RTCP and the associated use case of associating
> signaling and media flows.
> 
> I doubt that it is a good idea to attempt to include the same
> identifier in the media/RTCP as the signaling as even if this is
> possible in some scenarios it is most likely not possible in many and
> will break in others.
> 
> Is it really a requirement for the identifier to be used to associate
> signaling with media personally I am thinking it is not.
> 
> Regards
> Andy
> 
> 
> 
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 09 May 2012 18:14:48 -0400

Specifying it is out of scope, but the objective to have an ID that 
/could be /used in RTCP is nonetheless desirable.

I'd like to be able to use this as a means of correlating media flows.  
I'd like to be able to identify which set of flows have a direct 
relationship or indirect relationship.  There are things we can do with 
that information in the network.

Paul

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 10 May 2012 15:54:11 -0500

Andy

I don't want this to come off as too confrontational, but saying "I 
doubt it is a good idea" isn't technical enough for many to agree with you.

Picking only on RTCP, can you specifically list a few scenarios in 
which it will break RTCP?

As to "Is it really a requirement for the identifier to be used to 
associate signaling with media", right now that's req#9 because the 
requirements document lists it as a requirement. Saying only that you 
don't like something doesn't make it go away. We need more technical 
details as to why it doesn't make sense or why it breaks X and Y, and 
you need to be more open to others wanting to counter what you say 
for cases in which it does make sense.

Is this agreeable?

James

At 05:43 AM 5/9/2012, Hutton, Andrew wrote:
>possible in some scenarios it is most likely not possible in many 
>and will break in others.
>
>Is it really a requirement for the identifier to be used to 
>associate signaling with media personally I am thinking it is not.
>
>Regards
>Andy
>
>
>
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 10 May 2012 16:00:52 -0500

Andy

SIP is text based, and H.323 is binary based. One stated goal is to 
have this same (i.e., identical) identifier used in H.323. What that 
said, anything that is binary and extensible, and not fixed length, 
can conceivably carry this same identifier. That includes many 
protocols, RTCP, RSVP, H.323, H.248, etc.

As long as this session-ID is compatible with H.323, it can be placed 
in several more protocols that can use it viably, as long as it 
doesn't break them.

Further, IMO, as long as we know specific scenarios in which this ID 
will or will not break another protocol - I see no reason not to list 
those protocols and/or use-cases, if only in an appendix of solution doc.

James

At 12:30 PM 5/9/2012, Hutton, Andrew wrote:
>Just like to add that the INSIPID charter indicates that the group 
>will focus on a SIP Identifier and does not say anything about a 
>media level identifier. I assume that specifying something for RTCP 
>is therefore out of scope.
>
>Regards
>Andy
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sat, 12 May 2012 13:53:55 +0200

Hi James,

Don't worry about being confrontational that's part of the fun.

The main issue from my point of view is to determine whether correlating the media streams with signaling is a problem that the INSIPID WG is going to tackle. My understanding was that the WG was tasked with standardizing an identifier which could be passed end to end over the signaling path without being mangled by intermediaries. If the same identifier could be used over other session establishment protocols like H.323 then that would be also be nice. However I did not envisage that the same identifier was going to be used on the media plane.

The issue of correlating the media and signaling streams is a different problem space that I for one had not envisaged was within scope of INSIPID and one for which I have not seen the same need.

I did not say that including such an identifier in RTCP would break RTCP and I don't think it would. However any mechanism for correlating media streams with signaling will break in some scenarios.  It has to be assumed that the signaling and media will not flow through the same set of intermediaries and therefore there is always scope for things to go wrong if you are attempting to use the same identifier in both signaling and media.

I would argue that the use case below is not a valid use case within the scope of INSIPID and there should be no requirement to be able to include the identifier in RTCP and probably not RSVP either.

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

Regards
Andy

> Sent: 10 May 2012 21:54
> To: Hutton, Andrew; [email-masked]
> Cc: James M. Polk

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 16 May 2012 10:49:55 -0400

Andy,

I do have a desire to associate signaling with media flows, and to associate
one flow with another flow.  The Session-ID could be used for that for me.
Perhaps I would not use the Session-ID directly, but perhaps I might.  If
the Session-ID was defined as two GUIDs (Alice || Bob), perhaps
sha(Alice||Bob) might serve my purposes.

A SIP session is not only the call signaling, but the associated media
flows, too.  I would not necessary expect some value inserted into every RTP
packet or RTCP packet, etc., but we should strive for a construction that
would potentially allow for its inclusion.  What I would like to avoid is
some long, variable-length ASCII string that makes it a challenge to use
anywhere outside of an INVITE or 200.  I'd like a reasonably compact binary
encoding (that can also be expressed in ASCII).

Paul

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hutton, Andrew
> Sent: Saturday, May 12, 2012 7:54 AM
> The main issue from my point of view is to determine whether correlating
> the media streams with signaling is a problem that the INSIPID WG is going
> to tackle. My understanding was that the WG was tasked with standardizing
> an identifier which could be passed end to end over the signaling path
> without being mangled by intermediaries. If the same identifier could be
> used over other session establishment protocols like H.323 then that would
> be also be nice. However I did not envisage that the same identifier was
> going to be used on the media plane.
> 
> The issue of correlating the media and signaling streams is a different
> problem space that I for one had not envisaged was within scope of INSIPID
> and one for which I have not seen the same need.
> 
> I did not say that including such an identifier in RTCP would break RTCP
> and I don't think it would. However any mechanism for correlating media
> streams with signaling will break in some scenarios.  It has to be assumed
> that the signaling and media will not flow through the same set of
> intermediaries and therefore there is always scope for things to go wrong
> if you are attempting to use the same identifier in both signaling and
> media.
> 
> I would argue that the use case below is not a valid use case within the
> scope of INSIPID and there should be no requirement to be able to include
> the identifier in RTCP and probably not RSVP either.
> 
> "Association of session signaling and media flows, made possible by
> including the session identifier in media-related messages (e.g., RSVP or
> RTCP).
> 
> Regards
> Andy
> 
> 
> 
> 
> 
> > you need to be more open to others wanting to counter what you say for
> > cases in which it does make sense.
> >
> > Is this agreeable?
> >
> > James
> >
> > > > From: [email-masked] [mailto:[email-masked]]
> > > > On Behalf Of James M. Polk

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 18 May 2012 11:28:41 +0200

Hi Paul,

I understand the desire to associate signaling with media but this to me is clearly not within the scope of the INSIPID charter which only talks about correlating SIP Messages and dialogs so we should not have requirements and use cases for correlating signaling with media.

I think we need to clarify this and some of the terminology before moving forward for example when do we really mean a "dialog" and when do we mean a "session". For example REQ3 in your draft which currently states

"REQ3: It must be possible to identify all sessions participating in a multipoint or multi-party conference by observing the end-to-end session identifiers of each session".

Should this really be:

"REQ3: It must be possible to identify all SIP dialogs participating in a multipoint or multi-party conference by observing the end-to-end session identifiers of each SIP dialog".

Regards
Andy

> From: Paul E. Jones [mailto:[email-masked]]
> Sent: 16 May 2012 15:50
> To: Hutton, Andrew; 'James M. Polk'; [email-masked]
> Subject: RE: [Insipid] INSIPID Req#9 - comments?
> 
> Andy,
> 
> Behalf
> > > doubt it is a good idea" isn't technical enough for many to agree
> with
> > > you.
> > >
> and
> associate
> > > > > Comments, questions and wordsmithing are encouraged. Let's see
> if
> > > we
> > > > > http://www.ietf.org/internet-drafts/draft-jones-insipid-
> session-id
> > > > > -
> > > > > reqts-00.txt
> > > > >

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 18 May 2012 08:58:56 -0400

Andrew,

> I understand the desire to associate signaling with media but this to me
> is clearly not within the scope of the INSIPID charter which only talks
> about correlating SIP Messages and dialogs so we should not have
> requirements and use cases for correlating signaling with media.

The requirement does not say that flows must be correlated.  We merely
propose that the identifier be constructed in such a way that it can be
carried in other protocols.  How it might be used on those other protocols
is outside the scope of this document.  There document only says it might be
used for other purposes, but does not require it.
 
> I think we need to clarify this and some of the terminology before moving
> forward for example when do we really mean a "dialog" and when do we mean
> a "session". For example REQ3 in your draft which currently states

We debated that.  Some wanted to define it and some did not.  However, a
"session" or "communication" session in my documents is always the same --
it is an end-to-end (dare I say) "session".  It might be comprised of one or
more dialogs.
 
> "REQ3: It must be possible to identify all sessions participating in a
> multipoint or multi-party conference by observing the end-to-end session
> identifiers of each session".

This does not mean multiple dialogs.  This means multiple sessions.  If
there are 10 people (10 different "calls" or "sessions") participating in a
conference, it would be desirable to be able to recognize that all 10 are
participants in the same conference.

Paul
 
> Should this really be:
> 
> "REQ3: It must be possible to identify all SIP dialogs participating in a
> multipoint or multi-party conference by observing the end-to-end session
> identifiers of each SIP dialog".
> 
> Regards
> Andy
> 
> 
> 
> > I do have a desire to associate signaling with media flows, and to
> > associate one flow with another flow.  The Session-ID could be used
> > for that for me.
> > flows, too.  I would not necessary expect some value inserted into
> > every RTP packet or RTCP packet, etc., but we should strive for a
> > construction that would potentially allow for its inclusion.  What I
> > would like to avoid is some long, variable-length ASCII string that
> > makes it a challenge to use anywhere outside of an INVITE or 200.  I'd
> > like a reasonably compact binary encoding (that can also be expressed
> > in ASCII).
> >
> > Paul
> >
> > > without being mangled by intermediaries. If the same identifier
> > > could
> > be
> > > > I don't want this to come off as too confrontational, but saying
> > > > "I doubt it is a good idea" isn't technical enough for many to
> > > > agree
> > with
> > > > you.
> > > >
> > > > associate signaling with media", right now that's req#9 because
> > > > the requirements document lists it as a requirement. Saying only
> > > > that
> > you