Hi Eric, On Jun 11, 2014, at 4:53 PM, Eric Tamme wrote:
> Hi Saúl, and others, > > We have discovered a bug in mediaproxy where it does not recognize an answer > that is part of a different transaction, this is caused by how mediaproxy > tracks offer/answer based on cseq. Here is the example offer answer scenario > from RFC3262 that does not work. > > UAC INVITE Cseq: 1 (no SDP offer) -> > > <- 183 with SDP offer > > PRACK CSeq: 2, Rseq: 1 with SDP answer-> > Wow, what an abomination of a use-case, I didn't know it was even possible to do that :-/ > Because the PRACK is a different transaction, and has a different CSeq than > the offer, mediaproxy assumes it is a new offer, rather than an answer. > > Can you offer any thoughts on what might be the best way to fix this issue? > We are happy to work on a patch as well - but would like to have input from > the maintainers so that we can be sure it would be accepted upstream. > The OpenSIPS mediaproxy module just takes some information and passes it to the MediaProxy dispatcher process, so the fix needs to take place in mediaproxy/mediacontrol.py, in the update_session and/or update_media functions. Let me know how that goes! Cheers, -- Saúl Ibarra Corretgé AG Projects _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
