[OpenSIPS-Users] multiple use_media_proxy() calls

[Dan Pascu]

On 25 Jan 2011, at 15:35, Jeff Pyle wrote:

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

Then there is some misunderstanding somewhere. Before the first 183 arrives, mediaproxy cannot lock onto anything as it doesn't yet have information about both endpoints. It needs a request (INVITE) and a reply that carries media (183/200), before it can even begin to listen to packets. So how can it lock to media before even allocating the ports and listening is beyond me.

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

I checked the code and it does reset on any new request/reply.

> 
> This is on Mediaproxy 2.3.8, as far as we can go on CentOS with the Python

Hmm, I really can't recall if that version had this ability or not. I suggest you try the latest version and see if it fixes your problem.

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

--
Dan