sr-users November 2008

sr-users@lists.kamailio.org

97 participants
170 discussions

[Kamailio-Users] 488 Not acceptable here

by Ricky Gutierrez

Hi list, I am giving him returned script from openser trying to find the problem to this message " 488 acceptable Not here" , I have my openser integrated recently with asterisk and the voicemail recently adds rtpproxy to solve problems of nat and was almost a success, some details to improve, but after adding the rtpproxy when I call to UAC and it does not answer the call on the telephone shows a 488 message to me No Aceptable, it does not jump to the voicemai.. I have 2 networks cards in my server, and looking at the sip log, I see twice in the sdp the interfaz it public any idea as solving this problem? regards rickygm # U +1.675624 192.168.10.1:5060 -> 192.168.10.1:5070 INVITE sip:u120@192.168.10.1:5070 SIP/2.0 Record-Route: <sip:192.168.10.1;lr=on;ftag=69372fe200a41663> Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.1 Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1> Contact: <sip:119@192.168.10.28:5060;nat=yes;nat=yes> Supported: replaces, timer, path Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Grandstream GXV3000 1.1.3.14 Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK Content-Type: application/sdp Content-Length: 604 P-hint: inbound->inbound P-hint: Route[20]: Rtpproxy P-hint: Route[20]: Rtpproxy v=0 o=119 8000 8001 IN IP4 192.168.10.28 s=SIP Call c=IN IP4 192.168.1.64192.168.1.64 t=0 0 m=audio 3504835048 RTP/AVP 18 4 3 2 0 101 a=sendrecv a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:3 GSM/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 3505035050 RTP/AVP 99 34 a=sendrecv a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=428014; packetization-mode=0; sprop-parameter-sets=Z0KADJWgUH5A,aM4CXID= a=rtpmap:34 H263/90000 a=fmtp:34 CIF=2 MaxBR=1280 a=framerate:20 a=nortpproxy:yes a=nortpproxy:yes # U +0.000052 192.168.10.1:5060 -> 192.168.10.27:5060 CANCEL sip:120@192.168.10.27:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.0 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 Call-ID: 7c55e4667d473f76(a)192.168.10.28 To: <sip:120@192.168.10.1> CSeq: 12216 CANCEL Max-Forwards: 70 User-Agent: OpenSER (1.3.2-notls (i386/linux)) Content-Length: 0 # U +0.000411 192.168.10.1:5070 -> 192.168.10.1:5060 SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.1;received=192.168.10.1 Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 # U +0.000120 192.168.10.1:5060 -> 192.168.10.1:5070 ACK sip:u120@192.168.10.1:5070 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.1 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 Call-ID: 7c55e4667d473f76(a)192.168.10.28 To: <sip:120@192.168.10.1>;tag=as4f1165d5 CSeq: 12216 ACK Max-Forwards: 70 User-Agent: OpenSER (1.3.2-notls (i386/linux)) Content-Length: 0 # U +0.000144 192.168.10.1:5060 -> 192.168.10.28:5060 SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 P-hint: Onreply-route - fixcontact # U +0.000787 192.168.10.27:5060 -> 192.168.10.1:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.0 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=fb538483d0333de1 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 CANCEL User-Agent: Grandstream GXV3000 1.1.3.14 Supported: replaces, timer, 100rel, path Content-Length: 0 # U +0.000544 192.168.10.27:5060 -> 192.168.10.1:5060 SIP/2.0 487 Request Cancelled Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.0 Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 Record-Route: <sip:192.168.10.1;lr=on;ftag=69372fe200a41663> From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=fb538483d0333de1 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Grandstream GXV3000 1.1.3.14 Content-Length: 0 # U +0.000067 192.168.10.1:5060 -> 192.168.10.27:5060 ACK sip:120@192.168.10.27:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.0 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 Call-ID: 7c55e4667d473f76(a)192.168.10.28 To: <sip:120@192.168.10.1>;tag=fb538483d0333de1 CSeq: 12216 ACK Max-Forwards: 70 User-Agent: OpenSER (1.3.2-notls (i386/linux)) Content-Length: 0 # U +0.001390 192.168.10.28:5060 -> 192.168.10.1:5060 ACK sip:120@192.168.10.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.28:5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Contact: <sip:119@192.168.10.28:5060> Proxy-Authorization: Digest username="119", realm="192.168.10.1", algorithm=MD5, uri="sip:120@192.168.10.1", nonce="4919edaf0a873106bfd0b18f347709360f00f7eb", response="a5a26c257b491718def2b43488a39853" Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 ACK User-Agent: Grandstream GXV3000 1.1.3.14 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK Content-Length: 0 # U +0.497023 192.168.10.1:5060 -> 192.168.10.28:5060 SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 P-hint: Onreply-route - fixcontact # U +0.999813 192.168.10.1:5060 -> 192.168.10.28:5060 SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 P-hint: Onreply-route - fixcontact exit 67 received, 0 dropped

15 years, 6 months

[Kamailio-Users] issues with rtpproxy and kamailio

by Fabian Borot

I am trying to set up rtpproxy with kamailio and are having these 2 issues: 1- the BYEs are not relayed to the other party, I have to hang up the call at both ends 2- kamailio receives the INVITE from the calling party [behind a nat] and relays it to the called party but the connection information in the SDP has to IPs [the source IP and the RTPproxy IP together c=IN IP4 204.9.239.6765.111.185.187 user 100 is behind a NAT and user 101 is not but I want to force the RTPs to go thru the rtpproxy server [ in the same IP as kamailio] the good and weird thing is that there is audio both ways. this is my config file: if (loose_route()) { # mark routing logic in request xlog("L_INFO","mylog: Loose Route section. Method: [$rm].\n"); append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER") { xlog("L_INFO","mylog: starting to process REGISTER.Info: [$au].\n"); if (!www_authorize("", "subscriber")) { xlog("L_INFO","mylog: REGISTER came without auth, sending challenge.\n"); www_challenge("", "0"); exit; }; if (nat_uac_test("1")){ xlog("L_INFO","mylog: REGISTER-Device behind NAT.\n"); fix_nated_register(); } force_rport(); save("location"); xlog("L_INFO","mylog: save-location successful.\n"); exit; } else if (method=="INVITE") { xlog("L_INFO","mylog: Processing INVITE.\n"); if (!proxy_authorize("","subscriber")) { xlog("L_INFO","mylog: INVITE came without auth, sending challenge.\n"); proxy_challenge("","0"); exit; }; consume_credentials(); if (nat_uac_test("1")){ xlog("L_INFO","mylog: INVITE-Device behind NAT.\n"); #fix_nated_contact(); fix_nated_sdp("10"); } force_rtp_proxy(); if (!lookup("location")) { sl_send_reply("404", "Not Found"); xlog("L_INFO","mylog: lookup-location failed, sending 404 Not Found. Method: [$rm].\n"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; }; route(1); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP t_on_reply("1"); if (t_relay()) { xlog("L_INFO","mylog: Route 1 section. Method [$rm]."); } else { sl_reply_error(); xlog("L_INFO","mylog: Route 1 section. T_Relay failed. Method [$rm]."); }; exit; } onreply_route[1] { force_rtp_proxy("","65.111.185.187"); } thank you in advance Fabian _________________________________________________________________ Stay up to date on your PC, the Web, and your mobile phone with Windows Live http://clk.atdmt.com/MRT/go/119462413/direct/01/

15 years, 6 months

[Kamailio-Users] problem with fix_nated_register() function

by Fabian Borot

Hello, I am having probs with the fix_nated_register() function, I still see the private IP, even thought the nat_uac_test(31) shows the user behind a NAT This is the REGISTER section in kamailio.cfg: if (method=="REGISTER") { xlog("L_INFO","mylog: starting to process REGISTER.Info: [$au].\n"); if (!www_authorize("", "subscriber")) { xlog("L_INFO","mylog: REGISTER came without auth, sending challenge.\n"); www_challenge("", "0"); exit; }; if (nat_uac_test("31")){ xlog("L_INFO","mylog: Device behind NAT.\n"); fix_nated_register(); force_rport(); } save("location"); xlog("L_INFO","mylog: save-location successful.\n"); exit; this is the debug log [level 6], it shows the via with a public IP Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: mylog: starting to process REGISTER.Info: [100]. Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth:check_nonce: comparing [491a03a9000000041ba5231fd93870c44415f01d1a0d1963] and [491a03a9000000041ba5231fd93870c44415f01d1a0d1963] Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_new_result: allocate 28 bytes for result set at 0x81ab8a0 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_allocate_columns: allocate 4 bytes for result names at 0x81a7288 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_allocate_columns: allocate 4 bytes for result types at 0x81a7258 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_get_columns: allocate 8 bytes for RES_NAMES[0] at 0x81a7268 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x81a7268)[0]=[password] Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_convert_rows: allocate 8 bytes for rows at 0x81a7278 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_convert_row: allocate 20 bytes for row values at 0x81ab880 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_str2val: converting STRING [100] Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth_db:get_ha1: HA1 string calculated: e8f9a8a478e49a182e9cceeb3e43277f Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth:check_response: our result = '84a320db7e04e3ddd3ef84a5173187cd' Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth:check_response: authorization is OK Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth:post_auth: nonce index= 4 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_columns: freeing 1 columns Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x81a7268 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_columns: freeing result names at 0x81a7288 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_columns: freeing result types at 0x81a7258 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_rows: freeing 1 rows Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_row: freeing row values at 0x81ab880 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_rows: freeing rows at 0x81a7278 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_result: freeing result set at 0x81ab8a0 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:check_via_address: params 204.9.239.67, 192.168.1.108, 0 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: mylog: Device behind NAT. Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:parse_headers: flags=ffffffffffffffff Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:parse_headers: flags=8000000 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:registrar:build_contact: created Contact HF: Contact: <sip:100@192.168.1.108 7566;rinstance=89990b40ab560825>;expires=3341, <sip:100@192.168.1.108:44568;rinstance=f0942ae1a596ea83>;expires=3597 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:parse_headers: flags=ffffffffffffffff Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:check_via_address: params 204.9.239.67, 192.168.1.108, 0 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: mylog: save-location successful. Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:destroy_avp_list: destroying list 0xb60e11c0 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:receive_msg: cleaning up and this is how the AOR is stored in the location db [ private IP] [root@sp1094a kamailio]# ../../sbin/kamctl ul show database engine 'MYSQL' loaded Control engine 'FIFO' loaded entering fifo_cmd ul_dump Domain:: location table=512 records=1 max_slot=1 AOR:: 100 Contact:: sip:100@192.168.1.108:44568;rinstance=f0942ae1a596ea83 Q= Expires:: 3365 Callid:: 7a32d234b04d4b69M2IzODRhODkwM2M5NTM0MzUwMGM4ODY3NTgzYzFjMmE. Cseq:: 2 User-agent:: eyeBeam release 1003l stamp 30937 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:65.111.185.187:5060 Methods:: 5951 FIFO command was: :ul_dump:openser_receiver_14270 [root@sp1094a kamailio]# Am I missing something? Thanks in advance Fabian _________________________________________________________________ Get 5 GB of storage with Windows Live Hotmail. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_11…

15 years, 6 months

[Kamailio-Users] Tomcat won't start serMyAdmin - SEVERE: Error listenerStart

by rjreb

I'm trying to install serMyAdmin but it refuses to start. In the logs I see the following: Nov 12, 2008 2:25:31 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive serMyAdmin.war Nov 12, 2008 2:25:34 AM org.apache.catalina.core.StandardContext start SEVERE: Error listenerStart Nov 12, 2008 2:25:34 AM org.apache.catalina.core.StandardContext start SEVERE: Context [/serMyAdmin] startup failed due to previous errors I've been searching for this for a day now and I can't find where anyone else is having this problem. Any suggestions? Debian Etch Sun Java 1.5.0-16-3 Tomcat 6.0.16 -- View this message in context: http://www.nabble.com/Tomcat-won%27t-start-serMyAdmin---SEVERE%3A-Error-lis… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

15 years, 6 months

[Serusers] Is msilo module necessary to make IM work in SER? SER doesn't forward MESSAGE

by lin9k＠yahoo.com

Hi, I used two IM (SIMPLE based) clients to communicate through SER. However, I could only see clients kept sending MESSAGE to SER but SER never forwarded them to the peer. I was not using msilo. I am not sure if that's the cause that SER didn't forward to the other end. Or, do I need any special configuration in ser.cfg, or any different version of SER? I was using ser-0.9.6. Thanks in advance! Ling

15 years, 6 months

[Serusers] compiling ser from source in ubuntu

by amar mahmoud

Hi, when i compile SER from the debian packages embedded with ubuntu it works fine, but i want to compile from the source because i want to add one module i have invented. my problem is : when i compile from source mysql module does not get compiled, i have tried to change the Makefile and delete mysql module from those excluded modules, also i have tried to compile it alone with the command: make modules=modules/mysql modules but still there is problem. does any one met that before. thanks Amar _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster…

15 years, 6 months

[Kamailio-Users] Dialog profile persistence - DB vs. memory.

by Alex Balashov

Greetings, Is some of the dialog profile information kept in in-memory structures inside the Kamailio instance even when one is using a database? I am using the dialog module in an HA configuration and fail over the database and proxy between two machines. The database and the proxy are both started on the secondary node during failover, and the database uses on-disk data and indices on a shared filesystem. What I am finding is that if I initiate some dialogs on the primary and then trigger the failover, the proxy on the secondary node is not aware of them. I see the entries for them in the database table from the secondary node - they're definitely there, and I am using db_mode 1 (real-time). However, the profile sizes are all showing as 0. I have also tried it with different match_modes with the same results whether I am using the RR cookie or SIP attributes purely. It's rather important that I get this working because I require dialog tracking for secure loose-routing of subsequent (non-initial) in-dialog requests and for concurrent call limit control. I was imagining that storing all the dialog info in the database would create the necessary persistence layer for another proxy instance to have the exact same profile information as the first. Is this a bug, or is it supposed to work this way? Cheers, -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

15 years, 6 months

[Kamailio-Users] question about register

by Fabian Borot

Hello I am having an issue handling UN-REGISTERs. This is my config file: route{ xlog("L_INFO", "mylog: starting_main_logic.\n"); if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); xlog("L_INFO","mylog: Too Many Hops.\n"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); xlog("L_INFO","mylog: Message too big.\n"); exit; }; if (!method=="REGISTER") { xlog("L_INFO","mylog: Recording Route. Method: [$rm].\n"); record_route(); } if (loose_route()) { # mark routing logic in request xlog("L_INFO","mylog: Loose Route section. Method: [$rm].\n"); append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER" && (!search("expires=0"))) { xlog("L_INFO","mylog: starting to process REGISTER.Info: [$au].\n"); if (!www_authorize("", "subscriber")) { xlog("L_INFO","mylog: REGISTER came without auth, sending challenge.\n"); www_challenge("", "0"); exit; }; save("location"); xlog("L_INFO","mylog: save-location successful.\n"); exit; } else if (method=="INVITE") { xlog("L_INFO","mylog: Processing INVITE.\n"); if (!proxy_authorize("","subscriber")) { xlog("L_INFO","mylog: INVITE came without auth, sending challenge.\n"); proxy_challenge("","0"); exit; }; consume_credentials(); }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); xlog("L_INFO","mylog: lookup-location failed, sending 404 Not Found. Method: [$rm].\n"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (t_relay()) { xlog("L_INFO","mylog: Route 1 section. Method [$rm]."); } else { sl_reply_error(); xlog("L_INFO","mylog: Route 1 section. T_Relay failed. Method [$rm]."); }; exit; } I added the "&& (!search("expires=0"))" to make sure that only the REGISTER requests will be processed by the next lines and the AOR will be saved in those cases. The X-lite sends "expires=0" in the Contact HF when it is unregistering. This is how the processing of a REGISTER looks like as per my code: Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting_main_logic. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting to process REGISTER.Info: [<null>]. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: REGISTER came without auth, sending challenge. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting_main_logic. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting to process REGISTER.Info: [101]. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: save-location successful. and when the phone UN-REGISTERs this is what I see: Nov 10 12:33:17 sp1094a ../../sbin/kamailio[26069]: mylog: starting_main_logic. Nov 10 12:33:17 sp1094a ../../sbin/kamailio[26069]: mylog: lookup-location failed, sending 404 Not Found. Method: [REGISTER]. My question is, do I need to use the lookup section for REGISTERs and UN-REGISTERs? If I comment out that part this is how the log looks like: #if (!lookup("location")) { # sl_send_reply("404", "Not Found"); # xlog("L_INFO","mylog: lookup-location failed, sending 404 Not Found. Method: [$rm].\n"); # exit; #}; log: the 1st part [REGISTER] looks the same [root@sp1094a kamailio]# tail -f /var/log/kamailio_logs | grep mylog Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting to process REGISTER.Info: [<null>]. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: REGISTER came without auth, sending challenge. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting to process REGISTER.Info: [101]. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: save-location successful. and this is what the log shows when the phone is UN-REGISTERING Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: Message too big. [root@sp1094a kamailio]# Regards Fabian _________________________________________________________________ Stay up to date on your PC, the Web, and your mobile phone with Windows Live http://clk.atdmt.com/MRT/go/119462413/direct/01/

15 years, 6 months

[Kamailio-Users] sip router meeting in Karlsruhe

by Daniel-Constantin Mierla

Hello, because of taking several days off, a complete report might show up a bit later, apologizes for that. Now a (short) summary... First, many thanks thanks to 1&1 for hosting the event and everyone that participated in such short notice. There were representatives from 10 companies: - 1&1 - FhG Fokus - Telio - Asipto - iptelorg/Tekelec - Voztelecom - Iptego - Itsyscom - Longphone - Basis AudioNet Some pictures should be published in the near future. After going in short introduction and presentation of the goals from the point of view of each project, we focused on: - identification of potential points of conflicts and how to get to a resolution in such case - code integration for common layer of the first phase - future development and proposals of new features - management of the larger eco-system that includes related projects and business entities I will send several emails detailing what was discussed and proposed there in few days. meanwhile, the outlines: - it is hard to avoid conflicts just by some clear and strict rules, so the common sense should lead the collaboration and discussions - GIT repository should be up in several days so the work can start, with a time line of 2-3 months from now to get core and tm in a very good shape of integration - another meeting shall be set in about 3 months time, to allow enough time for people to be able to attend, adjust the development and look more deep at the future. While the a lot of focus in the next months will be on integration, development of new features won't stop -- for examples, steps to a partial asynchronous processing are undertaking, couple of new modules are planned for release, several other modules to bring new functionalities - we should encourage and promote the development of related applications, like web interfaces, management tools, applications servers -- the add value for community and business Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

15 years, 6 months

[Kamailio-Users] irc devel meeting summary

by Daniel-Constantin Mierla

Hello, sorry for delay... but better later than never, so I am trying to summarize the outcome of the IRC devel meeting from last Thursday, Nov 06, 2008. The log is available at: http://www.kamailio.org/dokuwiki/doku.php/development:irc-meeting-minutes-0… Regarding the 1.3.x series, we set the 2oth of November as the date for 1.3.4 release. There are several fixes and this branch is still used in many production environments, so it worths investing time in it. There are some updates in 1.4.x to be ported and some issues to be investigated. For a new 1.4.x release (the 1.4.3) we look for the beginning of December as the time frame for setting the date of the release. The 1.5.x rises in the first phase the question of a shorter time release, as we have lot of new features already implemented, see: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x http://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x Unfortunately some of the new features are not completed yet (e.g., htable, carrierroute updates, PV migration) so we will stick to 6-8 months release cycle. The next major one that will use the common layer (core and tm) from sip-router could be done in a shorter time than usual. So, beginning to mid of January should be the time to freeze the code for a release date somewhere in end of January or February. An important aspect approached during the discussions was the release management and testing management. Perhaps we need to appoint a person to manage releasing process in order to have a better synchronization of the developers. As everyone agrees, testing is very important and we try to improve it. There is a testing suite included in the source tree right now, used for static testing. The idea of a dynamic testing and testing community was introduced and hopefully we can attract people and build a group of beta testers. There is a proposal of how to implement and what to take care of, probably this one has to continue on devel and users mailing lists for a proper organizational structure. GIT became as a subject of migrating from SVN, because of its features for a distributed development environment. However, sourceforge does not have such offerings, so it is not possible now anyhow. However the sip-router.org will use it. Regarding the sip-router.org project, we focused on short term goals, acknowledging that we have several modules offering same functionality but relying on different underlaying data structures, this have to co-exists for a longer time. For the first phase, core + tm the overlapping is rather small, the two projects insisting in the past to improve different aspects of them. Unfortunately I forgot to bring up some punctual topics proposed, mainly related to tm failure route calling in case of sending error and reply handling/dropping in onreply_routes. We can continue those subjects on the mailing lists. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

15 years, 6 months

← Newer
1
...
8
9
10
11
12
13
14
...
17
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 November 2008