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