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
