[OpenSIPS-Users] multiple use_media_proxy() calls

Jeff Pyle jpyle at fidelityvoice.com
Fri Jan 21 15:42:29 CET 2011 

Dan,

Excellent info.

Here's the call flow I'm having trouble with:

- INVITE from Opensips to carrier (Sonus GSX), mediaproxy previously
engaged.
- GSX fires back 100.
- GSX tries a route on SS7 to terminate the call.
- Some media comes from the GSX on port, say, 16400 as a function of this
first termination attempt.
- Mediaproxy sees this RTP and locks onto it.
- GSX's primary SS7 route fails, so he tries a second one.
- This route is good, and the GSX relays back a 183 w/ SDP, indicating
port 16800.
- Media begins to flow from the GSX on port 16800, but it's too late
because the relay has locked onto the "leaky" media on port 16400.  And
the call is shot.

I went rounds with the carrier for quite a while on this.  I think they
tried for a while to see what they could do, but ended up citing a part of
an RFC I can't find at the moment that says a UAC should ignore any media
not defined in the SDP.  Mediaproxy isn't doing that, so as far as they
are concerned the case is closed because my UAC is broken.

I have no practical experience yet with the manual
use_media_proxy/end_media_proxy calls; I've used only engage_media_proxy.
I would not try to mix them (I know that's a no-no).  My hope was to try
to find a combination with the manual commands above and beyond what the
automatic engage'r could do.

Can you think of a way I could handle this scenario either with
engage_media_proxy or with use_media_proxy/end_media_proxy?  Much to my
chagrin I've seen a few more carriers exhibit this type of behavior.  One
way or another I think we're going to have to find a way to accommodate
it.  


- Jeff


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

>Unfortunately for you this will not work, for 3 reasons.
>
>1. engage_media_proxy already calls use_media_proxy for every message in
>the dialog, so by manually calling use_media_proxy on a certain message
>you do not change the conditions of the problem, as engage_media_proxy
>already called it for that message by using dialog hooks. You will only
>end up calling it twice which doesn't help, on the contrary (see point
>2). Also every time a new message is received in dialog and forwarded to
>mediaproxy for processing, mediaproxy will reset it's known expected
>ports and re-learn them when it receives the next media packet from
>endpoints.
>
>2. by calling use_media_proxy twice, the 2nd call won't overwrite the
>previous value. Unfortunately, this is not a mediaproxy issue, is a
>generic opensips issue that results from the way changes are applied to
>the existing message using lumps. Any other opensips function that
>modifies the message, if called twice will corrupt the message by
>appending each change after each other, instead of overwriting the
>previous one. So in case of mediaproxy you will see 2 IP addresses
>concatenated like: xx.xx.xx.xxyy.yy.yy.yy where the IP address was
>replaced.
>
>3. You cannot mix engage_media_proxy with
>use_media_proxy/end_media_session (this is clearly mentioned in the
>docs). If you start the call with engage_media_proxy and later expect to
>call end_media_session to end it and start using use_media_proxy it won't
>work. It will remove the session from the media relay, but it will not
>reset the dialog callbacks, which means that the dialog module will keep
>calling the callbacks that the original engage_media_proxy triggered. So
>while the session may be gone from the relay, the next message that
>triggers a dialog callback will attempt to add it back, however
>considering that half of the original information about the call was lost
>in the relay when the session was removed, it will not be able to restore
>the session anymore and you'll end up with a corrupted state and things
>won't work. You need go decide early which mechanism to use and stick
>with that for that call.
>
>In the end I really don't understand why you think all these things will
>help. mediaproxy is already prepared for IP/port changes following a SIP
>request/reply. So when a new request/reply is received and forwarded to
>mediaproxy, it will reset the ports it learned and allow them to change.
>Then the first media packets it receives after a SIP message will make it
>learn the new IP/ports for the media streams. This is already done as it
>is necessary for it to work (think about starting media when a 183 is
>received, but later some other endpoint answers the call with a 200 OK
>and media will come from a different device than the early media).
>mediaproy can handle this right now and what you describe doesn't sound
>different, with the only exception that it looks like a buggy behavior,
>not something that resulted from a normal call flow.
>
>On 20 Jan 2011, at 22:13, Jeff Pyle wrote:
>
>> Yikes.  Good to know; thanks.
>> 
>> Here's the issue.  Today I use media relay in limited cases, only when
>>I have to have it for internal network reasons.  Long story, but if I
>>don't use it, QoS doesn't happen right.  Anyway, it's about 1% of total
>>traffic.  No big deal.
>> 
>> I've had no issues with the dialog module over the last 2 years or so.
>>(Counting blessingsŠ)  As such, I use the engage_media_proxy() command.
>>It works ‹ most of the time.  Unless an upstream carrier lets some media
>>"leak" through outside of the ports indicated in the SDP that hasn't
>>arrived yet.  The relay locks onto the wrong ports, and we get one-way
>>or no-way audio.
>> 
>> This happens in one particular carrier's case when they route-advance
>>on SS7 behind the scenes as a function of their Sonus GSX.  They can't
>>tell me why any media comes through at all on the first (disregarded)
>>route.  But, the SDPs they send do have the correct ports for the second
>>(utilized) route.  This SDP comes after the leaky media.  Mediaproxy,
>>being primarily a NAT traversal mechanism, listens more to what's really
>>happening on the network rather than what's happening in the SDP.
>> 
>> And now the part I haven't researched fully.  I'm hoping to be able to
>>"reset" the media relay with an end_media_session() then
>>use_media_relay() in an onreply_route to force a port re-detection in
>>the relay when the 180 w/ SDP comes through (after the incorrect media
>>dribble has completed), and ultimately the 200 OK.  I may break more
>>than I fix with this.  Time will tell.
>> 
>> If this or something like it works, I'll be able to use the relays
>>more.  Which is something I'd like to do ­ mostly for accounting.
>> 
>> 
>> - Jeff
>> 
>> From: Duane Larson <duane.larson at gmail.com>
>> Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
>> Date: Thu, 20 Jan 2011 14:54:13 -0500
>> To: OpenSIPS users mailling list <users at lists.opensips.org>
>> Subject: Re: [OpenSIPS-Users] multiple use_media_proxy() calls
>> 
>> accidentally called twice in a script that is...
>> 
>> On Thu, Jan 20, 2011 at 1:53 PM, Duane Larson <duane.larson at gmail.com>
>>wrote:
>>> I think I have accidentally called use_media_proxy() in scripts and it
>>>has spit out syslog errors.  I think it caused one way audio issues for
>>>me.
>>> 
>>> On Thu, Jan 20, 2011 at 1:31 PM, Jeff Pyle <jpyle at fidelityvoice.com>
>>>wrote:
>>>> Hello,
>>>> 
>>>> What would happen if use_media_proxy() were called on a transaction
>>>>(or dialog) where it had already been used?  The documented result
>>>>codes don't cover this case.
>>>> 
>>>> Would it simply start a new session with the dispatcher and close any
>>>>previous ones, modifying the SDP again?  Or error out perhaps?
>>>> 
>>>> 
>>>> 
>>>> Regards,
>>>> Jeff
>>>> 
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> --
>>> *--*--*--*--*--*
>>> Duane
>>> *--*--*--*--*--*
>>> --
>> 
>> 
>> 
>> -- 
>> --
>> *--*--*--*--*--*
>> Duane
>> *--*--*--*--*--*
>> --
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>--
>Dan
>
>
>
>
>
>_______________________________________________
>Users mailing list
>Users at lists.opensips.org
>http://lists.opensips.org/cgi-bin/mailman/listinfo/users

More information about the Users mailing list