Iñaki Baz Castillo wrote:
> El Miércoles, 25 de Febrero de 2009, Maxim Sobolev escribió:
>>> Yes, this is the point. Are you sure that devices check that payload
>>> type? or do they assume they will receive the codec negociated in the
>>> SDP?
>> Yes they do. Mixing several payload types within one RTP sessions is
>> common practice - one payload type for actual audio grames, another for
>> DTMF packets and third one for comfort noise frames when VAD is enabled.
>
> Yes, but all these payloads have been previously negociated in the SDP. The
> original question was:
>
> - Alice sends a SDP with G729 and G711.
> - Bob replies a SDP with G729.
> - Bob sends RTP in G711.
>
> Even if Alice suppors G711, this codec was no negociated during SDP exchange.
My point it that device have to check payload type to work properly even
if no "asymmetric" codecs are present.
For some reason you think that the SDP delivered by the Bob to Alice
should somehow affect selection of codecs available for Bob to use when
sending to Alice, but I cannot find any place in the standard where it's
required.
On contrary, I believe that the SDP RFC (4566) explicitly permits
asymmetric sessions:
<quote>
sub-fields contain RTP payload type numbers. _When a list of
payload type numbers is given, this implies that all of these
payload formats MAY be used in the session, but the first of these
formats SHOULD be used as the default format for the session._
</quote>
Which to me means that if Alice announces G729 and G711 in its SDP it
should be prepared to receive both G729 and G711. If it wants to ensure
that only G729 is used after seeing Bob's SDP it should use re-INVITE on
its own.
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/F: +1-646-651-1110
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
