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
