Петр Кравченко wrote:
> В Втр, 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.
SHOULD is not MUST. There can be exceptions. The following is more
significant:
For streams marked as sendrecv in the answer,
the "m=" line MUST contain at least one codec the answerer is willing
to both send and receive, from amongst those listed in the offer.
Note that this says "codec", not "payload type number".
Paul
>>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
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Sip-implementors mailing list
>>[email protected]
>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
