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

[Christer Holmberg <[e-mail]>]

Hi,

>> When we discussed payload type mappings and RTP sessions, it was said that, in a sendonly m- line, the payload 
>> type values are simply "place holders", the remote endpoint will tell you what values it want to receive.
>>
>> So, in your case, you can't say "I am going to send you with PT 100". The answerer is going to say what it wants 
>> >> to receive, so in your case it may e.g. chose 98 for alice-audio and 99 for bob-audio.
>
> So I tell you that I will send N codecs with SSRC 1234 and you tell me which payload I should use. This makes no sense IMHO. SDP was designed for 1-to-1 symmetric (audio) streams.

Section 5.1 of RFC 3264 says:

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

> When it comes to multi-stream (I send my audio and video and receive multiple audio and video streams from others) SDP becomes a nightmare.

SDP Offer/Answer has been a nightmare from day one :)

Regards,

Christer