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