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.
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?
- Jeff
On Aug 16, 2011, at 4:16 AM, Saúl Ibarra Corretgé wrote:
>
> On Aug 16, 2011, at 9:40 AM, Saúl Ibarra Corretgé wrote:
>
>> Hi Jeff,
>>
>> On Aug 16, 2011, at 2:42 AM, Jeff Pyle wrote:
>>
>>> Ok, so maybe this was a bit much. I'll simply the question:
>>>
>>> Other than calling use_media_proxy() / end_media_session() more than once
>>> in a script, what could cause the c= line of the SDP to have the address of
>>> the media relay listed twice?
>>>
>>
>> Nobody else is mangling that line but MediaProxy (unless you are using
>> another relaying module).
>>
>
> Just to clarify, you are not mixing SDP mangling functions with mediaproxy
> functions, right?
>
> --
> Saúl Ibarra Corretgé
> AG Projects
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
