В Втр, 28/03/2006 в 14:12 +0200, Erez Morabia пишет: the key words you need from RFC3264 are "that same payload type number SHOULD be used for that codec in the answer". Thus, the answer is incorrect.
> Hi, > > Offer: > > m=audio 4321 RTP/AVP 0 96 > > a=rtpmap:96 telephone-event/8000 > > > > Answer: > > m=audio 1234 RTP/AVP 0 101 > > a=rtpmap:101 telephone-event/8000 > > > > RFC3264: > > 1. The stream MAY indicate additional media formats, not listed in the > corresponding stream in the offer, that the answerer is willing to send > or receive (of course, it will not be able to send them at this time, > since it was not listed in the offer). > 2. In the case of RTP, if a particular codec was referenced with a > specific payload type number in the offer, that same payload type number > SHOULD be used for that codec in the answer. Even if the same payload > type number is used, the answer MUST contain rtpmap attributes to define > the payload type mappings for dynamic payload types, and SHOULD contain > mappings for static payload types. > > > > As far as I understand from RFC3264, the answer is valid, but it is a > bit problematic. > > The offer-UA is willing to send/recv telephone-event stream with payload > 96. > > The answer-UA is willing to send/recv telephone-event stream with > payload 101. > > Does it mean that the answer-UA actually rejected the telephone-event > media format? > > > > Thanks, > > Erez > > > > > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Кравченко Петр Геннадьевич НПП "СпецСтрой Связь", НТЦ, разработчик Тел. +7(8634)311562 доп 225 mailto: [EMAIL PROTECTED]
_______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
