sr-users

sr-users@lists.kamailio.org

10 participants
37460 discussions

[Users] presence module
by henri keski-sikkila 08 Dec '06

08 Dec '06

Hello, I have some problems with presence module. When I use presence module it uses all available memory until there isn't any memory left. If I take ps or top there are many openser prosess but only one of them uses more and more memory all the time. Best Regards, Henri

4 6

[Serusers] Monitoring SER
by Peter Kuebler 08 Dec '06

08 Dec '06

Hi David, Did you ever get any help with this? We use SER here and monitoring is a difficult task. You may want to reference this link for some assistance- http://lists.iptel.org/pipermail/serusers/2006-January/026771.html Your post below: http://lists.iptel.org/pipermail/serusers/2006-May/028625.html Hi, My company has deployed SER on a very large scale across the US and I would like to develop a way to monitor critical parts of SER and the servers that SER runs on. I have several questions regarding monitoring SER. 1. Can SER be SNMP enabled via something like SMUX or AgentX from net-snmp? 2. Does SER have any native SNMP support or other monitoring/logging hooks built in? 3. Do any mibs exist for SER / SIP? 4. I am also still trying to find out if SER has anyway to detect when a user looses registration either via SER internals or external watchdog scripts etc. Thanks David Peter Kuebler Director Network Reliability tele: 703-636-1114 ext: 112 tele: 703-734-4112(alt) cell: 240-506-5703 SunRocket 8045 Leesburg Pike, Suite 300 Vienna, VA 22182 peter.kuebler(a)sunrocket.com SunRocket NOC 703-637-9970

3 2

[Users] MediaProxy / RTPproxy / SER / Asterisk / HA / LVS / DNS [load-balancing and high availability]
by Thomas Deillon 08 Dec '06

08 Dec '06

Hi, I will try to summarise different load balancing solution and I hope that you will correct my mistake to have a good point of view of all solution. Thanks in advance. 1. Solution with DNS SRV allows making Load Balancing (on phone side) but need phones that support this function. 1.1: Explanation In your DNS, you can set DNS SRV entry like this: ------------------------------------------------------------------ |sipserver1.bigu.edu. 43200 IN A 10.0.0.21 |sipserver2.bigu.edu. 43200 IN A 10.0.0.22 |; |_sip._udp.bigu.edu. 43200 IN SRV 0 0 5060 sipserver1.bigu.edu. |_sip._udp.bigu.edu. 43200 IN SRV 0 0 5060 sipserver2.bigu.edu. ------------------------------------------------------------------- In your phone, you set in proxy SIP: "bigu.edu". The DNS will see that it's a request SIP in UDP and will return 1/2 times in this order: - sipserver1.bigu.edu. - sipserver2.bigu.edu. Phone understanding DNS SRV, will use the first line and if it doesn't work, will use the second one. The phone witch not understands the DNS SRV will always use the first line even if it doesn't work. Conclusion (C/c): It's a load balancing on phone side and so, if you can't choose phone model, it's not a solution (like IP centrex). To solve this problem, we have to use a load balancing on network side OR server side. 2. Solution with HA (Heart Beat) it's a solution on server side. 1.1 Explanation This solution is a fail over architecture. You will set a VIP (virtual IP address) for two servers. The server 1 will have this VIP and handle all the traffic. The second server will listen to the "heart" of the first server and it's something going wrong, it will take the VIP. C/c: This solution will not load balance traffic, and half of computer will not be used. 3. [Correct this part please] LVS (linux virtual Server) is a solution to load balance traffic but it's not SIP aware. You can use it for TCP connection but for SIP, it's very hard. However, you can set a load balancing on IP source, and so, each phone will see only one server. More than this, the LVS solution will not try to know if Asterisk OR SER is alive but try to know if the server is alive. (most of the time, only the service going down, not the whole server ...) C/c: The LVS is not a good solution. This can help but the reactivity is very bad. 4. RTPproxy with SER RTPproxy with Ser is use for failover and not load balancing, so, it's the same conclusion as HA. 5. MediaProxy with SERs. I'm really not sure, but I thing that we have to use only SER servers and the loadbalancer have to be a registrar server ?????? C/c: can you conclude... 6. The ultimate solution... I'm looking for a solution with SER (or something else) in loadbalancer and multiple Asterisk server behind it witch will do all SIP function (REGISTRAR, ...). This kind of architecture has to support NATed phones. Thanks to read this and thanks for your help, Thomas Deillon

4 3

[Users] Softphone and OpenSER
by Kc Ayuba 07 Dec '06

07 Dec '06

Hi, I'm new. I was wondering if someone could tell me which SIP softphone I can use with OpenSER that supports presence en IM??? regards, Kc

2 1

[Users] new set of modules: presence user agent client implementations
by Daniel-Constantin Mierla 07 Dec '06

07 Dec '06

Hello everybody, during last week a new set of modules have been introduced to CVS repository. They are prefixed with 'pua' which stands for 'presesece user agent'. There is one module actually having the name 'pua', which implements the common API needed by other modules from this category. At this moment there are two modules which behave as presence user agent for user location records (pua_usrloc) and presence user agent for external applications which can use new management interface (MI - via FIFO file or XMLRPC) to publish details -- this module is named pua_mi. Next step in this direction will be implementation of PUA for xmpp. With pua_usrloc module you can configure OpenSER to publish online/offline status in behalf of SIP devices registered to OpenSER but not supporting presence extensions. The users which have phones supporting presence extension can see if the other users are registered or not. pua_mi module is one very interesting. It enables external applications to publish presence information, through a FIFO file or XMLRPC at this moment. In this way, basically one adds SIMPLE support to whatever they need in a easy and comfortable manner. PUBLISH support is there, SUBSCRIBE is implemented but needs an outward communication channel from OpenSER while MI is inward. Having two new features in place (the MI and SIMPLE/Presence stuff), I though it may be more appealing to start trying and testing if some examples are made available. Therefore I created a dokuwiki page where you can find two shell scripts along with OpenSER configuration file. http://openser.org/dokuwiki/doku.php/presence:pua-modules One of the shell scripts publishes details from operating system: logged in users (U), system CPU usage(C), free memory (M) and load average (L). The other one publishes details gathered from OpenSER statistics: processed SIP requests (R), active transactions (T) and user location records (U). I think they are good examples to start with. I made two screenshots of XLite v3.0 subscribed to such presence information. http://www.openser.org/downloads/presence/xlite-openser-system.jpg http://www.openser.org/downloads/presence/xlite-openser-stats.jpg Readme files for these new modules: http://www.openser.org/docs/modules/1.2.x/pua.html http://www.openser.org/docs/modules/1.2.x/pua_mi.html http://www.openser.org/docs/modules/1.2.x/pua_usrloc.html We have a lot of new code in place, the testing is a very appreciated help you can give. Cheers, Daniel

2 2

[Users] Simplified multilateral peering for a lab environment
by Aaron Daubman 07 Dec '06

07 Dec '06

Greetings, I've found some decent documentation on secure multilateral peering for OpenSER, however I'm looking for something more simple. In a lab environment, I'm looking to set up four simulated geographically diverse networks all peering across a common backbone. Each of the four networks should have its own SIP registrar. What I'm looking for is a quick guide on how to allow each of the four registrars tell the other three what prefixes are registered with what address so that all SIP UAs can dial just an extension to reach UAs in any of the four networks. Right now I'd like to leave things unsecured if possible (no need for TLS). Also, if there are any good pointers for setting up the DNS in each of the four networks (each network will have its own DNS as well as SIP server) those would be useful. Finally, IPv4 references would be helpful, but seeing as this will be a v6-only setup, any reverences to IPv6 configuration guides regarding the above would be especially useful. Thanks again, ~Aaron

4 4

[Users] t_relay handling of r-URI, d-URI and Route URIs
by Klaus Darilion 07 Dec '06

07 Dec '06

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

2 1

[Users] OpenSer Sending CANCEL after receiving 200 OK for a INVITE
by Md. Samiul Aftad Chowdhury 07 Dec '06

07 Dec '06

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. .

2 2

[Users] Broken link for PUA_USRLOC
by Nicolas Palix 07 Dec '06

07 Dec '06

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/

2 1

RE: [Users] MediaProxy SER with AsteriskS
by Thomas Deillon 07 Dec '06

07 Dec '06

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

1 0

Jump to page:

2025

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