[OpenSIPS-Users] multiple use_media_proxy() calls

[Jeff Pyle]

Dan,

On 1/25/11 1:39 AM, "Dan Pascu" <dan at ag-projects.com> wrote:

>
>On 21 Jan 2011, at 18:32, Jeff Pyle wrote:
>
>> Dan,
>> 
>> Brett and I communicated privately.  It turns out the majority of both
>>our headaches with this issue is from the same, rather large carrier.
>>Does anything come to mind on how we might handle it?
>> 
>> I'd love an option I could include in engage_media_proxy to tell it to
>>immediately set up the conntrack rules using the ports in the SDP rather
>>than try to detect the ports on the fly.
>
>This can be automated as described in the previous message so both
>automatic detection and preferring SDP addresses can coexist.

I understand conceptually, although unfortunately for me I do not have the
knowledge to make it happen.  I'll see if I can find some help.

>
>> 
>> Or, perhaps something already available in the code to force a reset of
>>some sorts when the 18x w/ SDP message comes back?  By this point, the
>>leaky media has stopped and the legit media is flowing.
>
>I don't think this is your case, because the relay already handles this.
>it will reset it's knowledge of the learnt addresses with every
>request/reply in dialog. So when the 2nd 183 comes in, it does reset the
>ports and attempts to relearn them. If things would be as you describe
>them (1st media stream has stopped when the 2nd 183 comes), then it
>should simply work because the relay would reset and learn the ports from
>the 2nd media stream. But I suspect that the 1st media stream still flows
>a bit past the 2nd 183 and the relay locks onto that again instead of
>locking on the 2nd media stream (that probably comes only after it
>re-locked to the 1st). Otherwise I cannot explain why it wouldn't work
>for you as the relay relearns the addresses after every 183/200

Here's the thing:  there is only one 183, not two.

The carrier sends only a 100, then some of this "leaky" media as I am
calling it.  I think the term "leaky" fits because it arrives outside of
any SDP.  The relay locks onto this media.  By the time the carrier does
send the 183 (and SDP), the leaky media has stopped and the legit media
has started.  But, since there is only one 183, it appears the relay
doesn't have an opportunity to reset.  There is only one stream at a time.

We have examined the Mediaproxy accounting records after the fact.  They
show the port on the carrier-side as the one from the leaky media, not the
one from the SDP.  For some reason the relay does not reset at 200 OK time.

This is on Mediaproxy 2.3.8, as far as we can go on CentOS with the Python
package limitations.  I am rebuilding into Debian Lenny with Opensips 1.6
and Mediaproxy 2.4 from the package repositories.  Perhaps we will see a
different behavior with more current versions.


- Jeff



>
>--
>Dan