lucas@cyneric.com wrote:

...

If I try to receive a call from the PSTN, trough my Gateway, I only have a one-way audio communication, but only in the SIP->PSTN direction. What could this be?.

Is the mediaproxy being used at all in this scenario? From your description it looks like it is not.

Yes, it is running. I can see it with a ps -aux, and it is well configured in my ser.cfg

In fact:

- If I have to UAs, both behind same (linux-iptables) nat, I have a two-way audio communication, with nice quality, with no problems at all. - If I place a call to the PSTN, trough my Gateway, from my UA, I have a two-way audio communication, with nice quality, with no problems at all.

But ...

- If I try to receive a call from the PSTN, trough my Gateway, I only have a one-way audio communication, but only in the SIP->PSTN direction.

look at what session.py showed when making calls from the pstn ...

Caller Via Called Status Duration Codec Type Traffic ------------------------------------------------------------------------ --------------------------- IP_CISCO:20482 - ip_mediaproxy:35234 - ?.?.?.?:? inactive 1'04" G729 Audio 11.29k/0/0

In some way, it cannot get the IP address of my UA ... and I do not why. The intereseting sing is that signalling gets completed, because my UA receives the last ACK ( from the proxy ) and starts sending RTP, but to the Gateway instead of sending it to the mediaproxy. Look at some tcpduming obtained at the UA (behind nat) ...

- tcpdumping RTP on the UA (private IP:192.168.1.185.15090)

20:36:37.596851 192.168.1.185.15090 > IP_CISCO.20482: udp 32

Do you see? It sends RTP packets to the IP:PORT of my cisco ...

And, lastly, if you see the active calls at the cisco, you'll see the following ...

- show call active voice brief

2D2B : 104269100hs.1 +273 pid:1991334 Originate 1991015 active dur 00:00:36 tx:162/3202 rx:1790/35800 IP ip_ser_mediaproxy:35234 rtt:0ms pl:33170/140ms lost:0/0/0 delay:69/69/70ms g729r8

So the cisco is communicating in a nice way with the proxy, but the proxy is not forwarding any rtp traffic to my UA.

Ideas ??

Best regards,

Lucas

...

Yes, it is running. I can see it with a ps -aux, and it is well configured in my ser.cfg

There is some kind of web interface for mediaproxy. Are you using it? If yes, do you see traffic going both ways? I suspect it is not.

No, there is only traffic in the direction SIP->PSTN. I'm not using the web interface, but instead the shell command session.py

This is what it shows ... ( for the case when I call from PSTN-to-SIP )

Total traffic: 20.48kbps/0bps/0bps (in1/in2/out) Session count: 1

Thanx!

Regards,

Lucas

...

No, there is only traffic in the direction SIP->PSTN. I'm not using the web interface, but instead the shell command session.py

This is what it shows ... ( for the case when I call from PSTN-to-SIP )

Total traffic: 20.48kbps/0bps/0bps (in1/in2/out) Session count: 1

I think you need to look into your ser.cfg; it looks to me like you are proxying calls only when they originate from NAT -> non-nat and not from non-natted endpoints -> NAT.

I know that, I could tell from when UA sends rtp traffic directly to the Gateway instead of sending it to the proxy. Is there something in the sip/sdp headers that tells the proxy from where to get the IP of my UA, so to be able to proxy the call ? Or, in other words, Why should calls coming in from the pstn not be proxied ?

Here goes my ser, may be you can see something I'm not seeing ...

debug=3 # debug level (cmd line: -dddddddddd) fork=no log_stderror=yes # (cmd line: -E)

check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R)

fifo="/tmp/ser_fifo"

server_signature=no

# ------------------ module loading ----------------------------------

loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/textops.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/uri.so"

# NAT STUFF loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/mediaproxy.so" loadmodule "/usr/local/lib/ser/modules/nathelper.so"

# ----------------- setting module-specific parameters ---------------

modparam("usrloc", "db_mode", 0) modparam("registrar", "use_domain", 0) modparam("rr", "enable_full_lr", 1)

# -- NAT STUFF PARAMS -- modparam("nathelper", "rtpproxy_disable", 1) modparam("nathelper", "natping_interval", 0)

modparam("mediaproxy", "natping_interval", 30) modparam("mediaproxy", "sip_asymmetrics", "/usr/local/etc/ser/sip-asymmetric-clients") modparam("mediaproxy", "rtp_asymmetrics", "/usr/local/etc/ser/rtp-asymmetric-clients")

modparam("registrar", "nat_flag", 6)

# main routing logic

route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; }; if (method=="INVITE" && client_nat_test("3")) { log(1, " -- INVITE and client_nat_test(3) --\n"); record_route_preset("208.221.169.88:5060;nat=yes"); # insert IP address } else if (!method=="REGISTER") { record_route(); };

if (method=="BYE" || method=="CANCEL") { log(1, " -- BYE or CANCEL: Media Proxy -- \n"); end_media_session(); };

if (loose_route()) { if (has_totag() && method=="INVITE") { if (client_nat_test("3") || search("^Route:.*;nat=yes")) { setflag(6); use_media_proxy(); }; }; # mark routing logic in request route(1); break; };

if (!uri==myself) { route(1); break; };

if (uri==myself) { if (method=="INVITE") { route(3); break; } else if (method=="REGISTER") { route(2); break; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found"); break; }; route(1); }; }

route[1] { log(1, " | route[1] entered |\n");

t_on_reply("1");

if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; }

route[2] { log(1, " | route[2] entered |\n");

if (!search("^Contact: *") && client_nat_test("7")) { setflag(6); fix_nated_register(); force_rport(); };

if (!save("location")) { sl_reply_error(); };

}

route[3] { log(1, " | route[3] entered |\n");

if (client_nat_test("3")) { setflag(7); force_rport(); fix_nated_contact(); };

if (!lookup("location")) { if (src_ip==IP_SNOM_PROXY) { sl_send_reply("404", "User Not Found"); break; };

log(1, " -- Reenviando a SIP Proxy SNOM -- \n"); rewritehostport("GATEWAY:5060");

};

if (isflagset(6) || isflagset(7)) { use_media_proxy(); };

route(1);

}

onreply_route[1] { log(1, " +--------------------------+\n"); log(1, " | onreply_route[1] entered |\n"); log(1, " +--------------------------+\n");

if(status=~"486") { log(1, " -- 486 -> BUSY --\n"); };

if(status=~"404") { log(1, " -- 404 -> NOT REGISTERED --\n"); };

if(status=~"180") { log(1, " -- 180 -> RINGING --\n"); };

if(status=~"183") { log(1, " -- 183 -> SESSION --\n"); };

if(status=~"2[0-9][0-9]") { log(1, " -- 2xx -> OK --\n"); };

if ((isflagset(6) || isflagset(7)) && (status=~"(180)|(183)|2[0-9][0-9]")) { if (!search("^Content-Length:\ 0")) { #fix_nated_contact(); use_media_proxy(); }; };

if (client_nat_test("1")) { fix_nated_contact(); };

}

Thank you very much

Regards,

Lucas

Great, please disregard my last post.

Thanks.

On Wed, 30 Mar 2005 17:20:58 -0300, Lucas Aimaretto lucas@cyneric.com wrote:

...

...

No, there is only traffic in the direction SIP->PSTN. I'm not using the web interface, but instead the shell command session.py

This is what it shows ... ( for the case when I call from

PSTN-to-SIP

...

)

Total traffic: 20.48kbps/0bps/0bps (in1/in2/out) Session count: 1

I think you need to look into your ser.cfg; it looks to me like you are proxying calls only when they originate from NAT -> non-nat and not from non-natted endpoints -> NAT.

In some way, my gateway was modifying my packets. What I did was ...

if ( src_ip = IP_GATEWAY) { force_rport(); fix_contact(); use_media_proxy(); };

... at the INVITE, and so, that was it.

Just in case any has the same problems.

Regards,

Lucas

-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.8.6 - Release Date: 30/03/2005

---

Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers