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