You need to use ranch_route instead of route:
http://www.kamailio.net/dokuwiki/doku.php/core-cookbook:1.5.x#branch_route
And you need to call branch_route after next_gw. With lcr you don't
need to call append_branch.
Regards,
Ovidiu Sas
On Thu, Mar 26, 2009 at 4:02 AM, Ronald Voermans <r.voerm...@global-e.nl> wrote:
> Ovidiu,
>
> Thank you for your answer, and sorry if this is not the right list.
>
> One more (and last) question about it:
> Will an 'append_branch()' in the failure_route suffice for this to work?
>
> Here's my failure_route:
>
> failure_route[1]
> {
> route(21);
> if(!next_gw())
> {
> xlog("L_ERR", "Failed to select next PSTN gateway - M=$rm
> RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
> route(10);
> exit;
> }
> # Set Flag 30 to prevent adding multiple CLI-headers
> setflag(30);
> t_on_failure("1");
> route(12);
> }
>
> route[12] calls the force_rtp_proxy function.
>
> If i add append_branch() before route(12) in the failure_route, will this
> work?
>
> Thanks again,
>
> Ronald
> -----Oorspronkelijk bericht-----
> Van: users-boun...@rtpproxy.org [mailto:users-boun...@rtpproxy.org] Namens
> Ovidiu Sas
> Verzonden: woensdag 25 maart 2009 22:14
> Aan: RTPproxy Users
> Onderwerp: Re: [RTPproxy Users] Problem with next_gw and rtpproxy
>
> This is a kamailio question. You need to perform force_rtp_proxy in a
> branch route, so it will not affect the original message. Next time
> when you call next_gateway you will need to force_rtp_proxy in a
> branch route again and everything should work properly.
>
> Regards,
> Ovidiu Sas
>
> On Wed, Mar 25, 2009 at 4:49 PM, Ronald Voermans <r.voerm...@global-e.nl>
> wrote:
>> Dear Kamailio users,
>>
>> I have a problem with using rtpproxy and the next_gw function: when the
>> first gateway is for whatever reason unavailable, the next gateway is
>> selected. I use rtpproxy for all calls, so when the next gateway is
>> selected, the force_rtp_proxy function is called again.
>>
>> I use this function with the following parameters: faroc. Next to that,
>> rtpproxy is running in bridged mode, so the function also has the additional
>> parameters I or E.
>>
>> When the first gateway is available, everything goes ok. However when the
>> next gateway is selected, there are some errors in the SDP-message:
>>
>>
>> v=0.
>> o=- 104514515 104514515 IN IP4 10.254.254.110.254.254.1.
>> s=-.
>> c=IN IP4 10.254.254.110.254.254.1.
>> t=0 0.
>> m=audio 5397453976 RTP/AVP 18 0 8 100 101.
>> a=rtpmap:18 G729/8000.
>> a=fmtp:18 annexb=no
>> a=rtpmap:0 PCMU/8000.
>> a=rtpmap:8 PCMA/8000.
>> a=rtpmap:100 NSE/8000.
>> a=fmtp:100 192-193.
>> a=rtpmap:101 telephone-event/8000.
>> a=fmtp:101 0-15.
>> a=ptime:20.
>> a=sendrecv.
>> a=nortpproxy:yes.
>> a=nortpproxy:yes.
>>
>>
>> As you can see, the 'o' and 'c' line are wrong. It is not an option to
>> disable the function force_rtp_proxy again, because the other gateway can be
>> on the external interface instead of the internal (so there is a change in I
>> or E when calling force_rtp_proxy again). I tried to use the function
>> unforce_rtp_proxy in my failure_route, but this also didn't change anything.
>>
>> Thanks for your time and help!
>>
>> Regards,
>> Ronald Voermans
>> _______________________________________________
>> Users mailing list
>> Users@rtpproxy.org
>> http://lists.rtpproxy.org/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users@rtpproxy.org
> http://lists.rtpproxy.org/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users@rtpproxy.org
> http://lists.rtpproxy.org/mailman/listinfo/users
>
_______________________________________________
Users mailing list
Users@rtpproxy.org
http://lists.rtpproxy.org/mailman/listinfo/users
