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