[OpenSIPS-Users] Problem with mediaproxy/engage_media_proxy with branches to same endpoint

[Saúl Ibarra Corretgé]

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