Hi Saúl, Thanks, I hadn't seen that thread and it does seem to be the problem. I guess we'll go with the separate start/end mediaproxy functions.
Regards, Henk Hesselink Saúl Ibarra Corretgé wrote: > 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, > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
