sr-users December 2006

sr-users@lists.kamailio.org

152 participants
257 discussions

[Users] t_relay handling of r-URI, d-URI and Route URIs

by Klaus Darilion

Hi! Can someone please tell me how t_relay exactly works? What URI will be used for forwarding if d-URI is set and Route headers are present? Or does loose_route set the d-URI? What if I add a route header with append_hf - will it be used for t_relay? regards klaus -- Klaus Darilion nic.at

17 years, 11 months

[Users] OpenSer Sending CANCEL after receiving 200 OK for a INVITE

by Md. Samiul Aftad Chowdhury

Hello Everyone, I am facing a problem when I am trying to send calls from my Openser(1.1.0) to another sip switch "MERA MSIP v.1.0.2." Here is the senario: openser( PublicIP 54.15.32.44) <====> Mera Sip Switch(PublicIP 52.132.36.43) ======================= ========================== INVITE ------------------> <----------------- 100 Trying <----------------- 183 Session Progress <----------------- 200 OK (for invite) CANCEL -------------------> <----------------- 200 OK (for cancel) <----------------- 487 Request Terminated ACK -------------------> This seems quite normal senario but prolem is that this "CANCEL" is not generated by the end point (in mycase IP Phone in public IP). This "CANCEL" generated from openser just after receiving the 200 OK of INVITE request. Why openser generateing a CANCEL while it already received 200 OK for that INVITE?? Here is my openser configuration script: openser.cfg ===================Script Begin=========================== # USE THIS VERSION IS REGISTER # ----------- global configuration parameters ------------------------ debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) /* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */ log_facility=LOG_LOCAL0 listen=54.15.32.44 alias="sip.myfone.com" check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 fifo="/tmp/openser_fifo" # ------------------ module loading ---------------------------------- mpath="/usr/local/openser/lib/openser/modules/" # Uncomment this if you want to use SQL database #loadmodule "mysql.so" loadmodule "exec.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "xlog.so" loadmodule "auth.so" loadmodule "auth_radius.so" loadmodule "acc.so" loadmodule "nathelper.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- modparam("usrloc", "db_mode", 0) # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) #modparam("rr", "enable_double_rr", 1) # For fail over # -- tm params -- # set time for which ser will be waiting for a final response; # fr_inv_timer sets value for INVITE transactions, fr_timer # for all others modparam("tm", "fr_inv_timer", 60 ) modparam("tm", "fr_timer", 30 ) #for Radius Accounting modparam("acc", "radius_flag", 1 ) modparam("acc", "radius_missed_flag", 3 ) # !! Nathelper modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) # Ping interval 30 s modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT ## Just for Fun,It shows color Log modparam("xlog", "force_color", 1) # ------------------------- request routing logic ------------------- # 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; }; route(2); if (!method=="REGISTER") record_route(); if(method=="INVITE" || method=="BYE") setflag(1); 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); }; #This is the best place for rewrite host port if (!method=="REGISTER") { rewritehostport("52.132.36.43:5060"); }; if (uri==myself) { if (method=="REGISTER") { if (!radius_www_authorize("54.15.32.44")) { www_challenge("54.15.32.44", "0"); exit; }; if (isflagset(5)) { setflag(6); # if you want OPTIONS natpings uncomment next # setflag(7); }; save("location"); 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/')){ setflag(6); }; if (isflagset(5)||isflagset(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); }; if (method=="INVITE") { xlog("L_INFO", "Invite -> [CallerID=$fu] and [DialedNo=$tU]\n"); if(uri=~"sip:[0-9]{20,}@.+") { sl_send_reply("513", "Message too big"); exit; }; if (!radius_www_authorize("54.15.32.44")) { www_challenge("54.15.32.44", "0"); exit; }; consume_credentials(); }; } route[3] { if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ # xlog("L_INFO","Invite -> Force Rtp Proxy"); if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } t_on_failure("1"); }; if (isflagset(5)) search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes;lr=on'); t_on_reply("1"); } failure_route[1] { if(!t_was_cancelled()) { rewritehostport("52.132.36.43:5060"); xlog("L_INFO","Invite -> Fail Over Route 1 at Time [$Tf]"); if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } t_on_failure("2"); t_relay(); } } failure_route[2] { if(!t_was_cancelled()) { rewritehostport("52.132.36.43:5060"); xlog("L_INFO","Invite -> Fail Over Route 2 at Time [$Tf]"); if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } t_on_failure("3"); t_relay(); } } failure_route[3] { if(!t_was_cancelled()) { rewritehostport("52.132.36.43:5060"); xlog("L_INFO","Invite -> Fail Over Route 3 at Time [$Tf]"); if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } t_on_failure("4"); t_relay(); } } failure_route[4] { if(!t_was_cancelled()) { rewritehostport("52.132.36.43:5060"); xlog("L_INFO","Invite -> Fail Over Route 4 at Time [$Tf]"); if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy(); } t_on_failure("5"); t_relay(); } } failure_route[5] { if (isflagset(6) || isflagset(5)) { unforce_rtp_proxy(); } } onreply_route[1] { if (!search("^Content-Length:[ ]*0")) { force_rtp_proxy("r"); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); if (isflagset(6)) { fix_nated_contact(); } exit; } ==========================Script End====================== Here is the sip trace (from ngrep): U IP Phone -> Openser INVITE sip:9128222570841@54.15.32.44 SIP/2.0. Via: SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport. Max-Forwards: 70. User-Agent: PA168S V1.55.013 CFG0 . From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44>. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. Contact: <sip:561705239298@58.88.13.13:5060>. Authorization: Digest username="561705239298", realm="54.15.32.44", nonce="4577de9a6e32a8fafc108687cbc9b520cfd2b1ea", uri=" sip:9128222570841@54.15.32.44", response="c18eeb314b2c5524ab3d7fe50b52851c", algorithm=MD5. CSeq: 2 INVITE. Supported: replaces. Content-Type: application/sdp. Content-Length: 134. . v=0. o=- 12369099 22311551 IN IP4 58.88.13.13. s=SIP CALL. c=IN IP4 58.88.13.13. t=0 0. m=audio 8704 RTP/AVP 4. a=rtpmap:4 G723/8000. # U Openser -> IP PHONE SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport=5060. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44>. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. CSeq: 2 INVITE. Server: openser (1.1.0 (i386/linux)). Content-Length: 0. Warning: 392 54.15.32.44:5060 "Noisy feedback tells: pid=27317 req_src_ip= 58.88.13.13 req_src_port=5060 in_uri=sip:9128222570841@54.15.32.44 out_uri= sip:9128222570841@52.132.36.43:5060 via_cnt==1". . # U Openser -> Mera INVITE sip:9128222570841@52.132.36.43:5060 SIP/2.0. Record-Route: <sip:54.15.32.44;lr=on;ftag=1pRGOP6lOmlBFIxy>. Via: SIP/2.0/UDP 54.15.32.44;branch=z9hG4bKa124.220e0023.0. Via: SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport=5060. Max-Forwards: 69. User-Agent: PA168S V1.55.013 CFG0 . From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44>. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. Contact: <sip:561705239298@58.88.13.13:5060>. CSeq: 2 INVITE. Supported: replaces. Content-Type: application/sdp. Content-Length: 152. . v=0. o=- 12369099 22311551 IN IP4 58.88.13.13. s=SIP CALL. c=IN IP4 54.15.32.44. t=0 0. m=audio 39780 RTP/AVP 4. a=rtpmap:4 G723/8000. a=nortpproxy:yes. # U Openser -> Mera INVITE sip:9128222570841@52.132.36.43:5060 SIP/2.0. Record-Route: <sip:54.15.32.44;lr=on;ftag=1pRGOP6lOmlBFIxy>. Via: SIP/2.0/UDP 54.15.32.44;branch=z9hG4bKa124.220e0023.1. Via: SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport=5060. Max-Forwards: 69. User-Agent: PA168S V1.55.013 CFG0 . From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44>. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. Contact: <sip:561705239298@58.88.13.13:5060>. CSeq: 2 INVITE. Supported: replaces. Content-Type: application/sdp. Content-Length: 152. . v=0. o=- 12369099 22311551 IN IP4 58.88.13.13. s=SIP CALL. c=IN IP4 54.15.32.44. t=0 0. m=audio 39780 RTP/AVP 4. a=rtpmap:4 G723/8000. a=nortpproxy:yes. # U Mera -> Openser SIP/2.0 100 Trying. Via: SIP/2.0/UDP 54.15.32.44;branch=z9hG4bKa124.220e0023.0,SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport=5060. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44>. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. CSeq: 2 INVITE. Content-Length: 0. . # U Mera -> Openser SIP/2.0 100 Trying. Via: SIP/2.0/UDP 54.15.32.44;branch=z9hG4bKa124.220e0023.1,SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport=5060. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44>. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. CSeq: 2 INVITE. Content-Length: 0. . # U Mera -> Openser SIP/2.0 183 Session Progress. Record-Route: <sip:52.132.36.43:5060;lr>,<sip:54.15.32.44 ;lr=on;ftag=1pRGOP6lOmlBFIxy>. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44 >;tag=ffff1200ffff7710ff00000f1f6fff3b. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. CSeq: 2 INVITE. Server: MERA MSIP v.1.0.2. Contact: <sip:9128222570841@52.132.36.43:5060>. Content-Type: application/sdp. Via: SIP/2.0/UDP 54.15.32.44:5060;branch=z9hG4bKa124.220e0023.0,SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport=5060. Content-Length: 136. . v=0. o=- 1165483497 1165483497 IN IP4 52.132.36.43. s=-. c=IN IP4 52.132.36.43. t=0 0. m=audio 37548 RTP/AVP 4. a=rtpmap:4 G723/8000. . # U Openser -> IP PHONE SIP/2.0 183 Session Progress. Record-Route: <sip:52.132.36.43:5060;lr>,<sip:54.15.32.44 ;lr=on;ftag=1pRGOP6lOmlBFIxy>. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44 >;tag=ffff1200ffff7710ff00000f1f6fff3b. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. CSeq: 2 INVITE. Server: MERA MSIP v.1.0.2. Contact: <sip:9128222570841@52.132.36.43:5060;nat=yes>. Content-Type: application/sdp. Via: SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport=5060. Content-Length: 153. . v=0. o=- 1165483497 1165483497 IN IP4 52.132.36.43. s=-. c=IN IP4 54.15.32.44. t=0 0. m=audio 39784 RTP/AVP 4. a=rtpmap:4 G723/8000. . a=nortpproxy:yes. # U Mera -> Openser SIP/2.0 200 OK. Record-Route: <sip:52.132.36.43:5060;lr>,<sip:54.15.32.44 ;lr=on;ftag=1pRGOP6lOmlBFIxy>. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44 >;tag=ffff1200ffff7710ff00000f1f6fff3b. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. CSeq: 2 INVITE. Server: MERA MSIP v.1.0.2. Contact: <sip:9128222570841@52.132.36.43:5060>. Content-Type: application/sdp. Via: SIP/2.0/UDP 54.15.32.44:5060;branch=z9hG4bKa124.220e0023.0,SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport=5060. Content-Length: 136. . v=0. o=- 1165483501 1165483501 IN IP4 52.132.36.43. s=-. c=IN IP4 52.132.36.43. t=0 0. m=audio 37548 RTP/AVP 4. a=rtpmap:4 G723/8000. . # U Openser -> IP Phone SIP/2.0 200 OK. Record-Route: <sip:52.132.36.43:5060;lr>,<sip:54.15.32.44 ;lr=on;ftag=1pRGOP6lOmlBFIxy>. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44 >;tag=ffff1200ffff7710ff00000f1f6fff3b. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. CSeq: 2 INVITE. Server: MERA MSIP v.1.0.2. Contact: <sip:9128222570841@52.132.36.43:5060;nat=yes>. Content-Type: application/sdp. Via: SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKI7LP7qhgGKFHt904;rport=5060. Content-Length: 153. . v=0. o=- 1165483501 1165483501 IN IP4 52.132.36.43. s=-. c=IN IP4 54.15.32.44. t=0 0. m=audio 39784 RTP/AVP 4. a=rtpmap:4 G723/8000. . a=nortpproxy:yes. # U Openser -> Mera CANCEL sip:9128222570841@52.132.36.43:5060 SIP/2.0. Via: SIP/2.0/UDP 54.15.32.44;branch=z9hG4bKa124.220e0023.1. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. To: "9128222570841" <sip:9128222570841@54.15.32.44>. CSeq: 2 CANCEL. User-Agent: openser (1.1.0 (i386/linux)). Content-Length: 0. . # U Mera -> Openser SIP/2.0 200 OK. Via: SIP/2.0/UDP 54.15.32.44;branch=z9hG4bKa124.220e0023.1. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. To: "9128222570841" <sip:9128222570841@54.15.32.44>. CSeq: 2 CANCEL. Content-Length: 0. . # U Mera -> Openser SIP/2.0 487 Request Terminated. Via: SIP/2.0/UDP 54.15.32.44;branch=z9hG4bKa124.220e0023.1. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. To: "9128222570841" <sip:9128222570841@54.15.32.44>. CSeq: 2 INVITE. Content-Length: 0. . # U Openser -> Mera ACK sip:9128222570841@52.132.36.43:5060 SIP/2.0. Via: SIP/2.0/UDP 54.15.32.44;branch=z9hG4bKa124.220e0023.1. From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. To: "9128222570841" <sip:9128222570841@54.15.32.44>. CSeq: 2 ACK. User-Agent: openser (1.1.0 (i386/linux)). Content-Length: 0. . # U IP Phone -> Openser ACK sip:9128222570841@52.132.36.43:5060 SIP/2.0. Via: SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKTpMoqwSSNb4LvZrv;rport. Route: <sip:54.15.32.44;lr=on;ftag=1pRGOP6lOmlBFIxy>, <sip:52.132.36.43:5060 ;lr>. Max-Forwards: 70. User-Agent: PA168S V1.55.013 CFG0 . From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44 >;tag=ffff1200ffff7710ff00000f1f6fff3b. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. Contact: <sip:561705239298@58.88.13.13:5060>. Authorization: Digest username="561705239298", realm="54.15.32.44", nonce="4577de9a6e32a8fafc108687cbc9b520cfd2b1ea", uri=" sip:9128222570841@52.132.36.43:5060", response="7b312414aa7de3f999f8fd4a2a81c8a5", algorithm=MD5. CSeq: 2 ACK. Content-Length: 0. . # U Openser -> Mera ACK sip:9128222570841@52.132.36.43:5060 SIP/2.0. Record-Route: <sip:54.15.32.44;lr=on;ftag=1pRGOP6lOmlBFIxy>. Via: SIP/2.0/UDP 54.15.32.44;branch=z9hG4bKa124.220e0023.3. Via: SIP/2.0/UDP 58.88.13.13:5060;branch=z9hG4bKTpMoqwSSNb4LvZrv;rport=5060. Route: <sip:52.132.36.43:5060;lr>. Max-Forwards: 69. User-Agent: PA168S V1.55.013 CFG0 . From: "561705239298" <sip:561705239298@54.15.32.44>;tag=1pRGOP6lOmlBFIxy. To: "9128222570841" <sip:9128222570841@54.15.32.44 >;tag=ffff1200ffff7710ff00000f1f6fff3b. Call-ID: BCmB3zph5YmuC8oz(a)58.88.13.13. Contact: <sip:561705239298@58.88.13.13:5060>. Authorization: Digest username="561705239298", realm="54.15.32.44", nonce="4577de9a6e32a8fafc108687cbc9b520cfd2b1ea", uri=" sip:9128222570841@52.132.36.43:5060", response="7b312414aa7de3f999f8fd4a2a81c8a5", algorithm=MD5. CSeq: 2 ACK. Content-Length: 0. P-hint: rr-enforced. .

17 years, 11 months

[Users] Broken link for PUA_USRLOC

by Nicolas Palix

Hi, In the page http://www.openser.org/docs/modules/1.2.x/ PUA_USRLOC module refers to http://www.openser.org/docs/modules/devel/pua.html instead of http://www.openser.org/docs/modules/devel/pua_usrloc.html Regards, -- Nicolas Palix http://phoenix.labri.fr/people/palix/

17 years, 11 months

RE: [Users] MediaProxy SER with AsteriskS

by Thomas Deillon

Hi all, I try a configuration with a SER server with mediaproxy that load balance SIP/RTP two 2 asterisks server (REGISTRAR, ... ) SER: 192.168.1.81 and 10.10.10.1 Asterisk1: 10.10.10.12 with default route 10.10.10.1 Asterisk2: 10.10.10.13 with default route 10.10.10.1 Mediaproxy.ini: [Dispatcher] start = yes socket = /var/run/proxydispatcher.sock group = root defaultProxy = /var/run/mediaproxy.sock [MediaProxy] start = yes socket = /var/run/mediaproxy.sock group = root proxyIP = 192.168.1.81 portRange = 60000:65000 TOS = 0xb8 idleTimeout = 60 holdTimeout = 3600 forceClose = 0 openser.cfg ... loadmodule "/usr/lib/openser/modules/sl.so" loadmodule "/usr/lib/openser/modules/tm.so" loadmodule "/usr/lib/openser/modules/rr.so" loadmodule "/usr/lib/openser/modules/maxfwd.so" loadmodule "/usr/lib/openser/modules/usrloc.so" loadmodule "/usr/lib/openser/modules/registrar.so" loadmodule "/usr/lib/openser/modules/textops.so" loadmodule "/usr/lib/openser/modules/dispatcher.so" loadmodule "/usr/lib/openser/modules/xlog.so" loadmodule "/usr/lib/openser/modules/mediaproxy.so" loadmodule "/usr/lib/openser/modules/domain.so" loadmodule "/usr/lib/openser/modules/mysql.so" modparam("domain", "db_url", "mysql://ser:ser@localhost/ser") modparam("mediaproxy", "mediaproxy_socket", "/var/run/proxydispatcher.sock") modparam("mediaproxy", "natping_interval", 20) modparam("dispatcher", "list_file", "/etc/openser/dispatcher.list") route{ ... if(method=="REGISTER"){ # For the moment I just do like this to register # my phone on one server forward("10.10.10.12"); } else { if (method==INVITE) { use_media_proxy(); } ds_select_dst("1", "4"); t_relay(); } } Dispatcher.list: 1 sip:10.10.10.12:5060 1 sip:10.10.10.13:5060 Thanks a lot for your help, Thomas

17 years, 11 months

[Serusers] pstn gateway

by jorain

Hi all, I have a PSTN gateway (IP:123.456.78.90), when I route to it, there is no audio between PSTN and UA. I found that the PSTN gateway IP is different from the media IP, which is specified inside the SDP Connection Information (c) : IN IP4 xxx.xxx.xxx.xxx My RTPProxy is working and tested before. Please help. Thanks Regards, jorain

17 years, 11 months

[Serusers] Ser accounting question?

by Lokesh Kumar

Hello List, Below mentioned is my accounting packet, I would like to know what is IAPP-AP-Check, what this check do , and where its configuration present. Can I change Service-Type ? Wed Dec 6 20:08:23 2006 Acct-Status-Type = Stop Service-Type = IAPP-AP-Check Sip-Response-Code = 200 Sip-Method = 8 User-Name = "69021(a)xxx.yyy.pt" Calling-Station-Id = "sip:69021@xxx.yyy.pt" Called-Station-Id = "sip:30612@xxx.yyy.pt" Sip-Translated-Request-URI = "sip:30612@212.13.xx.yy:5060" Acct-Session-Id = "D4808CE2-1BA9-4572-B82B-5A0BCF6AB7CB(a)192.168.0.47" Sip-To-Tag = "86949D74-2699" Sip-From-Tag = "67434843439" Sip-Cseq = "3" NAS-Port = 5060 Acct-Delay-Time = 0 NAS-IP-Address = 127.0.0.1 Client-IP-Address = 127.0.0.1 Acct-Unique-Session-Id = "c6adb5da735b1150" Timestamp = 1165435703 Thanks Lokesh -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.6/567 - Release Date: 12/4/2006

17 years, 11 months

[Serusers] load balancing amongst servers

by Zeeshan Sajid

First of all thanks for the response and support ... really appreciate that ... This time the problem is alittle more complex now coming to the point I really need to know how can i do load balancing for a situation like [SER1] DIALER ----------------> [SER2] --------> PSTN [SER3] I have 3 SER servers and i want some kind of load balancing amongst them. I have been trying to make SER work behind a load balancer but that seriously involves mangling with some headers. So, is there any clean way to get this done ... Please help me in this as i am pretty struck at this point... regards, Zeeshan. --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.

17 years, 11 months

[Users] openser.org web site: new look

by Daniel-Constantin Mierla

Hello, just to let you know that a new template which is more in harmony with the OpenSER logo has been deployed on the web site. Anyone who considers that can improve the design and make user's experience better, please send an email to devel(a)openser.org or team(a)openser.org. The site uses the open source cms mambo/joomla engine. The OpenSER logo should have replaced old variants, and has been posted in relevant new places (e.g., dokuwiki). See: http://www.openser.org If you want to get the OpenSER logo, there are two variants available on the site, with white background and transparent: http://www.openser.org/images/openser-logo.jpg http://www.openser.org/images/openser-logo-transparent.png Cheers, Daniel

17 years, 11 months

[Users] avpops multi db query

by vallimamod abdullah

Hello list, For my call routing algorithm, I need to query different databases to retrieve the destination of an outgoing call. From what I have understood, I can specify only one db url in the avpops module to use with avp_db_query(). Is there a (simple) way to make queries in different databases with openser ? Thanks. -- Regards, -vma .

17 years, 11 months

[Users] ACK and re-INVITE ordering

by Jerome Martin

Hello everyone, I found many references in serdev, openser users, etc. MLs to the issue at hand, but only came up with diverging opinions and no solution whatsoever. The issue appears in case of a UA sending a re-INVITE inside of an established dialog. Depending on your configuration file, version, network conditions, there is NO guarantee that this re-INVITE will be sent to (I'm not even talking about reaching) the next hop (typically a PSTN gateway) AFTER the ACK to the first INVITE of the dialog. I perfectly understand why (openser being transaction and not dialog statefull being the only reason that really matters, given the fact that INVITE and ACK are separate transactions, often handled by separate openser processes) it is this way. However, it seems that several gateways are not handling this well at all, and just drop the transaction typically sending a "500 Server internal error". I've read reports about cisco AS5300, Asterisk, and I am myself experiencing this with an Andiocodes Mediant 2000 gateway. In my case, the issue is there 99% of the time. I know I could profile a bit my config file to ensure ACKs are processed faster than INVITEs (which propably is already the case), but this is hardly a workaround. I got tempted to even call an external "timer" via exec_msg when detecting a re-INVITE (if it is an INVITE, has a to_tag and is loose routed), but come on, I'm sure we can do better than this ! So no matter what the RFCs say or mean to say, no matter how long we argue about this, the facts are : - gateways often don't stand this ordering issue - many iPBXs are using reINVITEs for several call features - the only way to solve this is to be dialog statefull, at least for ACKs and INVITES So my conclusion is : I'm going to code an ugly little hack - using an external database and avpops - so that ACKs are logged per Cseq+callid, and when reinvites are detected, relay will be delayed until the last ACK is logged as sent. What do you think ? Is there a way to use the dialog module to optimize this (flagging the SIP headers themselves instead of an external DB) ? Best Regards, Jerome Martin

17 years, 11 months

← Newer
1
...
16
17
18
19
20
21
22
...
26
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users December 2006