Re: [MMUSIC] New version of draft-ietf-mmusic-image-attributes

[Robert Sparks <[e-mail]>]

Thanks for the quick revision Ingemar -

I've been discussing this with Paul, and am forwarding a question from him (with his permission).
Do you think the current text explains this? If not, what can we add?


> I'm not certain I understand what the intended behavior is. Here is the key paragraph:
> 
>   Payload type number (PT):  The image attribute is bound to a specific
>      codec by means of the payload type number.  A wild card (*) can be
>      specified for the payload type number to indicate that it applies
>      to all payload types in the media description.  Several image
>      attributes can be defined for instance for different video codec
>      alternatives conditioned that the payload type number differs.
>      Note that the attribute is associated to the codec(s), for
>      instance an SDP offer may specify payload type number 101 while
>      the answer may specify 102, this may make it troublesome to
>      specify a payload type number with the 'imageattr' attribute.  The
>      only solution that works in this case is to use a wild card (*)
>      and thus specify that the image attribute applies to all codecs in
>      a media description.
> 
> Lets consider the situation when there is one PT (101) in the m-line of the offer, and the answer uses PT 102 for the same codec. Now consider the following cases:
> 
> - the offer and answer have a=imageattr: * ...
> 
> - the offer has a=imageattr: 101 ..., the answer has a=imageattr: 102...
> 
> - the offer has a=imageattr: 101, but the answer has a=imageattr: *...
> 
> - the offer has a=imageattr: 101 send ... recv ..., while the answer has
>  a=imageattr: 101 send ..., a=imageattr: 102 recv ...
> 
> In all cases the offerer will be receiving media with PT 101 and sending media with PT 102.
> 
> In the first case its clear that the imageattr applies for both sending and receiving.
> 
> But I don't know what is the intended behavior in the second case. I think the imageattr in the answer is the operable one for both sides. If its taken literally, it means the offerer will only use the imageattr when sending on 102, which it won't be doing.
> 
> The third case seems to work ok. *Perhaps* this is what the paragraph is intending to recommend. Or maybe not. I'm not certain.
> 
> The fourth case may be workable, depending on what we expect. This would require the answerer sort it all out, and reflect exactly what it will be sending on and receiving on. The offerer will then have to use that, but swap the settings for send and recv.
> 
> As I work through this here, I think that the fourth case is probably the preferred one in this case. But the doc is sorely lacking in specification for the procedures that should be used. And none of the examples show any of this.
> 
> 	Thanks,
> 	Paul