On Tue, Apr 6, 2010 at 12:28 PM, JOLY, ROBERT (ROBERT) <[email protected]> wrote: >> Attached is a sip trace (from QA) for a call hold ( with MOH) >> and resume operation which results in no voice path after >> resume. Problem reported is that after the call resume there >> is no media path. Looking at the pcap, the ITSP sends G729 >> whereas sipx sends the ITSP G711 ( asymmetric meida ). >> >> Note that on the re-INVITE (with SDP), sipX sends the ITSP >> all supported codecs (including G729 - I need to filter this >> out but that is a different problem ). The phone selects G711 >> and ITSP sends in >> G711 in the period of time following Frame 46. This is legal >> ( the ITSP answered with G711 and G729) However, it appears >> that the asymmetry of the media stream causes the observed >> problem of no speech path. So there appears to be an ITSP >> issue at hand. >> >> The asymmetric codec problem can be resolved again by >> sipxbridge restricting all re-INVITEs responses to to that >> codec negotiated for the FIRST call setup. This seems quite >> restrictive however and clearly the RFC allows for multiple >> codecs in the response to that re-INVITE but there is no >> speech path. So I am wondering if I should implement a single >> codec restriction on the re-INVITE response to avoid the situation. > > One possible approach that would less restrictive would be for the sipXbridge > to implement the codec lockdown procedure described in RFC3264 section 10.2 > when it sees an SDP containing for than 1 codec.
Thanks but I am not sure I follow. I would have thought that the codec lockdown is upto the endpoints ( in this case the ITSP and the phone ). Why would sipxbridge need to take an active part other than to relay the signaling? Regards, Ranga -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
