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

[Jeff Pyle]

This is on Opensips 1.6.4 from the opensips.org/apt repo, and Mediaproxy 2.4.4 from the AG Projects repo.

I'm still struggling with the doubled-up connection IP on a small percentage of calls with serial forking and the manual use_media_proxy() and end_media_session() functions.  I did rewrite my config to call at most one of the functions per iteration of the loop.  In testing it seems to work great, but with production traffic I see some 400s and 488s from the far-end gateways that puke on the messed up c= line I still seem to be sending from time to time.

I have to use the manual functions because some carrier destinations need relay while others cannot have it, while engage_media_proxy() wouldn't provide enough the flexibility to disable the relay.  I'm attempting to selectively enable/disable the relay prior to t_relay() in the serial forking loop.

Here are the high points of the logic:

1. Load the AVP with the list of carriers we're going to try.

2. Enter the carrier egress loop in request_route.  Look up prefs, including whether or not this carrier is enabled.  Keep looping through the carrier list AVP until we find one that is.  Just before t_relay(), look at the prefs AVP associated with the current carrier to see if this carrier needs a media relay.  If it does, set_dlg_flag("26") and use_media_proxy().  If no relay required, is_dlg_flag_set("26") from a previous iteration, and if so, end_media_session().  Then arm the appropriate relay and failure routes, and t_relay().

3. failure_route.  Check to see if it's a response code we route advance on.  If so, remove this carrier from the AVP carrier list and send it back up to step 2.

I've done my best to call at most one function on each iteration of the loop, just before t_relay() out to the carrier we're about to try.  What else might cause a doubled-up c= line if use_media_proxy/end_media_session() is called only once per iteration?

If the current carrier needs the relay, and the previous one did as well, I still call use_media_proxy() to update the session.  If the current carrier does not need a relay, I call end_media_session() only is_dlg_flag_set("26"), indicating the relay had been called during a previous iteration.

There are other use_media_relay() in the reply_route and loose_route sections; these seem to work okay.  I'm not having problems with T.38 or other reinvites mid-call, only with getting the call established in the first place with a clean c= line 100% of the time.

I looked at my CDRs from yesterday that ended in 400 or 488.  In all cases, the first carrier (who did require the relay) sent a 503 forcing a route-advance.  Only in some cases the second carrier required it.  In all cases prior to the t_relay() to the second carrier there would have been some relay operation, either use_media_proxy() to update the session or end_media_session() to close down the session altogether.  In some percentage of both cases I got a botched c= line for the second carrier attempt.

Might there be some timing issue between the various Opensips processes that cause things not to be sync'd all the time?  Maybe something odd about dialog flags in this regard?  I ask because I can take exactly the same call flow I see failed in a CDR and duplicate it with clean c= lines on each iteration, each time.

Any suggestions would be great.  I'm out of things to try!


Regards,
Jeff


On Apr 22, 2011, at 2:35 PM, Saúl Ibarra Corretgé wrote:

> 
>> So as long as I t_relay() the message between the first use() and the
>> end(), or the end() and the second use(), all will be well?
>> 
> 
> Yes, that's right.
> 
> -- 
> Saúl Ibarra Corretgé
> AG Projects