sr-users March 2013

sr-users@lists.kamailio.org

92 participants
142 discussions

FreeBSD build from git: i use that patch
by Victor V. Kustov 15 Mar '13

15 Mar '13

diff --git a/modules/ims_icscf/cxdx_lir.c b/modules/ims_icscf/cxdx_lir.c index faabd85..24686e7 100644 --- a/modules/ims_icscf/cxdx_lir.c +++ b/modules/ims_icscf/cxdx_lir.c @@ -51,6 +51,11 @@ #include "mod.h" #include "location.h" +#if defined (__OS_freebsd) +#include "sys/limits.h" +#define MAXINT INT_MAX +#endif + //we use pseudo variables to communicate back to config file this takes the result and converys to a return code, publishes it a pseudo variable int create_lia_return_code(int result) { int rc; diff --git a/modules/ims_icscf/scscf_list.c b/modules/ims_icscf/scscf_list.c index bd5216c..8b6b79c 100644 --- a/modules/ims_icscf/scscf_list.c +++ b/modules/ims_icscf/scscf_list.c @@ -47,6 +47,11 @@ #include "db.h" #include "../../lib/ims/useful_defs.h" +#if defined (__OS_freebsd) +#include "sys/limits.h" +#define MAXINT INT_MAX +#endif + extern int scscf_entry_expiry; //time for scscf entries to remain the scscf_list extern struct tm_binds tmb; //Structure with pointers to tm funcs -- SY, Victor JID: coyote(a)bks.tv JID: coyote(a)bryansktel.ru I use FREE operation system: 3.8.3-calculate GNU/Linux

3 4

registrar and check registered
by Victor V. Kustov 15 Mar '13

15 Mar '13

Hi. I try to use Kamailio 4.1 git version as registrar and PSTN gw. Need accept register from users. Its OK, I made it and use save() function - from keep registrations in case of kamailio restart. Need forward calls to gw, but only for registered users. If I understand correctly in INVITE enough check registered("location"), isnt it? but it's not work, i need verify auth again. Routing part of my config: route { # initial sanity checks - skip in letter # We are registrar! if (is_method("REGISTER")) { sl_send_reply("100", "Trying"); # send "Trying, dont threat on me if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging ## setbflag(FLB_NATSIPPING); } # we must check auth right now # WORK: if (!www_authorize("$fd", "subscriber")) if (!auth_check("$fd", "subscriber", "1")) { # WORK: www_challenge("$fd", "0"); auth_challenge("$fd", "0"); # send me requisites plz exit; } else { # ok. auth accepted, save in location if (save("location")) #if (save("location","0x04","$fd")) { xlog("L_WARN", "Save OK in location sip:$au@$fd"); } else { xlog("L_WARN", "Save FAIL in location sip:$au@$fd"); } } xlog("L_WARN", "REGISTERED method done"); exit; } if (is_method("INVITE")) { if ($si == $sel(cfg_get.pstn.gw_ip)) { # incoming calls xlog("L_WARN", "Incoming call"); } else { # outgoing calls xlog("L_WARN", "Outgoing call"); # check auth # we must check auth right now if (!proxy_authorize("$fd", "subscriber")) { proxy_challenge("$fd", "0"); exit; } consume_credentials(); ### THAT FUNCTIONS ALWAYS WRITE IN LOGS # "!registered" "!lookup" for both registered and unregged users # if (!registered("location")) xlog("L_WARN","!registered"); # if (!lookup("location")) xlog("L_WARN", "!lookup"); # number change - FIX late # check may be used dialplan automatically? # route $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); xlog("L_WARN", "Rewrite to $ru, send to PSTN."); if (!t_relay()) { sl_reply_error(); } } } else { # reply 2 keepalive and drop all # if (!t_relay()) { sl_reply_error(); } } } -- SY, Victor V. Kustov +7 (952) 966 76 24 JID: coyote(a)bks.tv JID: coyote(a)bryansktel.ru I use FREE operation system: 3.7.7-calculate GNU/Linux

2 3

UAC module and SRV records
by Olle E. Johansson 15 Mar '13

15 Mar '13

Hi! When using the UAC module to send a request to a domain that only exists in SRV records, I get an error message that no A or AAAA records can be found for the domain. Is this by design or possibly a bug? Anyone else that have seen this? /O

2 5

Problems with Mar portion of registration
by mrichardson 15 Mar '13

15 Mar '13

The MAR portion of registration is either not happening or failing causing scscf to die. Using Kamailio 4.0 with the ims_auth module. We're trying to determine what the REGISTER block should look like and what ims_auth parameters are necessary for a successful MAR challenge with auth vector delivery. We currently only get the UAR by ICSCF then the SAR by SCSCF. Module parameters: # -- ims_auth params -- modparam("ims_auth", "name", URI) modparam("ims_auth", "registration_default_algorithm", REG_AUTH_DEFAULT_ALG) modparam("ims_auth","ignore_failed_auth",0) #!ifdef CXDX_FORCED_PEER modparam("ims_auth", "cxdx_forced_peer", CXDX_FORCED_PEER) #!endif modparam("ims_auth", "cxdx_dest_realm", NETWORKNAME) modparam("ims_auth", "av_request_at_once", 1) modparam("ims_auth", "registration_qop", "auth") route[REGISTER] { xlog("L_ERR", "Enter register block"); t_newtran(); ims_www_authenticate(NETWORKNAME); #check to see if user is authenticated - ie sip header has auth information - (already challenged) if ($avp(maa_return_code) == 1) { # user has not been authenticated. Lets send a challenge via 401 Unauthorized ims_www_challenge("$td"); exit; } else { # We need to check if this user is registered or not if (!impu_registered("location")) { save("location"); if ($avp(saa_return_code) == 1) { isc_match_filter_reg("0","location"); exit; } } else { save("location"); if($avp(saa_return_code) == 1) { isc_match_filter_reg("1","location"); exit; } } } } 12(22978) INFO: cdp [receiver.c:910]: peer_connect(): Peer hss.ims.somecompany.com:3868 connected 0(22966) ERROR: <script>: Enter register block 0(22966) INFO: ims_registrar_scscf [cxdx_sar.c:79]: created AVP successfully : [saa_return_code] - [-2] 5(22971) INFO: ims_registrar_scscf [cxdx_avp.c:138]: cxdx_get_experimental_result_code: Failed finding avp 5(22971) INFO: ims_registrar_scscf [cxdx_sar.c:79]: created AVP successfully : [saa_return_code] - [1] 5(22971) WARNING: tm [t_lookup.c:1559]: WARNING: script writer didn't release transaction

2 1

A weird message looping scenario
by Ajay Sabat 15 Mar '13

15 Mar '13

Hi, We have an ugly message looping scenario where a SIP request message received at Kamailio is forwarded to the switch/router and back to Kamailio in a loop until the Max-forwards header value becomes 0 or the transaction times out. After receiving an incoming INVITE request from a local user, Kamailio forwards the INVITE request to another proxy located in a different network. The call is established successfully. During the call setup the external proxy sends an OPTIONS request to Kamailio (actually to the external public IP address from where it received INVITE request from Kamailio). The OPTIONS request arrives at Kamailio. But the request uri contains the mapped public address instead of the local ip address where Kamailio is listening. So Kamailio forwards the request to the public IP address (i.e. the switch) which again sends it back to Kamailio again and it keeps looping. Here is the message flow. 192.168.1.3 is the local user registered to Kamailio which is running at 192.168.1.5. IP address of the external proxy server is 10.139.90.161 and 10.139.90.137 is the public IP address of the switch/router. NAT isn't enabled at Kamailio. Internet Protocol Version 4, Src: 192.168.1.3 (192.168.1.3), Dst: 192.168.1.5 (192.168.1.5) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: INVITE sip:1002@video-conf SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.3:5060;rport;branch=z9hG4bK1941685709 From: "xxxx" <sip:1001@192.168.1.5>;tag=256977615 To: <sip:1002@video-conf> Call-ID: 1110783207 CSeq: 20 INVITE Contact: <sip:1001@192.168.1.3> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Max-Forwards: 70 User-Agent: Linphone/3.5.2 (eXosip2/3.6.0) Subject: Phone call Content-Length: 510 Message Body Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.3 (192.168.1.3) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 100 trying -- your call is important to us Message Header Via: SIP/2.0/UDP 192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709 From: "xxxx" <sip:1001@192.168.1.5>;tag=256977615 To: <sip:1002@video-conf> Call-ID: 1110783207 CSeq: 20 INVITE Server: kamailio (3.3.3 (i386/linux)) Content-Length: 0 Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 10.139.90.161 (10.139.90.161) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: INVITE sip:1002@vc-vcs-control.air2gnd.net SIP/2.0 Message Header Record-Route: <sip:192.168.1.5;lr=on> Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKd6e1.f7985e64.0 Via: SIP/2.0/UDP 192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709 From: "xxxx" <sip:1001@192.168.1.5>;tag=256977615 To: <sip:1002@video-conf> Call-ID: 1110783207 CSeq: 20 INVITE Contact: <sip:1001@192.168.1.3> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Max-Forwards: 69 User-Agent: Linphone/3.5.2 (eXosip2/3.6.0) Subject: Phone call Content-Length: 510 Message Body Internet Protocol Version 4, Src: 10.139.90.161 (10.139.90.161), Dst: 192.168.1.5 (192.168.1.5) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 100 Trying Message Header Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKd6e1.f7985e64.0;received=10.139.90.137 Via: SIP/2.0/UDP 192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709 From: "xxxx" <sip:1001@192.168.1.5>;tag=256977615 To: <sip:1002@video-conf> Call-ID: 1110783207 CSeq: 20 INVITE Content-Length: 0 Internet Protocol Version 4, Src: 10.139.90.161 (10.139.90.161), Dst: 192.168.1.5 (192.168.1.5) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 101 Dialog Establishement Message Header Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bKd6e1.f7985e64.0;received=10.139.90.137 Via: SIP/2.0/UDP 192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709 Record-Route: <sip:192.168.1.5;lr=on> From: "xxxx" <sip:1001@192.168.1.5>;tag=256977615 To: <sip:1002@ video-conf>;tag=689763673 Call-ID: 1110783207 CSeq: 20 INVITE Contact: <sip:1002@10.139.90.161:5060> Content-Length: 0 Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 192.168.1.3 (192.168.1.3) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 101 Dialog Establishement Message Header Via: SIP/2.0/UDP 192.168.1.3:5060;rport=5060;branch=z9hG4bK1941685709 Record-Route: <sip:192.168.1.5;lr=on> From: "xxxx" <sip:1001@192.168.1.5>;tag=256977615 To: <sip:1002@video-conf>;tag=689763673 Call-ID: 1110783207 CSeq: 20 INVITE Contact: sip:1002@10.139.90.161:5060 Content-Length: 0 P-Received: 10.139.90.137 Internet Protocol Version 4, Src: 10.139.90.161 (10.139.90.161), Dst: 192.168.1.5 (192.168.1.5) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: OPTIONS sip:10.139.90.137:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 10.139.90.161:5060;rport;branch=z9hG4bK231479102 From: "yyyy" <sip:1002@10.139.90.161>;tag=537974226 To: <sip:1001@192.168.1.5> Call-ID: 1856507851 CSeq: 20 OPTIONS Accept: application/sdp Max-Forwards: 70 Content-Length: 0 Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 10.139.90.137 (10.139.90.137) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: OPTIONS sip:10.139.90.137:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bK8ba7.fa94bab7.0 Via: SIP/2.0/UDP 10.139.90.161:5060;rport=5060;branch=z9hG4bK231479102 From: "yyyy" <sip:1002@10.139.90.100>;tag=537974226 To: <sip:1001@192.168.1.5> Call-ID: 1856507851 CSeq: 20 OPTIONS Accept: application/sdp Max-Forwards: 69 Content-Length: 0 Internet Protocol Version 4, Src: 10.139.90.137 (10.139.90.137), Dst: 192.168.1.5 (192.168.1.5) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: OPTIONS sip:10.139.90.137:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bK8ba7.fa94bab7.0 Via: SIP/2.0/UDP 10.139.90.161:5060;rport=5060;branch=z9hG4bK231479102 From: "uuuu" <sip:1002@10.139.90.100>;tag=537974226 To: <sip:1001@192.168.1.5> Call-ID: 1856507851 CSeq: 20 OPTIONS Accept: application/sdp Max-Forwards: 69 Content-Length: 0 Internet Protocol Version 4, Src: 192.168.1.5 (192.168.1.5), Dst: 10.139.90.137 (10.139.90.137) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: OPTIONS sip:10.139.90.137:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bK8ba7.0b94bab7.0 Via: SIP/2.0/UDP 192.168.1.5;received=10.139.90.137;branch=z9hG4bK8ba7.fa94bab7.0 Via: SIP/2.0/UDP 10.139.90.161:5060;rport=5060;branch=z9hG4bK231479102 From: "yyyy" <sip:1002@10.139.90.100>;tag=537974226 To: <sip:1001@192.168.1.5> Call-ID: 1856507851 CSeq: 20 OPTIONS Accept: application/sdp Max-Forwards: 68 Content-Length: 0 Internet Protocol Version 4, Src: 10.139.90.137 (10.139.90.137), Dst: 192.168.1.5 (192.168.1.5) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Session Initiation Protocol Request-Line: OPTIONS sip:10.139.90.137:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bK8ba7.0b94bab7.0 Via: SIP/2.0/UDP 192.168.1.5;received=10.139.90.137;branch=z9hG4bK8ba7.fa94bab7.0 Via: SIP/2.0/UDP 10.139.90.161:5060;rport=5060;branch=z9hG4bK231479102 From: "yyyy" <sip:1002@10.139.90.100>;tag=537974226 To: <sip:1001@192.168.1.5> Call-ID: 1856507851 CSeq: 20 OPTIONS Accept: application/sdp Max-Forwards: 68 Content-Length: 0 This message forwarding goes on for a long time in a loop, each time with an extra Via header and Max-Forwards value decremented by one. After sometime it eventually times out and Kamailio starts sending 408 response for the OPTIONS request which again keeps looping. Probably adding an alias for the public IP address i.e., 10.139.90.137 in the Kamailio config file would solve the problem. But this IP address is not fixed and may change and I guess there is no way Kamailio can learn the public IP address on its own. Any help or reference to previous posts if it is already discussed and solved will be much helpful. Regards, Ajay

2 1

What factor determine NATed or not ?
by Khoa Pham 15 Mar '13

15 Mar '13

Hi, When we send REGISTER or INVITE to Kamailio, which part of the request message does Kamailio use to determine if client is NATed or not ? -- Khoa Pham HCMC University of Science Faculty of Information Technology

2 2

search_hf returns always true
by Ajay Sabat 15 Mar '13

15 Mar '13

Hi, I want to check whether a parameter exists in a header and I am using the search_hf() function defined in textops module. I am surprised that is always returning true whether the searched pattern exists or not. To be specific, I need to check if the "received" parameter exists in the top most via header and this is how I do it. The statements inside the if block get executed all the time irrespective of whether the received parameter exists in the top most via or not. Any help what am I doing wrong here? if (search_hf("Via", "received=", "f")) { xdbg("received param $sel(via.received) in top most via header \n"); # perform necessary action } Case 1: no received parameter in via Via header in response message looks like: Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bK39bc.c1076d93.0 Via: SIP/2.0/UDP 192.168.1.3:5060;rport=5060;branch=z9hG4bK56870034 And the corresponding debug message from Kamailio is: ./sbin/kamailio[22600]: DEBUG: <script>: received param <null> in top most via header Case 2: received parameter exists Via header in response message looks like: Via: SIP/2.0/UDP 192.168.1.5;branch=z9hG4bK006e.18417697.0;received=10.139.90.137 Via: SIP/2.0/UDP 192.168.1.3:5060;rport=5060;branch=z9hG4bK960971659 And the corresponding debug message: ./sbin/kamailio[22600]: DEBUG: <script>: received param 10.139.90.137 in top most via header Thanks, Ajay

2 1

testing Supported and Require keywords
by Juha Heinanen 14 Mar '13

14 Mar '13

is there currently a proper way to test if a particular keyword appears in Supported or Require header or is a regex test on $hdr(X)[*] the only possibility? -- juha

3 3

Kamailio World Updates - March 14
by Daniel-Constantin Mierla 14 Mar '13

14 Mar '13

Hello, the groups of speakers at Kamailio World Conference got new members, among them Prof. Dr. Thomas Magedantz from Technische Universitat Berlin/FhG Fokus and Alan Duric, a pioneer in VoIP, among other positions being co-founder of Telio, more details at: - http://conference.kamailio.com/k01/speakers/ It is about one month till the start of the event, agenda is pretty much done, with possibility of few updates in the near future. Regarding Kamailio project, Monday we released v4.0.0, with really good feedback so far. Thank you again to everyone making it possible. New contributions started to show up on master branch, once you are done upgrading to v4.0.0, don't forget to give a try to development version and check the list of new additions. If you haven't registered yet for the Kamailio World conference, you should hurry up, the speakers and the other participants form an excellent group of professionals working with rich communication services and products, it is your chance to meet with them and get updated on the field: - http://conference.kamailio.com/k01/registration/ Also, if you consider sponsoring or participate to surrounding exhibition space, please get in touch with us, you will get an exceptional visibility and additional benefits at the event: - http://conference.kamailio.com/k01/sponsors/ We are glad to announce the first group of participating companies with all day availability for demos and presentations of their products and services: Sipwise, Sipgate, NG Voice, FhG Fokus and Asipto. The list will be updated soon with more participants. Looking forward to meet many of you in Berlin, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, April 16-17, 2013, Berlin - http://conference.kamailio.com -

1 0

Re: [SR-Users] how to extract the ip address in the via header received paramter
by Ajay Sabat 13 Mar '13

13 Mar '13

I added the append_hf() inside the if condition in oureply_route[] block as given below, and it is working. I still want to learn how to store data in a variable to use it later in another block. Thanks, Ajay Hi Daniel, Thanks for your response. But I don't want the IP in the received parameter of the incoming request. Instead, I want to read it (i.e. the public IP address of my own network where the local user and Kamailio are located) from the incoming response received from another proxy located outside the network. And I need that because Kamailio strips the top most via (where the received parameter is present ) in the incoming response before sending it back to the local user, which I guess is correct. But the user needs to know that IP address. So we are planning to send that IP address in a custom header in the response back to the user. After going through some Kamailio documents I found that $sel(via.received) would return the IP address in top most via of a message. Can I store it in a variable inside onreply_route[MANAGE_REPLY] block and use that variable later in some appropriate route block to insert a new header in the response to the local user? Can I do something as given below to fetch and store the IP address from received parameter in the via header of incoming response onreply_route[MANAGE_REPLY] { ... if(search_hf("Via", "received", "f")) { xdbg("received param exists on top most via header \n"); $var(public_ip) = $sel(via.received); } ... } and insert a new header as given below in an appropriate route block which is executed while sending response back? append_hf("My-custom-hdr: $var(public_ip) \r\n"); I am not sure if this logic would work. Is the $var() variable retained through two different sip transactions? And which route block should be used to insert the header as mentioned above? Please help. Thanks, Ajay Hello, the received parameter is constructed from source IP of the incoming request. You get it via $si script variable. Cheers, Daniel On 3/12/13 7:22 PM, Ajay Sabat wrote: > > Hi, > > I want to extract the IP address in the received parameter of the top > most via header of a response and use that in a custom header while > sending response back to the caller. Can somebody please tell how to > implement that in the Kamailio configuration file? > > I need to handle a NAT traversal scenario without enabling NAT in > Kamailio which is used as the proxy server. The caller which is in the > same network as Kamailio first sends a OPTIONS request to the callee > before sending the INVITE. It uses the public IP address returned in > the custom header of the OPTIONS response to build the contact header > and SDP of the INVITE request. In fact, it first looks for the IP > address in the received parameter of the via header to do that. But > Kamailio removes the top most via with received parameter and then > sends the OPTIONS response back to the caller. So we are using a > custom header for that purpose. > > I would appreciate other suggestions to achieve this in Kamailio, may > be by enabling NAT or some other alternative. > > Thanks, > > Ajay > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing > list sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, April 16-17, 2013, Berlin - http://conference.kamailio.com -

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
15
Older →

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 March 2013