On Tue, Apr 6, 2010 at 1:37 PM, JOLY, ROBERT (ROBERT) <[email protected]> wrote: >> 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? > > If I'm following you, your proposal already called for sipXbridge taking an > active part in the signaling by restricting the codecs in the re-INVITE > responses. What I'm suggesting here is another strategy that would be less > restrictive but indeed would require the sipXbridge to take an even more > active role in the re-INVITE call flow. I totally understand it if you judge > this approach overkill or too complicated. I threw in that idea just in > case... > Yes you are right. I have decided to not implement that either.
In the 4.2 time frame, I will just file a bug report with bandwidth.com (it appears to be a bug indeed) and perhaps can try for something more ambitious in 5.0. I believe this will not be a problem if I filter out G729 in the sdp re-offer in any case ( I should be doing that in any case because of MOH restrictions). Thanks for looking and commenting. 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/
