> 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... _______________________________________________ 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/
