No, I think that confirms what I thought I remembered. As onfailure will use the original message, there will be parts of it you cannot change. g-)
Shaun Hofer wrote:
I found the problem, which was on the Asterisk end. As it stands, it works fine when exclude route(4) call. When I call with mediaproxy being used, I don't get any sound. From packet captures I can see RTP stream coming from Asterisk to SER machine(I assume mediaproxy). Asterisk seems to also send RTP packets to UA. Does this mean mediaproxy can't be used after failure_route or is there something else I can try ?
route[4] { # ---------------------------------------------------------- # NAT Traversal Section # ---------------------------------------------------------- if (isflagset(6) || isflagset(7) || isflagset(11)) { if (!isflagset(8)) { setflag(8); use_media_proxy(); }; }; }
route[7] { setflag(11); revert_uri(); rewritehostport("202.168.41.218:5060"); append_branch(); route(4); t_relay(); }
failure_route[1] { if (t_check_status("487")) { break; }; if (isflagset(26) && t_check_status("486")) { avp_delete("s:fwdbusy"); resetflag(26); route(7); }; if (isflagset(27) && t_check_status("408")) { avp_delete("s:fwdnoanswer"); resetflag(27); route(7); }; end_media_session(); }
mediaproxy[6335]: lookup 2fc1aa3946236d91@10.0.0.101 202.168.41.218:8672:audio 202.168.41.218 202.168.41.225 local 202.168.41.225 unknown Asterisk=20PBX=20 info=from:5002@202.168.41.225,to:5004@202.168.41.225,fromtag:a42f4694cd2519b3,totag:as1948cde3
mediaproxy[6335]: request 2fc1aa3946236d91@10.0.0.101 203.220.88.70:5522:audio 203.220.88.70 202.168.41.225 remote 202.168.41.218 remote Grandstream=20 info=from:5002@202.168.41.225,to:5004@202.168.41.225,fromtag:a42f4694cd2519b3,totag:
Thanks Shaun
On Tuesday 06 February 2007 17:37, Greger V. Teigre wrote:
Well, nothing much I can do. "whole thing broke" and "no success" are not easy to debug remotely... ;-) g-)
Shaun Hofer wrote:
I must be loosing the plot here, I tried t_relay() with no success.
-Shaun
On Monday 05 February 2007 20:00, you wrote:
Sorry I didn't catch that before, but when you add a new branch after a failure, you must call t_relay()... g-)
Shaun Hofer wrote:
I'm not entirly sure why, but when i put it into a seperate route the
whole
thing broke, I tried it with and without t_relay_to_udp and break. When I try the following, ser doesn't even send anything to Asterisk.
Any
idea's what I'm doing wrong ?
route[7] { revert_uri(); rewritehostport("202.168.41.218:5060"); append_branch(); }
failure_route[1] { if (t_check_status("487")) { break; }; if (isflagset(26) && t_check_status("486")) { avp_delete("s:fwdbusy"); resetflag(26); route(7); }; if (isflagset(27) && t_check_status("408")) { avp_delete("s:fwdnoanswer"); resetflag(27); route(7); }; end_media_session(); }
Thanks Shaun
On Thursday 01 February 2007 18:43, Greger V. Teigre wrote:
you should remove t_relay_to_udp, as well as the break and make sure that on return to failure_route you don't run more commands. g-)
Shaun Hofer wrote:
> I tried making route just to house the commands, I call for both: > route[7] { > revert_uri(); > rewritehostport("202.168.41.218:5060"); > append_branch(); > t_relay_to_udp("202.168.41.218", "5060"); > break; > } > > When I did this I found that it wouldn't work properly. I did play >
around
> > >
with
> putting something like use_mediaproxy and calling other routes but >
seemed
> like they failed to be called correctly. I'm thinking either I >
mediaproxy
> all traffic before from the start or let rtp travel directly between >
UA
> > >
and
> Asterisk. > > On Wednesday 31 January 2007 18:21, you wrote: > > > > >> You could create a route and then call the route from failure_route. >> However, I'm not sure if that will work as the INVITE was already >>
sent
>> to the UA not responding. But try. >> g-) >> >> Shaun Hofer wrote: >> >> >> >> >>> Hi, >>> >>> I wish to forward busy and no answer calls to Asterisk, and have the >>>
RTP
>>> stream go through mediaproxy. At the moment, some calls use >>>
mediaproxy
>>> >>> >>>
and
>>> some don't. If the call is not using mediaproxy to get it too. I >>>
have
>>> >>> >>> >>> > noticed > > > > >>> that I can't call use_media_proxy() from failed route. I don't want >>>
to
>>> >>> >>>
use
>>> mediaproxy for every call between UA's, if not needed. Any >>>
suggestions
>>> >>> >>>
on
>>> >>> >>> >>> > how > > > > >>> I might be able to get calls to use mediaproxy if forwarded ? >>> >>> current fail route: >>> >>> failure_route[1] { >>> if (t_check_status("487")) { >>> break; >>> }; >>> if (isflagset(26) && t_check_status("486")) { >>> avp_delete("s:fwdbusy"); >>> resetflag(26); >>> revert_uri(); >>> rewritehostport("202.168.41.218:5060"); >>> append_branch(); >>> t_relay_to_udp("202.168.41.218", "5060"); >>> break; >>> }; >>> if (isflagset(27) && t_check_status("408")) { >>> avp_delete("s:fwdnoanswer"); >>> resetflag(27); >>> revert_uri(); >>> rewritehostport("202.168.41.218:5060"); >>> append_branch(); >>> t_relay_to_udp("202.168.41.218", "5060"); >>> break; >>> }; >>> end_media_session(); >>> } >>>