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

[Jonathan Lennox <[e-mail]>]

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

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

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.