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

[Jeff Pyle]

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?


- Jeff


On Aug 15, 2011, at 1:47 PM, Jeff Pyle wrote:

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