[OpenSIPS-Users] doubled-up connection IP with use_media_proxy()

[Saúl Ibarra Corretgé]

On Aug 16, 2011, at 3:14 PM, Jeff Pyle wrote:

> Hi Saúl,
> 
> Correct, no SDP mangling functions in this proxy.  But in other proxies where I use engage_media_relay() I do have this:
> 
>                        # Mangle the origin if the B2B is in use
>                        if (is_dlg_flag_set("24") && search("Content-Type: application/sdp")) {
>                                subst_body('/^o=(.*) IN IP4 .*/o=\1 IN IP4 127.0.0.1/');
>                        }
> 
> This overwrites the origin line of the SDP with 127.0.0.1 in the event I'm using the B2B topology hiding scenario upstream (dialog flag 24).  It seems to work pretty well, and to the best of my knowledge I've never had a conflict with Mediaproxy.
> 
> Back to this proxy, to the issue at hand.  Here's what we've got:  The LCR engine runs and loads a carrier list.  A request_route section loads the prefs for the carrier and verifies it's viability.  Once we find a viable one, we finish up with this portion of the script:
> 
>        if ([ $avp(s:car_flags) & 128 ] && !isflagset(27)) {
>                #_#xlog("L_INFO", "Using media proxy on call to $rd - $ci\n");
>                set_dlg_flag("26");
>                use_media_proxy();
>        }
> 
>        if (![ $avp(s:car_flags) & 128 ] && is_dlg_flag_set("26")) {
>                #_#xlog("L_INFO", "Ending media session on call to $rd - $ci\n");
>                reset_dlg_flag("26");
>                end_media_session();
>        }
> 
>        if !(t_relay("0x05")) {
>                sl_reply_error();
>        }
> 
> The 128-bit of the AVP is the carrier flag indicating a media relay requirement.  Script flag 27 is set further up in the script by a check for a custom header indicating a previous proxy in the signal flow has already invoked a media relay, so we don't need to here.  I use dialog flag 26 to indicate whether the media relay has been called or not, checking for its presence in stanzas like this in the onreply_route:
> 
>        if (is_dlg_flag_set("26") && has_body("application/sdp")) {
>                #_#xlog("L_INFO", "Using media proxy in onreply_route - $ci\n");
>                use_media_proxy();
>        }
> 
> Prior to the script above the onreply_route and failure_route are armed.  The failure route will send the transaction back up to the request_route that loads the carrier info if certain response codes are received, like a 503, ultimately reaching this script again on the way out the door towards the next carrier.  This is the only place the media functions appear in the request_route.  There are no media functions in the failure_routes.  onreply_route and loose_route have items such as the one above.
> 
> If the first attempted carrier destination has the media relay 128 bit set, the call fails and is sent back around for the next carrier and this next carrier also has it set, the top stanza above will run again (intentionally) to refresh the media session.  If I do not re-run use_media_relay() on subsequent attempts requiring the relay, I get one-way audio.  Not ending the session is not enough.  In my testing it seems I have to re-run the function each time I run through the script to send to the next carrier, assuming this next carrier needs media relay.  If the next carrier does not, the second stanza hits and we close down the media session we've started during the first iteration.
> 

How do you jump from the failure route back to the request route? route(X) or are you t_relay-ing to yourself? I don't remember right now exactly to which message changes would be applied if you do stuff on the failure route.

> Everything above works okay in testing.  It's only in production do I start to see a small percentage of 400s and 488s coming back from the term carriers because of the mangled SDP lines.  I can take the call flow of one of the failed calls, duplicate it, and it will work fine.  That leads me to believe there's some sort of timing issue at work here causing the unintended SDP manglage even though I'm running only one of these functions at a time.
> 
> Does anything jump out at you?
> 

Since the routing script will be executed top to bottom, I don't see how timing could be an issue here :-S Sorry I can't be of much help here, if something comes to ming I'll come back to you.


Regards,

--
Saúl Ibarra Corretgé
AG Projects