[OpenSIPS-Users] multiple use_media_proxy() calls

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

Dan,

As I re-read this, I should clarify one point:

  "...I think we're going to have to find a way to accommodate it."

I was referring to my team and I, not you.  You don't "have" to do
anything.  :)


- Jeff


On 1/21/11 9:42 AM, "Jeff Pyle" <jpyle at fidelityvoice.com> wrote:

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

More information about the Users mailing list