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

[Jeff Pyle]

Hi Saúl,


On Aug 17, 2011, at 3:32 AM, Saúl Ibarra Corretgé wrote:

> 
> 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.

With a route[x] statement.  I had some of these functions occurring at the failure route, but I had the same issues.  I tried to simply things by having everything happen at the same place, in this case, in the request_route just prior to the t_relay out to the carrier.

>> 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.

My thought on timing was items not being updated between Opensips processes, or perhaps within the dispatcher itself.  I have a fresh 400 example in front of me where the first carrier attempt required media relay, returned a 503, so we looped around to the second carrier attempt, also requiring a media relay.  If that execution of use_media_relay caused another session to be generated somewhere, instead of updating the original one from the previous carrier attempt, I can see where it might cause this symptom where it appears the function was called twice.  Or am I barking up the wrong tree?


- Jeff


> 
> Regards,
> 
> --
> Saúl Ibarra Corretgé
> AG Projects
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users