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();
}