Hi Henk, On 7/3/10 12:37 AM, Henk Hesselink wrote: > We're running up against a problem where engage_media_proxy seems to > handle multiple branches to the same endpoint incorrectly. We've been > getting sporadic cases of no audio and we can now reproduce it. This > is the simplest setup where it happens: > > R > | > A ----- P ----- D ----- T > | > M > > A = Asterisk > P = proxy (OpenSIPS) > R = registrar (OpenSIPS) > D = dispatcher (OpenSIPS) > M = Mediaproxy > T = phone > > What happens is: > > 1. the phone is unplugged (so can't unregister) > 2. the phone is plugged in again and registers - there are now 2 entries > in the location table until the old registration expires > 3. a call is made from Asterisk to the phone > 4. the lookup() in the proxy results in 2 branches > 5. both INVITE branches are sent to the dispatcher > 6. both result in a call to engage_media_proxy() > 7. both INVITE branches are forwarded to the phone > 8. the phone responds to one branch with > a. "482 Loop Detected" > and the other with > b. "180 Ringing" and then "200 OK" with an SDP payload > > If the dispatcher receives the 482 response before the 180/200 then the > SDP payload in the OK is for a different (new) mediaproxy session and we > get no audio. What it looks like is happening is that the 482 response > causes the original mediaproxy session for all branches to terminate. > > This doesn't seem correct behaviour to us, or is it correct and should > we be handling it in one of the configs? We currently have a workaround > where we regularly flush old duplicate registrations, but it seems like > that shouldn't be necessary.
I may need some confirmation on this from Bogdan, but I think your problem here has to do with the actual lack of support for early dialogs in the dialog module IIRC. There was a long thread discussing this: http://www.openser.org/pipermail/devel/2009-August/003806.html but I'n not sure of what got finally implemented or if it was left for the 2.0 version. If I'm not mistaken, then this is a situation that currently we can't deal with. In order to solve it, you may use the separate functions for doing the nat traversal: use_media_proxy and end_media_session. Those functions don't use the dialog module, so are not affected by this issue. Kind regards, -- Saúl Ibarra Corretgé AG Projects _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
