[OpenSIPS-Users] multiple use_media_proxy() calls

[Jeff Pyle]

Dan,

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

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

Interesting.  I will re-verify the leaky media has stopped before the 183
arrives.  A plausible explanation is that I am incorrect, and it is still
flowing after the 183.

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

Does this mean that it resets once on any request/reply pair, or that it
resets on each new request and each new 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.

Yes, certainly.  I'll be far enough along in the build to do that shortly.

One fine point:  We have been saying 183 throughout this entire
discussion.  That isn't accurate.  In most cases the GSX at this carrier
sends a 180 with SDP.  I bring it up only to rule out some weird
difference that may exist within Mediaproxy between a 183 and a 180 with
SDP.  An SDP is an SDP, regardless of the code it rides in on, no?


- Jeff

>
>> 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
>
>
>
>
>
>_______________________________________________
>Users mailing list
>Users at lists.opensips.org
>http://lists.opensips.org/cgi-bin/mailman/listinfo/users