Well, your problem seems pretty obvious. You seem to have a race condition, where the original media stream continues to flow past the 2nd 183, so even though mediaproxy resets the ports and expects to re-learn them, it will still lock to the old one as the stream continues to flow past the reset point.
Unfortunately for you, you cannot fix this with any manual use of use_media_proxy/end_media_session. engage_media_proxy is jus tan automated way to appropriately call those 2 for every message in the dialog, to release you from the need of calling them yourself on every message. Using one or another will have the same result, the only difference is that one is automated and once started cannot be stopped, while the other is manual and allows more control over starting/stopping it later after the dialog started. Fortunately for you, there is a simple solution for all this. The media relay can store the original media IP/port it received from the SDP (it may already store them, I haven't checked). Then later when it receives a packet outside of the conntrack rule that was added after locking to a stream, it can compare that address with the stored SDP address. If the new address is the same as the stored SDP address, but different from the locked address, the relay can re-trigger another reset (or simply remove the conntrack rule and add one with the SDP address). In other words, the relay should always favor media coming from the same address advertised in the SDP over the automatic discovery of the port. The fix should be simple to implement, but currently I cannot allocate time for this. If you have the knowledge or you know someone that can help, feel free to make a patch and I will include it. Otherwise it may take a while until I can get to address it. On 21 Jan 2011, at 16:42, Jeff Pyle 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" <d...@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.lar...@gmail.com> >>> Reply-To: OpenSIPS users mailling list <users@lists.opensips.org> >>> Date: Thu, 20 Jan 2011 14:54:13 -0500 >>> To: OpenSIPS users mailling list <users@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.lar...@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 <jp...@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@lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> *--*--*--*--*--* >>>> Duane >>>> *--*--*--*--*--* >>>> -- >>> >>> >>> >>> -- >>> -- >>> *--*--*--*--*--* >>> Duane >>> *--*--*--*--*--* >>> -- >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> -- >> Dan >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Dan _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
