Problem with mediaproxy/engage_media_proxy with branches to same endpoint

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem with mediaproxy/engage_media_proxy with branches to same endpoint

Henk Hesselink
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.

Regards,

Henk Hesselink


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users