sr-users February 2010

sr-users@lists.kamailio.org

59 participants
109 discussions

Number Portability Functionality
by Asim Riaz 17 Feb '10

17 Feb '10

Hi list, Can someone explain me about PDB server? what I understand that PDB server have all the routing information for all the numbers and SIP-Router receive that information and route the call accordingly but how PDB server receive the routing data? Do we need to load this routing data manually? What happen if the routing information for a number is changed, do we need to update manually? Thanks, Asim

3 2

[Kamailio-Users] Inbound call no way audio
by RAJNIKANT VANZA 17 Feb '10

17 Feb '10

Hi Friends, Outbound calling works fine. When I receive an inbound call, the phone rings, but when I pick up the phone, the conversation does not get established. I have call from inside NAT extension number to Outside NAT extension ( Outboud call ) then call get established and two-way audio work fine but when I have call from Outside NAT extension to Inside NAT extension (Inbound call ) then phone rings, but when pickup the phone, audio is not present. During inboud call RTP packets are not transmit whereas Outboud call RTP packets transmit successful. Sometimes, Inbound and Outbound call only one-way audio present. Can anybody help me, or point me to a previous thread where this issue was discussed and solved? Thanks in advance. -- Best Regards, Rajnikant Vanza

2 4

[Kamailio-Users] What is the best (and secure) way to change FROM_URI using regexp?
by Fernando Frota M Morais 16 Feb '10

16 Feb '10

Before sending this message I looked for an answer and found some options, two of them are followed: 1) SUBST function, sample listed here: if (is_present_hf("User-Agent")) { remove_hf("User-Agent"); remove_hf("P-Asserted-Identity"); subst("/^From: \".+\" (<sip: *[a-zA-Z0-9_\.-]+ <at> .*>)/From: \1/ig"); subst("/^To: \".+\" (<sip: *[a-zA-Z0-9_\.-]+ <at> .*>)/To: \1/ig"); } 2-a) uac_replace: if (from_uri=~"^sip:10804007\@voip.mydomain") { xlog("L_ALERT", "TESTANDO - Original From is ($fu-$fn)\n"); # uac_replace_from("sip:031" . $fU . "\(a)voip.mydomain"); uac_replace_from("Frota10804007","sip:03110804007@voip.mydomain"); xlog("L_ALERT", "TESTANDO - From changed to ($fu-$fn)\n"); }; OR : 2-b) uac _replace #2: if (from_uri=~"^sip:10804007\@.*") { xlog("L_ALERT", "Route 21 - Original from is ($fu-$fn)\n"); $avp(from)=$fu; # $avp(to)=$ru; # avp_pushto("$ru", "$avp(from)"); avp_subst("$avp(from)", "/(sip:)/sip:031/"); uac_replace_from("$avp(from)"); # xlog("L_ALERT", "Route 21 - From changed to ($fu-$fn)\n"); # avp_pushto("$ru", "$avp(to)"); }; } OR Looks like uac_replace is safer then "subst" function, because it can be reverted, but I did not found a way to use concatenation or any other kind of string operation as a parameter for it. I don't want to start a discussion, I need only a few lines showing me how to change from_uri_from from "sip:108xxxx" to "sip:031108xxxx". Thanks in advance, -- Fernando Frota Machado de Morais Divisao de Redes de Comunicacao Centro de Computacao Universidade Federal de Minas Gerais Brasil Tel. +55(31)3409.4007 Fax. +55(31)3409.4004

2 1

[Kamailio-Users] What is wrong with this NOTIFY packet
by Asterisk User 15 Feb '10

15 Feb '10

Hi Group, I know this issue has to do bit more with SIP and off from kamailio problems, but just wanted to know your opinions on this. I have my sip extensions registered to kamilio and Asterisk works as a voicemail server. Now to implement MWI i send NOTIFY packet from Asterisk to Kamailio and from kamailio to SIP extension (Grandstream GXP2000). here is the packet that travels from kamailio to extension and the response sent from extension to kamilio. =========================== NOTIFY sip:1111111@arzoo.com <sip%3A1111111(a)arzoo.com> SIP/2.0 Max-Forwards: 10 Record-Route: <sip:172.18.100.74;lr;nat=yes> Via: SIP/2.0/UDP 172.18.100.74;branch=z9hG4bK3c3.e1003f03.0 Via: SIP/2.0/UDP 127.0.0.1:45382 ;received=172.18.100.73;branch=z9hG4bK.4f83530d;rport=45382;alias Via: SIP/2.0/UDP 172.18.100.73:5060 From: <sip:111@arzoo.com <sip%3A111(a)arzoo.com>> To: <sip:1111111@arzoo.com <sip%3A1111111(a)arzoo.com>> Contact: <sip:1111111@arzoo.com <sip%3A1111111(a)arzoo.com>> Call-ID: 4d61cf9e505d40e905032a18329d61ec(a)172.19.100.42 CSeq: 1 NOTIFY User-Agent: VoiceMail Event: message-summary Content-Type: application/simple-message-summary Content-Length: 39 =========================== SIP/2.0 415 Unacceptable Content-Type Via: SIP/2.0/UDP 172.18.100.74;branch=z9hG4bK3c3.02003f03.0 Via: SIP/2.0/UDP 127.0.0.1:43416 ;received=172.18.100.73;branch=z9hG4bK.7be73901;rport=43416;alias Via: SIP/2.0/UDP 172.18.100.73:5060 Record-Route: <sip:172.18.100.74;lr;nat=yes> From: <sip:111@arzoo.com <sip%3A111(a)arzoo.com>> To: <sip:1111111@arzoo.com <sip%3A1111111(a)arzoo.com>>;tag=3c6ba3e4a93d6864 Call-ID: 4d61cf9e505d40e905032a18329d61ec(a)172.19.100.42 CSeq: 1 NOTIFY User-Agent: Grandstream GXP2000 1.1.4.14 Accept: application/sdp, application/simple-message-summary, application/octet-stream, application/dialog-info+xml, application/pidf+xml, message/sipfrag;version=2.0 Content-Length: 0 =========================== Please guide me in right direction to get rid of 'Unacceptable Content-Type' problem. Thanks in advance, --SM

5 10

[Kamailio-Users] Problems with parallel forking to different users
by Anton Roman 15 Feb '10

15 Feb '10

Hi all, I'm trying to implement parallel forking to different users registered on a Kamailio server. I want to fork the call to a number of different users (not including the called user). To do this I added the piece of code below to the default 3.0.0 config file: ... # account only INVITEs if (is_method("INVITE")) { setflag(1); # do accounting setflag(4); #dialog aware if(avp_db_load("$ru/username","$avp(s:fork)")) { avp_pushto("$ru/username","$avp(s:fork)/g"); }; } .... This is usr_preference table content: +----+------+----------+--------+-----------+------+-------+---------------------+ | id | uuid | username | domain | attribute | type | value | last_modified | +----+------+----------+--------+-----------+------+-------+---------------------+ | 4 | | 1000 | | fork | 0 | 1001 | | | 3 | | 1000 | | fork | 0 | 1005 | | +----+------+----------+--------+-----------+------+-------+---------------------+ Kamailio correctly forks the call to 1001 and 1005, but the Request-URI of the 1005 user is not correctly set, because the proxy IP is used instead of the IP where the user is registered (10.1.2.15). You can see the INVITEs below. Could anybody tell me what I'm doing badly? Thanks for your time, best regards Anton ---------------------------------------------------------------------------------------------------------------------------------------- # U +0.000328 10.1.20.103:5060 -> 10.1.3.18:5061 INVITE sip:1001@10.1.3.18:5061 SIP/2.0 Record-Route: <sip:10.1.20.103;lr=on;did=c34.3ed81d77> Via: SIP/2.0/UDP 10.1.20.103;branch=z9hG4bKc40b.ec3572a3.0 Via: SIP/2.0/UDP 10.1.3.15:5061;branch=z9hG4bK-213aa77 From: "1002" <sip:1002@10.1.20.103 <sip%3A1002(a)10.1.20.103> >;tag=280da520d15d62cfo1 To: "1000" <sip:1000@10.1.20.103 <sip%3A1000(a)10.1.20.103>> Call-ID: 8973c34-427096cb(a)10.1.3.15 CSeq: 102 INVITE Max-Forwards: 69 Contact: "1002" <sip:1002@10.1.3.15:5061> Expires: 240 User-Agent: Linksys/SPA941-5.1.5 Content-Length: 202 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: replaces Content-Type: application/sdp v=0 o=- 2003696 2003696 IN IP4 10.1.3.15 ... # U +0.000052 10.1.20.103:5060 -> 10.1.20.103:5060 INVITE sip:1005@10.1.20.103 <sip%3A1005(a)10.1.20.103> SIP/2.0 Record-Route: <sip:10.1.20.103;lr=on;did=c34.3ed81d77> Via: SIP/2.0/UDP 10.1.20.103;branch=z9hG4bKc40b.ec3572a3.1 Via: SIP/2.0/UDP 10.1.3.15:5061;branch=z9hG4bK-213aa77 From: "1002" <sip:1002@10.1.20.103 <sip%3A1002(a)10.1.20.103> >;tag=280da520d15d62cfo1 To: "1000" <sip:1000@10.1.20.103 <sip%3A1000(a)10.1.20.103>> Call-ID: 8973c34-427096cb(a)10.1.3.15 CSeq: 102 INVITE Max-Forwards: 69 Contact: "1002" <sip:1002@10.1.3.15:5061> Expires: 240 User-Agent: Linksys/SPA941-5.1.5 Content-Length: 202 Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER Supported: replaces Content-Type: application/sdp v=0 o=- 2003696 2003696 IN IP4 10.1.3.15 ... ----------------------------------------------------------------------------------------------------------------------------------------

2 1

[Kamailio-Users] Registration Timeout Retransmission
by Hemanshu Patel 13 Feb '10

13 Feb '10

Hello to all users, I am very new to kamailio and just started using it. I have installed it and my phones are getting register successfully. But sometimes i am seeing a scenario, which makes my phones unusable for sometime. please see the condition as below | phone |--------------| Kamailio | | REGISTER-----------------> <----------------------401 | REGISTER-----------------> Tricky condition here | timeout <--------------200 OK phone shows itself as unregistered | REGISTER----------------> <--------------------401 After several retries phone stops to retry till say next 20 seconds, during that time though there's an entry in location table in kamailio (i am using mysql) my phone shows itself as unregistered phone. Due to load or any other conditions Server takes a bit time to send 200OK back to phone and During that time timer expires and phone sends REGISTER once again. now phone will keep sending REGISTER request with same nonse and other value, and kamailio is configured to not to entertained same credentials with nonce if it is authenticated once. So kamailio generates new 401 Message with new nonce value to which phone understands as the previous reply thet he send for previous 401 was rejected, and the most probable reason is wrong user credentials..... Hope you guys have got my problem? i can not allow kamailio to let use the same credentials+ response with nonce if it has used it once for security reason. Then what could be the solution for this. I am very good in Programming, but just that i have just started to use kamailio and not very much aware about its architecture. -- Regards, Hemanshu Patel M: 09601295238

3 5

[Serusers] stateful statistics
by Sabatella, Michael 12 Feb '10

12 Feb '10

I know somebody else posted this a while ago but I did not see any response. I tried to research it but could not come up with any answers and would like to get an understanding of this . On the stateful statistics what does 130 waiting and 6 current mean Stateful Statistics Current: 6 (130 waiting) Total: 3540496 (0 local) Replied localy: 3809867 Is it recommended to restart the process once a week or once a month? I am running ser 0.9.6 Thanks for the help. Michael ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

1 0

[Kamailio-Users] Error in header - where and how?
by Anders 12 Feb '10

12 Feb '10

Hi, My carrier doesn't like the invites that come from two specific customers I have, who both use something called VoipSwitch. It returns from the carrier as a Bad Request. Below is the dialog - I'm not sharp enough to see what's wrong - anyone? Thanks! //Anders U 2010/02/01 17:53:42.355689 CustomerIP:5060 -> MyProxyIP:5060 INVITE sip:890912551128650136@MyProxyIP SIP/2.0. CSeq: 1 INVITE. Via: SIP/2.0/UDP CustomerIP:5060;branch=z9hG4bk01025810150801381470578. From: "SERVER BR" <sip:001184517324@CustomerIP:5060>;tag=010258101508381470562. Call-ID: GW6d4c945d2c573c27@CustomerIP. To: <sip:890912551128650136@MyProxyIP>. Contact: <sip:CustomerIP:5060;transport=udp>. Content-Type: application/sdp. Content-Length: 250. Remote-Party-ID: "SERVER BR"<sip:69912390@customerDNS>;privacy=off;screen=no. . v=0. o=VoipSwitch 9298 9298 IN IP4 CustomerIP. s=VoipSIP. i=Audio Session. c=IN IP4 CustomerIP. t=0 0. m=audio 8298 RTP/AVP 18 101. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. U 2010/02/01 17:53:42.355990 MyProxyIP:5060 -> CustomerIP:5060 SIP/2.0 100 Giving a try. CSeq: 1 INVITE. Via: SIP/2.0/UDP CustomerIP:5060;branch=z9hG4bk01025810150801381470578;rport=5060;received=187.45.218.17$ From: "SERVER BR" <sip:001184517324@CustomerIP:5060>;tag=010258101508381470562. Call-ID: GW6d4c945d2c573c27@CustomerIP. To: <sip:890912551128650136@MyProxyIP>. Server: Kamailio. Content-Length: 0. . U 2010/02/01 17:53:42.356010 MyProxyIP:5060 -> CarrierIP:5060 INVITE sip:84370551128650136@CarrierIP:5060 SIP/2.0. Max-Forwards: 10. Max-Forwards: 5. Record-Route: <sip:MyProxyIP;lr=on;nat=yes;did=e4c.e1f33ad5>. CSeq: 1 INVITE. Via: SIP/2.0/UDP MyProxyIP;branch=z9hG4bK139a.a74691c5.0. Via: SIP/2.0/UDP CustomerIP:5060;rport=5060;received=CustomerIP;branch=z9hG4bk0102581015080138147057$ From: "SERVER BR" <sip:001184517324@CustomerIP:5060>;tag=010258101508381470562. Call-ID: GW6d4c945d2c573c27@CustomerIP. To: <sip:890912551128650136@MyProxyIP>. Contact: <sip:CustomerIP:5060;transport=udp>. Content-Type: application/sdp. Content-Length: 250. Remote-Party-ID: "SERVER BR"<sip:69912390@customerDNS>;privacy=off;screen=no. . v=0. o=VoipSwitch 9298 9298 IN IP4 CustomerIP. s=VoipSIP. i=Audio Session. c=IN IP4 CustomerIP. t=0 0. m=audio 8298 RTP/AVP 18 101. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. U 2010/02/01 17:53:42.608917 CarrierIP:5060 -> MyProxyIP:5060 SIP/2.0 400 Bad Request. Via: SIP/2.0/UDP MyProxyIP;branch=z9hG4bK139a.a74691c5.0. Via: SIP/2.0/UDP CustomerIP:5060;rport=5060;received=CustomerIP;branch=z9hG4bk0102581015080138147057$ From: "SERVER BR" <sip:001184517324@CustomerIP:5060>;tag=010258101508381470562. To: <sip:890912551128650136@MyProxyIP>. Call-ID: GW6d4c945d2c573c27@CustomerIP. CSeq: 1 INVITE. Content-Length: 0.

2 4

[Kamailio-Users] Drouting Question
by Sven Schulz 12 Feb '10

12 Feb '10

Hello, Ive been testing Kamailio 3.0 and drouting. In the documentation it states (Section 1.5 Routing Rule Processing) ³The module will execute serial forking for each address in chain. The next address in chain is used only if the previously has failed.² What exactly defines a failure? Does it use ping or OPTIONS to determine if a GW is busy or down? Id like to know exactly how drouting figures this out. Sven Schulz Penn State University Telecommunications and Network Services 814.865.6116 sip:sven@psu.edu

3 4

[Kamailio-Users] acc module
by Denis Putyato 12 Feb '10

12 Feb '10

Hello everybody! I have a such problem with ACC module. Calls was accounted but only INVITE and BYE requests has appeared in acc table. ACK is absent. Kamailio 3.0 was installed from GIT. Thank you for any help loadmodule "db_mysql.so" loadmodule "mi_fifo.so" loadmodule "tm.so" loadmodule "sl.so" loadmodule "tmx.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "acc.so" loadmodule "avpops.so" loadmodule "siptrace.so" loadmodule "dialplan.so" loadmodule "lcr.so" loadmodule "sqlops.so" loadmodule "carrierroute.so" loadmodule "drouting.so" loadmodule "kex.so" # ----- acc params ----- modparam("acc", "early_media", 0) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 1) modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) modparam("acc", "failed_transaction_flag", 29) modparam("acc", "db_table_acc", "acc") modparam("acc", "db_table_missed_calls", "missed_calls") modparam("acc", "acc_method_column", "method") modparam("acc", "acc_from_tag_column", "from_tag") modparam("acc", "acc_to_tag_column", "to_tag") modparam("acc", "acc_callid_column", "callid") modparam("acc", "acc_sip_code_column", "sip_code") modparam("acc", "acc_sip_reason_column", "sip_reason") modparam("acc", "acc_time_column", "time") modparam("acc", "db_url", "xxxxxxxxxxxxxxxxxxxxxxxx") modparam("acc", "db_extra", "src_user=$avp(i:2);src_domain=$si;dst_ouser=$avp(i:1);dst_user=$rU;dst_doma in=$rd") route { sip_trace(); setflag(30); if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { setflag(1); setflag(29); } if (is_method("ACK")) { xlog("L_NOTICE", "ACK detected"); # I see this line in syslog setflag(1); setflag(29); } route("relay"); exit; } else { if ( is_method("ACK") ) { if ( t_check_trans() ) { setflag(1); route("relay"); exit; } else { exit; } } } }

1 0

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

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 February 2010