[OpenSIPS-Users] Engage media proxy corrupts sdp c= when dynamic routing

[Charles Solar]

Hi brian, I think I agree, we found this post (
http://www.mail-archive.com/users@lists.opensips.org/msg03093.html) which
mentions that failure route and branch route will be called on a failure.
I suspect that mech underneath engage_media_proxy is modifying SDP c= in
failure and branch.
I may switch to using use/end mediaproxy, but if that is the case, I figure
it may be easy enough to fix in the module itself.  So I will look there
first and see if I can't make up a patch.

Charles

On Fri, Feb 10, 2012 at 4:33 PM, Brian ipt <voiplists at iptel.co> wrote:

>
>
> On Fri, Feb 10, 2012 at 10:01 PM, Charles Solar <charlessolar at gmail.com>wrote:
>
>> Definitely not - I know there was a lengthy discussion about calling
>> use_media_proxy twice and that function a while ago.  The only thing I do
>> with a natted invite is this:
>>
>> # NAT test
>>         if( is_method("INVITE") && !has_totag() )
>>         {
>>                 $avp(can_uri) = $ru;
>>
>>                 setflag(3); # flag for NAT
>>                 force_rport();
>>                 fix_contact();
>>                 append_hf("P-hint: NAT\r\n");
>>                 xlog( "L_INFO", "Engaging media proxy" );
>>                 engage_media_proxy();
>>         }
>>
>> Charles
>>
>>
> Sorry not to be more helpful and you as you say in your mail it does look
> like a bug, engage_media_proxy is using dialog and when you failover
> mediaproxy module is modifying SDP incorrectly for the second time..
>
> use use_media_proxy and end_media_sessions to get around this for the
> moment.
>
>
>
>>
>> On Fri, Feb 10, 2012 at 3:54 PM, Brian ipt <voiplists at iptel.co> wrote:
>>
>>>
>>>
>>> On Fri, Feb 10, 2012 at 9:21 PM, Charles Solar <charlessolar at gmail.com>wrote:
>>>
>>>> I have been using engage_media_proxy in my script, but it seems to
>>>> cause problems when I failover in the dynamic routing module.
>>>> This is the scenario:
>>>>
>>>> 1. Incoming call
>>>> 2. Engage media proxy
>>>> 3. Try first GW (which is down)
>>>> 4. Failure route
>>>> 5. Try next GW
>>>> 6. Next GW sends Session progress & invite
>>>> 7. Media proxy module 'fixes' my SDP contact twice
>>>>
>>>> My SIP message end up with duplicated SDP contact info.  For example:c=IN IP4 33.66.22.1133.66.22.11
>>>>
>>>> If the first gateway works, this does not happen.  In fact it works
>>>> perfectly.  But I guess engage_media_proxy or the dialog module is having
>>>> an issue with a failure scenario?
>>>>
>>>> My failure route is pretty simple:
>>>>
>>>> failure_route[4] {
>>>>         xlog("L_INFO", "Failure Route: $rm,  $fu,  $ru\n");
>>>>
>>>>         if (use_next_gw()) {
>>>>                 xlog("L_INFO", "Trying next gateway" );
>>>>                 t_relay();
>>>>                 exit;
>>>>         } else {
>>>>                 xlog( "L_INFO", "Exhausted gateway list" );
>>>>                 t_reply ("503", "Service not available");
>>>>                 exit;
>>>>         }
>>>> }
>>>>
>>>> Should I switch to use_media_proxy/end_media_session if I want to
>>>> expect failovers?  Or could I be doing something wrong?
>>>>
>>>> Thanks guys
>>>> Charles
>>>>
>>>
>>>
>>>
>>> Hi Charles,
>>>
>>> Are you using fix_nated_sdp anywhere in your scripts or using anything
>>> else that modifies the SDP?
>>>
>>> Brian
>>>
>>>
>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120210/3d5ccc85/attachment.htm>