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

[Henk Hesselink]

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,
>