inline: [EMAIL PROTECTED] wrote: > > > However, I cannot see any explicit statement > > regarding the payload field in the offerer's > > RTP packets. > > And apologies again since I wrongly extrapolated that > text from the draft for the offerer too. Your theory > seems to be correct regarding the offerer. > > A more detailed study and I found the following text > in Page 6 (section 5.1) of the offer/answer-02 draft: > > "For sendrecv RTP streams, the payload type numbers > indicate the value of the payload type field the > offerer expects to receive, and would prefer to send. > ^^^^^^ > 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, .... that would be the right thing to do. Each person > MUST use the payload numbers that the other party wants to > see in the RTP payload.
Correct. This was a late change to offer/answer, which for a long time always used the same dynamic PT value in the offer and answer. It was changed because of issues with H.323 interop, which do allow for different dynamic PT in both directions. > > I (as the offerer) want to see 119 in whatever RTP I receive > so I give that in the SDP and you MUST use 119 in the RTP packet. > You, on the other hand, want to see 97 in your RTP payload, > so you send 97 in the answer SDP and I MUST use 97 for the > RTP payload. Right. > > Everyone would be happy then and get to see what they want > to see ;) I think I got it right this time (finally :) Yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
