Like to note that SDP in H.248 allows to support asymmetric media formats (and thus direction-individual codec types), due to local and remote specific media control.
Thus, an H.248 media endpoint could support asymmetric codecs with SIP UAs. Of course, this doesn't solve your problem with SIP/SDP ... Albrecht > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Klaus Darilion > Sent: Mittwoch, 25. Februar 2009 13:49 > To: Iñaki Baz Castillo > Cc: sip-implementors > Subject: Re: [Sip-implementors] asymmetric audio codecs > > > > Iñaki Baz Castillo schrieb: > > 2009/2/25 Klaus Darilion <[email protected]>: > >> I think if Alice announces G711 and G729, and Bob answers > with G.729, > >> Alice must send with G729 and Bob can send with G711 too. > Is this correct? > > > > If Bob answers G729 then Alice expects that Bob will send G729. > > I wonder why? If I offer somebody to talk to me in English or > German, I have to be prepared to receive English or German, > even if I started talking in German. > > Thus from a logical point of view, all the offered codecs > should be supported. If the device supports only a single on > at the time, it can send reINVITE with a single offer to lock > down on a single codec. > > > > But if Bob sends G711, how will detect Alice that the > incoming RTP is not G729? > > There is the payloadtype field in the RTP header. So it is > easy to differ them. > > klaus > > > > The negoziation is supposed to have place during the SDP > exchange and > > it must be deterministic, am I wrong? > > > _______________________________________________ > 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
