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

[Saúl Ibarra Corretgé]

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

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

Can you paste some relevant of the cfg file? I'd be interested in seeing that loop and the places where you use_media_proxy and end_media_session for the INVITE requests, you can leave the replies out.

Regards,

--
Saúl Ibarra Corretgé
AG Projects