Re: [MMUSIC] BUNDLE: no reason por payload type to be unique within bundled m= lines

[Christer Holmberg <[e-mail]>]

Hi,

>>    "For sendonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets
>>    the offerer is planning to send for that codec."
>>
>> ...followed by:
>>
>>    "However, for sendonly and sendrecv streams, the answer might indicate
>>    different payload type numbers for the same codecs, in which case,
>>    the offerer MUST send with the payload type numbers from the answer."
>>
>> So, for sendonly, the offerer can indicate the values it is "planning" to use, but the answerer will have the final say.
>
>OK. But what would happen when such a a=sendrecv becomes a=sendonly and later a=recvonly (due "hold" feature for example)? 
>Also note that, depending who sends the re-offer, payload types may have to change within the same RTP "session".

If I could decide, endpoints would always indicate what they want to receive - even if they don't intend to receive anything (in case of inactive or sendonly).

Then, when/if you change the direction, the negotiation is already done, and you can start send/receive based on what you previously negotiated.

But, to answer your question: I don't see what the problem is. If there is an O/A where you will start receiving media, you will simply indicate what PTs you want to receive.

Regards,

Christer




--
Iñaki Baz Castillo
<[e-mail]>