From yoannks at gmail.com Wed Sep 2 04:33:46 2009 From: yoannks at gmail.com (Yoann Karas) Date: Wed, 2 Sep 2009 13:33:46 +0200 Subject: [RTPproxy Users] RTPproxy to other media proxy Message-ID: <5778ebe40909020433v575bc31ex5cbc30d761966f82@mail.gmail.com> Hello, I have few questions about RTPproxy. I'm using kamailio and rtpproxy in order to establish rtp session behind a nat. It works fine. I made some test with a media proxy develloped in my company and it works as good as RTPproxy. I used the media proxy from my company because we can play with the stream bitrate. The problem is my media proxy doesn't fit with "nathelper" module and it is not possible to handle more than 1call :D not really usefull.. Here was my idea. Alice-----------SIP------------| Kamailio |------------SIP-----------Bob Alice-----------RTP-----------|*RTPproxy*|-----------RTP------------Bob | | ___|_____|_____ |*MyMedia Proxy*| In that way SDP are modify by "nathelper" module. RTP stream goes first to RTPproxy and then to my proxy then go back to RTPproxy. I hope you get my idea and can give me light about that idea. Do you think it is possible to do that !? Any hints about coding this idea ? Best Regards, Yoann -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rtpproxy.org/pipermail/users/attachments/20090902/b3e28a83/attachment.html From josip.djuricic at voljatel.hr Thu Sep 10 08:08:11 2009 From: josip.djuricic at voljatel.hr (Josip Djuricic) Date: Thu, 10 Sep 2009 17:08:11 +0200 Subject: [RTPproxy Users] Status 481 Call Leg/Transaction Does Not Exist Message-ID: <01dd01ca3228$83468d00$89d3a700$@djuricic@voljatel.hr> Dear I am trying to do call transfer, but it fails with SIP 481 message. Scenario is like this: 2 phones registered to SER Phone 1 <-----> SER <-----> Phone 2 When making a call SER forwards all meassages to b2bua, b2bua asks radius (gets all necessary info, routes ...etc) and sends call to Phone 2. The call is sucesfully established, and everything works as expected in both ways. Now the problem starts when I want to do Call Transfer, because I immediatelly after establishing second line to the Phone 3 get SIP 481 Call Leg/Transaction Does Not Exist. I get the same thing if I try to put caller on HOLD from the party that answered the Call. Phone1 -----> SER -----> B2BUA -----> Phone 2 ----xfer-----> B2BUA -----> SIP 481 I am attaching b2bua log and also attaching sip and radius tcpdump. P.S. There is no NAT involved, I am just using private ips with direct routing for test P.P.S. I have done only one modification to b2bua_radius.py to change xpkg-routing parameter to be compatible with our billing/routing engine (just to expect different radius attrib and it works fine) Best regards, Josip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rtpproxy.org/pipermail/users/attachments/20090910/87832071/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: dump-xfer-22222.cap Type: application/octet-stream Size: 38176 bytes Desc: not available Url : http://lists.rtpproxy.org/pipermail/users/attachments/20090910/87832071/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: b2log-22222.log Type: application/octet-stream Size: 36787 bytes Desc: not available Url : http://lists.rtpproxy.org/pipermail/users/attachments/20090910/87832071/attachment-0003.obj From jcpriotti at gmail.com Tue Sep 15 05:33:46 2009 From: jcpriotti at gmail.com (Juan Priotti) Date: Tue, 15 Sep 2009 09:33:46 -0300 Subject: [RTPproxy Users] TOS not working? Message-ID: <36E8D04B-D53B-4C60-A118-FD7802E13E07@gmail.com> Hi, I'm using rtpproxy and need to be able to set TOS or use the default TOS but for some reason I'm getting 0x0 for default TOS: 2:58:03.099359 IP (tos 0xc0, ttl 249, id 28676, offset 0, flags [none], proto: UDP (17), length: 200) aa.bb.cc.dd.5004 > ww.xx.yy.zz. 48152: UDP, length 172 12:58:03.105643 IP (tos 0x0, ttl 54, id 48883, offset 0, flags [none], proto: UDP (17), length: 200) ww.xx.yy.zz.48152 > aa.bb.cc.dd. 5004: UDP, length 172 RTP Proxy is running at ww.xx.yy.zz together with opensips. UA is at aa.bb.cc.dd and sending 0xc0 for TOS but getting 0x0 from the RTP Proxy. I have configured RTP Proxy with default setting for TOS (no -t option) and also added -t 0xc0 and -t 184 but I get same results. Any idea why I can't set up TOS? Thanks, Juan From ryan.yaldor at pbx-change.com Thu Sep 24 10:17:05 2009 From: ryan.yaldor at pbx-change.com (Ryan Yaldor) Date: Thu, 24 Sep 2009 13:17:05 -0400 Subject: [RTPproxy Users] Early Media Issue Message-ID: <2326AD79CF8CA048B00058B8569A9EF2AFE129@exchange2k3.y-tech.com> Seeing an issue with early media that arrives before the 180 or 183 with SDP. When the media arrives prior, it is being buffered and then flooded out once the 180 or 183 arrives. This causes the delta on the packets to be around 0 instead of ~20ms. Once the buffer is cleared the call is fine for the remainder of the call. Here is a short sample of the packet timing from rtpproxy to the client side. 236,110,5.94,18.63,53.28,,[ Ok ],09/23/2009 07:10:43.760,74 237,111,0.02,18.71,53.76,,[ Ok ],09/23/2009 07:10:43.760,74 238,112,0.02,18.79,54.24,,[ Ok ],09/23/2009 07:10:43.760,74 239,113,0.01,18.87,54.72,,[ Ok ],09/23/2009 07:10:43.760,74 240,114,0.01,18.94,55.20,,[ Ok ],09/23/2009 07:10:43.760,74 242,115,5.96,18.63,55.68,,[ Ok ],09/23/2009 07:10:43.766,74 243,116,0.02,18.71,56.16,,[ Ok ],09/23/2009 07:10:43.766,74 244,117,0.02,18.79,56.64,,[ Ok ],09/23/2009 07:10:43.766,74 245,118,0.02,18.87,57.12,,[ Ok ],09/23/2009 07:10:43.766,74 250,119,5.92,18.57,57.60,,[ Ok ],09/23/2009 07:10:43.772,74 252,120,18.51,17.50,58.08,,[ Ok ],09/23/2009 07:10:43.791,74 256,121,20.01,16.41,58.56,,[ Ok ],09/23/2009 07:10:43.811,74 260,122,20.17,15.39,59.04,,[ Ok ],09/23/2009 07:10:43.831,74 264,123,19.85,14.44,59.52,,[ Ok ],09/23/2009 07:10:43.851,74 268,124,19.99,13.54,60.00,,[ Ok ],09/23/2009 07:10:43.871,74 272,125,20.14,12.70,60.48,,[ Ok ],09/23/2009 07:10:43.891,74 276,126,19.84,11.92,60.96,,[ Ok ],09/23/2009 07:10:43.911,74 280,127,20.00,11.17,61.44,,[ Ok ],09/23/2009 07:10:43.931,74 284,128,20.02,10.48,61.92,,[ Ok ],09/23/2009 07:10:43.951,74 288,129,20.14,9.83,62.40,,[ Ok ],09/23/2009 07:10:43.971,74 292,130,20.07,9.22,62.88,,[ Ok ],09/23/2009 07:10:43.991,74 >From the received side 5,0,0.00,0.00,0.48,SET,Incorrect timestamp,09/23/2009 07:10:41.391,74 6,1,20.03,0.00,0.96,,[ Ok ],09/23/2009 07:10:41.411,74 7,2,20.14,0.01,1.44,,[ Ok ],09/23/2009 07:10:41.431,74 8,3,19.84,0.02,1.92,,[ Ok ],09/23/2009 07:10:41.451,74 9,4,20.00,0.02,2.40,,[ Ok ],09/23/2009 07:10:41.471,74 10,5,20.02,0.02,2.88,,[ Ok ],09/23/2009 07:10:41.491,74 11,6,20.02,0.02,3.36,,[ Ok ],09/23/2009 07:10:41.511,74 12,7,19.93,0.02,3.84,,[ Ok ],09/23/2009 07:10:41.531,74 13,8,20.11,0.03,4.32,,[ Ok ],09/23/2009 07:10:41.551,74 14,9,20.05,0.03,4.80,,[ Ok ],09/23/2009 07:10:41.571,74 Any suggestions how to prevent this? It causes having on MOS score monitoring. Thanks, Ryan Yaldor From luis.guaman at interlancompu.com Tue Sep 15 05:28:52 2009 From: luis.guaman at interlancompu.com (Luis Guaman) Date: Tue, 15 Sep 2009 07:28:52 -0500 Subject: [RTPproxy Users] Sometimes YES sometime NO rtp packets Message-ID: <000001ca3600$1821d210$48657630$@guaman@interlancompu.com> Hi list, We have one Kamailio server with public ip on Internet and two uac?s behind different nats. The problem is that sometimes rtp packets flow normally in a call. Sometimes in other call there is no rtp, audio in both ends same config. At this call, no rtp, we can get rtp packets with hold/unhold events. Thanks in advance. I am using Kamailio 1.5.2-tls on Lenny Linux Srv1 2.6.26-2-686 #1 SMP i686 GNU/Linux with rtpproxy: Srv1:/usr/local/etc/kamailio# rtpproxy -v Basic version: 20040107 Extension 20050322: Support for multiple RTP streams and MOH Extension 20060704: Support for extra parameter in the V command Extension 20071116: Support for RTP re-packetization Extension 20071218: Support for forking (copying) RTP stream Extension 20080403: Support for RTP statistics querying Extension 20081102: Support for setting codecs in the update/lookup command Extension 20081224: Support for session timeout notifications Extension 20090810: Support for automatic bridging Rtpproxy is run as follow: /usr/local/bin/rtpproxy -u rtpproxy -l 200.XXX.XX.XXX -s udp:localhost:7722 It Sometime works fine, ie rtp flows normal: ===RTP YES=== DBUG:handle_command: received command "25837_10 Uc18,4,101 YmRjZmE5NWM5MmRkMjQ3YmJjNWI5YWFlNGNhZTU1NDk. 186.66.71.118 21578 b309ba09;1" INFO:handle_command: new session YmRjZmE5NWM5MmRkMjQ3YmJjNWI5YWFlNGNhZTU1NDk., tag b309ba09;1 requested, type strong INFO:handle_command: new session on a port 38588 created, tag b309ba09;1 INFO:handle_command: pre-filling caller's address with 186.66.71.118:21578 DBUG:doreply: sending reply "25837_10 38588 200.xxx.xx.xxx " DBUG:handle_command: received command "25839_6 Lc18,101 YmRjZmE5NWM5MmRkMjQ3YmJjNWI5YWFlNGNhZTU1NDk. 190.152.165.48 20514 b309ba09;1 0d4da661;1" INFO:handle_command: lookup on ports 38588/58568, session timer restarted INFO:handle_command: pre-filling callee's address with 190.152.165.48:20514 DBUG:doreply: sending reply "25839_6 58568 200.xxx.xx.xxx " DBUG:handle_command: received command "25839_7 Lc18,101 YmRjZmE5NWM5MmRkMjQ3YmJjNWI5YWFlNGNhZTU1NDk. 190.152.165.48 20514 b309ba09;1 0d4da661;1" INFO:handle_command: lookup on ports 38588/58568, session timer restarted DBUG:doreply: sending reply "25839_7 58568 200.xxx.xx.xxx " DBUG:handle_command: received command "25839_8 Lc18,101 YmRjZmE5NWM5MmRkMjQ3YmJjNWI5YWFlNGNhZTU1NDk. 190.152.165.48 20514 b309ba09;1 0d4da661;1" INFO:handle_command: lookup on ports 38588/58568, session timer restarted DBUG:doreply: sending reply "25839_8 58568 200.xxx.xx.xxx " INFO:rxmit_packets: caller's address filled in: 186.66.71.118:1030 (RTP ==TearDownRTPYES=== DBUG:handle_command: received command "25839_9 D YmRjZmE5NWM5MmRkMjQ3YmJjNWI5YWFlNGNhZTU1NDk. b309ba09 0d4da661" INFO:handle_delete: forcefully deleting session 1 on ports 38588/58568 INFO:remove_session: RTP stats: 1702 in from callee, 1562 in from caller, 3264 relayed, 0 dropped INFO:remove_session: RTCP stats: 7 in from callee, 7 in from caller, 14 relayed, 0 dropped INFO:remove_session: session on ports 38588/58568 is cleaned up DBUG:doreply: sending reply "25839_9 0 " Sometime rtp don?w flows. ====No RTP==== DBUG:handle_command: received command "25840_5 Uc18,4,101 MGZjYTk4Yjc0YTZkNzI4YTdhZDUxZGZkMzE0ZDA5Yzk. 186.66.71.118 21586 1e4c8b45;1" INFO:handle_command: new session MGZjYTk4Yjc0YTZkNzI4YTdhZDUxZGZkMzE0ZDA5Yzk., tag 1e4c8b45;1 requested, type strong INFO:handle_command: new session on a port 57504 created, tag 1e4c8b45;1 INFO:handle_command: pre-filling caller's address with 186.66.71.118:21586 DBUG:doreply: sending reply "25840_5 57504 200.xxx.xx.xxx " DBUG:handle_command: received command "25838_10 Lc18,101 MGZjYTk4Yjc0YTZkNzI4YTdhZDUxZGZkMzE0ZDA5Yzk. 190.152.165.48 20522 1e4c8b45;1 7d31770c;1" INFO:handle_command: lookup on ports 57504/55194, session timer restarted INFO:handle_command: pre-filling callee's address with 190.152.165.48:20522 DBUG:doreply: sending reply "25838_10 55194 200.xxx.xx.xxx " INFO:rxmit_packets: caller's address filled in: 186.66.71.118:1030 (RTP) INFO:rxmit_packets: callee's address filled in: 192.168.50.30:20522 (RTP) INFO:rxmit_packets: guessing RTCP port for callee to be 20523 INFO:rxmit_packets: callee's address filled in: 190.152.165.48:20523 (RTCP) INFO:rxmit_packets: caller's address filled in: 186.66.71.118:1030 (RTCP) ===TearDownNoRTP== DBUG:handle_command: received command "25839_10 D MGZjYTk4Yjc0YTZkNzI4YTdhZDUxZGZkMzE0ZDA5Yzk. 1e4c8b45 7d31770c" INFO:handle_delete: forcefully deleting session 1 on ports 57504/55194 INFO:remove_session: RTP stats: 2 in from callee, 7324 in from caller, 7326 relayed, 0 dropped INFO:remove_session: RTCP stats: 30 in from callee, 31 in from caller, 61 relayed, 0 dropped INFO:remove_session: session on ports 57504/55194 is cleaned up DBUG:doreply: sending reply "25839_10 0 Kamailio config: # ----------- global configuration parameters ------------------------ debug=4 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no# (cmd line: -E) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=6 listen=udp:200.xxx:5060 server_header = "Server: SIP Proxy V1.5.2-tls" user_agent_header = "Server: SIP Proxy V1.5.2-tls" alias=xxxx /* uncomment the following lines to enable TLS support (default off) */ disable_tls = no listen = tls:xxxx:5061 tls_verify_server = 1 tls_verify_client = 1 tls_require_client_certificate = 0 tls_method = TLSv1 tls_certificate = "/usr/local/etc/kamailio/tls/user/user-cert.pem" tls_private_key = "/usr/local/etc/kamailio/tls/user/user-privkey.pem" tls_ca_list = "/usr/local/etc/kamailio/tls/user/user-calist.pem" # --- module loading mpath="/usr/local/lib/kamailio/modules/" loadmodule "mi_fifo.so" loadmodule "db_mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "nathelper.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "pv.so" loadmodule "siputils.so" loadmodule "avpops.so" loadmodule "xlog.so" loadmodule "uac.so" loadmodule "perl.so" loadmodule "htable.so" # --- setting module parameters # -- mi_fifo params -- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") modparam("usrloc|auth_db","db_url","mysql://openser:xxx at localhost/openser") # -- usrloc params -- modparam("usrloc", "db_mode", 2) modparam("usrloc", "nat_bflag", 6) # -- registrar params -- modparam("registrar|nathelper", "received_avp", "$avp(i:42)") # -- auth params -- modparam("auth_db", "calculate_ha1", 0) modparam("auth_db", "password_column", "ha1") # -- rr params -- modparam("rr", "enable_full_lr", 1) # -- nathelper modparam("nathelper", "rtpproxy_sock", "udp:localhost:7722") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", 7) modparam("nathelper", "sipping_from", "sip:pinger at xxxxx") # -- perl modparam("perl", "modpath", "/usr/local/lib/kamailio/perl") modparam("perl", "filename", "/usr/local/etc/kamailio/voipprepago.pl") modparam("htable", "htable", "intentoslogin=>size=4;") # --- main routing logic route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; }; if (uri==myself) { if ((method==OPTIONS) && (! uri=~"sip:.*[@]+.*")) { options_reply(); } } # NAT detection route(2); if (!method=="REGISTER") record_route(); if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER") { if (!www_authorize("xxxx", "subscriber")) { www_challenge("xxxx", "0"); exit; }; if (isflagset(5)) { setbflag(6); # if you want OPTIONS natpings uncomment next setbflag(7); }; save("location","0x04"); exit; }; if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); } route[1] { if (subst_uri('/(sip:.*);nat=yes/\1/')){ setbflag(6); }; if (isflagset(5)||isbflagset(6)) { route(3); } if (!t_relay()) { sl_reply_error(); }; exit; } route[2]{ force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); }; setflag(5); }; } route[3] { if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ force_rtp_proxy("o"); t_on_failure("1"); }; if (isflagset(5)) search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); t_on_reply("1"); } failure_route[1] { if (isbflagset(6) || isflagset(5)) { unforce_rtp_proxy(); } } onreply_route[1] { if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])") { log(2, "Enabling RTPProxy ONREPLY_ROUTE1"); xlog(" dd: $avp(i:450) srcip: $src_ip\n"); force_rtp_proxy("o"); }; search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); if (isbflagset(6)) { fix_nated_contact(); } exit; } Atentamente, Luis Guam?n Rep?blica 396 y Diego de Almagro Ph:+593.2.2526585 Cel:+593.9.4264354 Quito - Ecuador logoReducido -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rtpproxy.org/pipermail/users/attachments/20090915/46afb06d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 2051 bytes Desc: not available Url : http://lists.rtpproxy.org/pipermail/users/attachments/20090915/46afb06d/attachment-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 8506 bytes Desc: not available Url : http://lists.rtpproxy.org/pipermail/users/attachments/20090915/46afb06d/attachment-0001.jpeg From ryan.yaldor at pbx-change.com Wed Sep 23 08:24:33 2009 From: ryan.yaldor at pbx-change.com (Ryan Yaldor) Date: Wed, 23 Sep 2009 11:24:33 -0400 Subject: [RTPproxy Users] Early Media Issue Message-ID: <2326AD79CF8CA048B00058B8569A9EF2AFE051@exchange2k3.y-tech.com> Seeing an issue with early media that arrives before the 180 or 183 with SDP. When the media arrives prior, it is being buffered and then flooded out once the 180 or 183 arrives. This causes the delta on the packets to be around 0 instead of ~20ms. Once the buffer is cleared the call is fine for the remainder of the call. Here is a short sample of the packet timing from rtpproxy to the client side. 236,110,5.94,18.63,53.28,,[ Ok ],09/23/2009 07:10:43.760,74 237,111,0.02,18.71,53.76,,[ Ok ],09/23/2009 07:10:43.760,74 238,112,0.02,18.79,54.24,,[ Ok ],09/23/2009 07:10:43.760,74 239,113,0.01,18.87,54.72,,[ Ok ],09/23/2009 07:10:43.760,74 240,114,0.01,18.94,55.20,,[ Ok ],09/23/2009 07:10:43.760,74 242,115,5.96,18.63,55.68,,[ Ok ],09/23/2009 07:10:43.766,74 243,116,0.02,18.71,56.16,,[ Ok ],09/23/2009 07:10:43.766,74 244,117,0.02,18.79,56.64,,[ Ok ],09/23/2009 07:10:43.766,74 245,118,0.02,18.87,57.12,,[ Ok ],09/23/2009 07:10:43.766,74 250,119,5.92,18.57,57.60,,[ Ok ],09/23/2009 07:10:43.772,74 252,120,18.51,17.50,58.08,,[ Ok ],09/23/2009 07:10:43.791,74 256,121,20.01,16.41,58.56,,[ Ok ],09/23/2009 07:10:43.811,74 260,122,20.17,15.39,59.04,,[ Ok ],09/23/2009 07:10:43.831,74 264,123,19.85,14.44,59.52,,[ Ok ],09/23/2009 07:10:43.851,74 268,124,19.99,13.54,60.00,,[ Ok ],09/23/2009 07:10:43.871,74 272,125,20.14,12.70,60.48,,[ Ok ],09/23/2009 07:10:43.891,74 276,126,19.84,11.92,60.96,,[ Ok ],09/23/2009 07:10:43.911,74 280,127,20.00,11.17,61.44,,[ Ok ],09/23/2009 07:10:43.931,74 284,128,20.02,10.48,61.92,,[ Ok ],09/23/2009 07:10:43.951,74 288,129,20.14,9.83,62.40,,[ Ok ],09/23/2009 07:10:43.971,74 292,130,20.07,9.22,62.88,,[ Ok ],09/23/2009 07:10:43.991,74 >From the received side 5,0,0.00,0.00,0.48,SET,Incorrect timestamp,09/23/2009 07:10:41.391,74 6,1,20.03,0.00,0.96,,[ Ok ],09/23/2009 07:10:41.411,74 7,2,20.14,0.01,1.44,,[ Ok ],09/23/2009 07:10:41.431,74 8,3,19.84,0.02,1.92,,[ Ok ],09/23/2009 07:10:41.451,74 9,4,20.00,0.02,2.40,,[ Ok ],09/23/2009 07:10:41.471,74 10,5,20.02,0.02,2.88,,[ Ok ],09/23/2009 07:10:41.491,74 11,6,20.02,0.02,3.36,,[ Ok ],09/23/2009 07:10:41.511,74 12,7,19.93,0.02,3.84,,[ Ok ],09/23/2009 07:10:41.531,74 13,8,20.11,0.03,4.32,,[ Ok ],09/23/2009 07:10:41.551,74 14,9,20.05,0.03,4.80,,[ Ok ],09/23/2009 07:10:41.571,74 Any suggestions how to prevent this? It causes having on MOS score monitoring. Thanks, Ryan Yaldor