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

[Ingemar Johansson S <[e-mail]>]

Hi

Comments inline below 

I believe I will make a separate subsection to 3.2 that discuss this in detail.

The way I see it today it seems to be more clean to split the image attribute in separate send recv attributes in the answer. 

/Ingemar

-----Original Message-----
From: Robert Sparks [mailto:[e-mail]] 
Sent: den 6 december 2010 23:16
To: [e-mail]
Cc: Paul Kyzivat; Ingemar Johansson S
Subject: Re: New version of draft-ietf-mmusic-image-attributes

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.
[IJ] Agree


> 
> 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.
[IJ] Problematic one.

> 
> The third case seems to work ok. *Perhaps* this is what the paragraph is intending to recommend. Or maybe not. I'm not certain.
[IJ] Realize that I don't have anything that says whether or not it is alowed to replace a PT with * in the SDP answer, of course this is an alternative if the PT number is changed in the answer 

> 
> 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.
[IJ] This is doable and perhaps the most clean alternative ? The present syntaxt does not prevent this.

> 
> 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.
[IJ] I will add an example for this

> 
> 	Thanks,
> 	Paul