Subject: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-03.txt

From: Roni Even <[email-masked]>
Date: Fri, 11 Apr 2014 16:46:42 +0000

Hi ,
Based on the mailing list and London discussion this new version limited the scope of the token to be just a token  with no semantics that can be used as appId or recv-appId
Roni
________________________________________
From: [email-masked] [[email-masked]]
Sent: Friday, April 11, 2014 7:31 PM
To: Jonathan Lennox; Roni Even; Qin Wu; Roni Even; Jonathan Lennox; Qin Wu
Subject: New Version Notification for draft-even-mmusic-application-token-03.txt

A new version of I-D, draft-even-mmusic-application-token-03.txt
has been successfully submitted by Roni Even and posted to the
IETF repository.

Name:           draft-even-mmusic-application-token
Revision:       03
Title:          The Session Description Protocol (SDP) Application Token Attribute
Document date:  2014-04-11
Group:          Individual Submission
Pages:          14
URL:            http://www.ietf.org/internet-drafts/draft-even-mmusic-application-token-03.txt
Status:         https://datatracker.ietf.org/doc/draft-even-mmusic-application-token/
Htmlized:       http://tools.ietf.org/html/draft-even-mmusic-application-token-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-even-mmusic-application-token-03

Abstract:
   The RTP fixed header includes the payload type number and the SSRC
   values of the RTP stream.  RTP defines how to de-multiplex streams
   within an RTP session, but in some use cases applications need
   further identifiers in order to identify the signaling descriptions
   associated with particular RTP media streams.

   This document defines a mechanism to provide the mapping between the
   SSRCs of RTP streams and the SDP m-line description by defining
   extensions to RTP and RTCP messages.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Apr 2014 12:43:29 -0400

I have a couple of comments on the new version:

Section 4:

    An answerer, receiving an offer containing appId or recv-appId
    attributes, MUST respond with mirrored recv-appId and appId values
    for the subset of m= lines and packet streams indicated in the
    answer, maintaining the same recv-appId and appId values.

IIUC these aren't *mirrored*. Rather, for each appId in the offer there 
should be a recv-appId (with the same id value) in the answer, and for 
each recv-appId in the offer there should be a matching appId in the 
answer. It is this matching indication in the answer that tells the 
offerer that the answerer agrees.

IIUC, a recv-appId in the offer is intended so that media can be 
identified even before the answer is received. But at that time the 
offerer doesn't yet know if the answerer will accept it. So is the 
offerer just hoping it will work?

Also, this section makes it mandatory to use recv-appId with bundle. 
Isn't it only needed of the pt isn't unique?

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 14 Apr 2014 21:10:29 +0000

On Apr 14, 2014, at 12:43 PM, Paul Kyzivat <[email-masked]> wrote:

> IIUC these aren't *mirrored*. Rather, for each appId in the offer there should be a recv-appId (with the same id value) in the answer, and for each recv-appId in the offer there should be a matching appId in the answer. It is this matching indication in the answer that tells the offerer that the answerer agrees.

Right.  “Mirrored” was a poor choice of words.  We’ll clarify the wording in the next version.

> IIUC, a recv-appId in the offer is intended so that media can be identified even before the answer is received. But at that time the offerer doesn't yet know if the answerer will accept it. So is the offerer just hoping it will work?

Yes.  In general, you send an offer hoping it will work, yes?  I don’t see why recv-appId is any different.

If you mean, what happens if the answerer doesn’t support recv-appId?  I think appId needs to be mandatory for BUNDLE.

> Also, this section makes it mandatory to use recv-appId with bundle. Isn't it only needed of the pt isn't unique?

That’s a good point; the MUST should be changed to be scoped to non-unique PT values.

I’m inclined to say that appId and recv-appId MAY be used even if PTs are unique, and SHOULD be used if you expect you might re-offer with non-unique PTs in the future.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Apr 2014 19:19:57 +0000

Hi,

A few comments.

First, it is a little difficult for me to process the changes from the previous version. I am not sure what "token without semantics" mean. My understanding from London was that this draft was only going to define recv-appId, and the other stuff was going to be defined in a separate draft, but maybe I misunderstood.

Second, the draft defines BUNDLE procedures. I think those shall be defined in BUNDLE.

Third, the draft says that the appId token MUST be used with BUNDLE. However, what BUNDLE currently needs is the recv-appId mechanism. Have we decided to mandate usage of appId with BUNDLE?

Fourth, the draft will need quite a bit of editorial work :)

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Roni Even
Sent: 11 April 2014 19:47
To: [email-masked]
Subject: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-03.txt

Hi ,
Based on the mailing list and London discussion this new version limited the scope of the token to be just a token  with no semantics that can be used as appId or recv-appId Roni ________________________________________

A new version of I-D, draft-even-mmusic-application-token-03.txt
has been successfully submitted by Roni Even and posted to the IETF repository.

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 16 Apr 2014 15:11:19 -0700

Christer Holmberg said:
"I am not sure what "token without semantics" mean."
[BA] In this case, I think it means:  "there actually are semantics, but we're not going to tell you what they are" :)
For example, when an appId is included in an RTP packet with a given SSRC, and the appId is matched within the SDP, that RTP stream continues to be processed as if contained the appId, even when the appId is no longer present in the RTP packets. 
There are corner cases that can arise as a result of this, such as:
1. RTP packet 1 arrives with appId="foo" and SSRC=1. 2. RTP packet 2 arrives with appId="bar" and SSRC=1.3. RTP packet 3 arrives with no appId and SSRC=1.  Is it processed as though it contained "foo" or "bar"?  Inquiring minds want to know :)

---

From: "Roni Even" <[email-masked]>
Date: Thu, 17 Apr 2014 12:43:44 +0300

Hi,

By no semantics we meant that it is just a token with no parameters that
maps the RTP stream (packet stream) to a description in the SDP m-line. (we
agreed to take out the SSRC like functionality and have it at the end of the
document as issues that we may want to address for simulcast for example)

It addressed the cases described by Christer where the RTP arrives before
the SDP answer but also on the send direction for cases where the offerer
does not know the SSRC that will be used (see for example of the three
camera case bellow)

As for 

1. RTP packet 1 arrives with appId="foo" and SSRC=1. 

2. RTP packet 2 arrives with appId="bar" and SSRC=1.

3. RTP packet 3 arrives with no appId and SSRC=1.  Is it processed as though
it contained "foo" or "bar"?  Inquiring minds want to know :)

In this case the last appId is valid  so SSRC=1 is mapped appId="bar". I
think we missed this case in section 3.1 (the first bullet is about having a
new SSRC mapped to an existing appID which may happen for example when we
describe three m-lines each for one of  three cameras using the same PT
number and a fourth m-line describing the active speaker with an appId. So
if the answerer only wants to receive the steam from the fourth m-line the
appId will map to a different SSRC with each speaker switch. This is an
example use case for the appId in the offer)

Roni

From: mmusic [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 17 April, 2014 1:11 AM
To: Christer Holmberg; [email-masked]
Subject: Re: [MMUSIC] New Version Notification for
draft-even-mmusic-application-token-03.txt

Christer Holmberg said:

[BA] In this case, I think it means:  "there actually are semantics, but
we're not going to tell you what they are" :)

For example, when an appId is included in an RTP packet with a given SSRC,
and the appId is matched within the SDP, that RTP stream continues to be
processed as if contained the appId, even when the appId is no longer
present in the RTP packets. 

1. RTP packet 1 arrives with appId="foo" and SSRC=1. 

2. RTP packet 2 arrives with appId="bar" and SSRC=1.

3. RTP packet 3 arrives with no appId and SSRC=1.  Is it processed as though
it contained "foo" or "bar"?  Inquiring minds want to know :)

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Apr 2014 10:49:30 +0000

Hi,

>By no semantics we meant that it is just a token with no parameters that maps the RTP stream >(packet stream) to a description in the SDP m-line.

Well, then that IS the semantics :)

> (we agreed to take out the SSRC like functionality and have it at the end of the document as issues > that we may want to address for simulcast for example)
> It addressed the cases described by Christer where the RTP arrives before the SDP answer but also > on the send direction for cases where the offerer does not know the SSRC that will be used (see for > example of the three camera case bellow)

Is there a reason why you don't call the 'appId' attribute 'send-appId' instead?

Also, assuming the previous answerer in a subsequent O/A exchange becomes the offerer, which attribute (if any) does it include in the Offer? You need to describe how a change of the Offerer/Answerer roles affect affects the usage.

Regards,

Christer

---

From: "Roni Even" <[email-masked]>
Date: Thu, 17 Apr 2014 18:25:30 +0300

Hi,

Inline

Roni

From: Christer Holmberg [mailto:[email-masked]] 
Sent: 17 April, 2014 1:50 PM
To: Roni Even; 'Bernard Aboba'; [email-masked]
Cc: 'Jonathan Lennox'
Subject: RE: [MMUSIC] New Version Notification for
draft-even-mmusic-application-token-03.txt

Hi,

>By no semantics we meant that it is just a token with no parameters that
maps the RTP stream >(packet stream) to a description in the SDP m-line.

> (we agreed to take out the SSRC like functionality and have it at the end
of the document as issues > that we may want to address for simulcast for
example)

> It addressed the cases described by Christer where the RTP arrives before
the SDP answer but also > on the send direction for cases where the offerer
does not know the SSRC that will be used (see for > example of the three
camera case bellow)

Is there a reason why you don't call the 'appId' attribute 'send-appId'
instead?

[Roni Even] No reason and we may have a different name for appId, was
discussed on the list. We assume appId is sent-appId

Also, assuming the previous answerer in a subsequent O/A exchange becomes
the offerer, which attribute (if any) does it include in the Offer? You need
to describe how a change of the Offerer/Answerer roles affect affects the
usage.

[Roni Even] The current text talks about having the answer use the
recv-appId as the appId. 

We need to add text about subsequent offer/answer, do we mandate keeping
current appId.

Other issue we have is if we need to send appId (send-appId) or can only
send the recv-appId

Regards,

Christer