sr-users August 2012

sr-users@lists.kamailio.org

77 participants
127 discussions

Kamailio with asterisk for outbound calls
by Vijay Thakur 23 Aug '12

23 Aug '12

Hi All Kamailio Experts, I have configured Kamailio (kamailio 3.1.5) as media server. All things are working fine. Now i want to use Asterisk (Asterisk 1.6) for Outbound Calls. For this purpose i have followed the web page : http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdb. In this page, some points are not clear for me , as given below: (1) In case you use *sipregs* you have to create a record for each extension where to set the 'name' to value of 'name' from *sipusers*. The rest is populated by Asterisk from registrations. (2) Be sure you configure Asterisk *to not authenticate* SIP requests coming from Kamailio. I am not sure that my local users chat is working through kamailio or asterisk, who is used for authorization. Any specific Web page to correct the issue will highly appreciated according to my scenario. Kindly guide me. Thanks in advance. -- Best Regards, Vijay Thakur (Assistant Manager - Networks) Mobile : +91 8744018065 Mail : vijay.thakur(a)loopmethods.com Loop IT Methods Private Limited 1st Floor, B-10, Sector-7, Noida, (U.P) India Ph: +91 120 305 3481,82 (INDIA), +1 347 468 8631 (USA), +61 390 011 178 (AUS) Fax: +91 971 728 330 Web: www.loopmethods.com LOOP Disclaimer ------------------------------------------------------------------------------------------------- This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. -----------------------------------------------------------------------------------------------------------------

2 3

interfacing with kamailio
by Carlos Cruz 22 Aug '12

22 Aug '12

I'm just starting to evaluate Kamailio to be used as a front end to a couple of Asterisk Servers. Currently I have an Adobe Flex application that interfaces with Asterisk via AMI using a socket connection. I searched on how to interface with Kamailio but wasn't able to find anything that helped me. I would appreciate it if someone could point me to where I can find information on how this can be done using Kamailio. For example I would like my Flex Application to connect to Kamailio to know the status of the SIP channels. Thanks for any help!!! Carlos

2 1

new feature: option to remove contacts based on sip nat keepalives
by Juha Heinanen 22 Aug '12

22 Aug '12

daniel, you wrote: This feature should be useful in mobile networks, to avoid stacking lot of invalid contacts which could result in lot of branches causing many retransmissions. why would a sip ua that runs in a mobile network device be configured to use udp instead of tcp? poor battery life seems to be a big problem in so called smart phones. wouldn't this kind of active pinging make it even worse? -- juha

2 1

Websocket INVITE 407 error
by David Patiño 22 Aug '12

22 Aug '12

Hi there, I'm new on kamailio users list. Now I'm developing a client in javascript (using websockets) to SIP calls. I'm using last devel version of kamailio with websocket support. I've already get a correct REGISTER transaction but now I'm not able to get a correct INVITE transaction. Actually I'm not sure if this a kamailio error or a problem with my source code however I'm using the same function to get digest info from received nonce both REGISTER and INVITE transactions. The INVITE transaction always enters in an endless loop with 407 requests. Please, is there anybody who could help me? Those are the frames of my code (obtained from chrome browser console): wsUri: ws://10.1.20.40:80/ SOCKET CREATED SOCKET OPENED SENT: REGISTER sip:10.1.20.40 SIP/2.0 Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bK1C36k8S3b0OobHUAOLLOae0SbsbEQg From: sip:101@10.1.20.40;tag=Me0arqDG6K8o7l32oJgR To: sip:101@10.1.20.40 Call-ID: 0EQSBkoG9RGgfg3E CSeq: 1 REGISTER Max-Forwards: 70 Supported: path, outbound, gruu Contact: <sip:101@KMkjMf37lVeM.invalid;transport=ws> ;reg-id=98 ;+sip.instance="<urn:uuid:beb-68a9-6396e5f4>" RESPONSE: SIP/2.0 401 Unauthorized Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bK1C36k8S3b0OobHUAOLLOae0SbsbEQg;rport=50906;received=10.1.2.229 From: sip:101@10.1.20.40;tag=Me0arqDG6K8o7l32oJgR To: sip:101@10.1.20.40;tag=9de7b31b15b69da019f867d4866ff286.000c Call-ID: 0EQSBkoG9RGgfg3E CSeq: 1 REGISTER WWW-Authenticate: Digest realm="10.1.20.40", nonce="UDND2VAzQq0Tz8wvIFWNh2eYRxdtu4Re" Server: kamailio (3.4.0-dev3 (i386/linux)) Content-Length: 0 SENT: REGISTER sip:10.1.20.40 SIP/2.0 Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bKl521S8acS8nVEcejv2GOJ8r46Jb037 From: sip:101@10.1.20.40;tag=Pb8d1gV8K5qJo1gOv612 To: sip:101@10.1.20.40 Call-ID: 0EQSBkoG9RGgfg3E CSeq: 2 REGISTER Max-Forwards: 70 Supported: path, outbound, gruu Contact: <sip:101@KMkjMf37lVeM.invalid;transport=ws> ;reg-id=98 ;+sip.instance="<urn:uuid:beb-68a9-6396e5f4>" Authorization: Digest username="101", realm="10.1.20.40", nonce="UDND2VAzQq0Tz8wvIFWNh2eYRxdtu4Re", opaque="", uri="sip:10.1.20.40", response= "9b209eb35ee88192e2e0c468f8cf91da" RESPONSE: SIP/2.0 200 OK Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bKl521S8acS8nVEcejv2GOJ8r46Jb037;rport=50906;received=10.1.2.229 From: sip:101@10.1.20.40;tag=Pb8d1gV8K5qJo1gOv612 To: sip:101@10.1.20.40;tag=9de7b31b15b69da019f867d4866ff286.b2e4 Call-ID: 0EQSBkoG9RGgfg3E CSeq: 2 REGISTER Contact: <sip:101@KMkjMf37lVeM.invalid;transport=ws>;expires=120;received="sip:10.1.2.229:50906;transport=WS";pub-gruu="sip:101@10.1.20.40;gr=urn:uuid:beb-68a9-6396e5f4";temp-gruu="sip:uloc-5033344d-5211-1-1de173@10.1.20.40;gr";+sip.instance="<urn:uuid:beb-68a9-6396e5f4>";reg-id=98 Server: kamailio (3.4.0-dev3 (i386/linux)) Content-Length: 0 SENT: INVITE sip:102@10.1.20.40 SIP/2.0 Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bKOIosJ8TMPgvfHme6NIm4GSn24Fu7f7 From: sip:101@10.1.20.40;tag=3U0osO4h3h2bgCrvnCqO To: sip:102@10.1.20.40 Call-ID: 9KoKnFdh285k2jg4 CSeq: 1 INVITE Max-Forwards: 70 Supported: path, outbound, gruu Contact: <sip:101@KMkjMf37lVeM.invalid;transport=ws ;gr=urn:uuid:beb-68a9-6396e5f4;ob> Content-Type: application/sdp RESPONSE: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bKOIosJ8TMPgvfHme6NIm4GSn24Fu7f7;rport=50906;received=10.1.2.229 From: sip:101@10.1.20.40;tag=3U0osO4h3h2bgCrvnCqO To: sip:102@10.1.20.40;tag=9de7b31b15b69da019f867d4866ff286.f545 Call-ID: 9KoKnFdh285k2jg4 CSeq: 1 INVITE Proxy-Authenticate: Digest realm="10.1.20.40", nonce="UDND2VAzQq0Tz8wvIFWNh2eYRxdtu4Re" Server: kamailio (3.4.0-dev3 (i386/linux)) Content-Length: 0 SENT: ACK sip:102@10.1.20.40 SIP/2.0 Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bKAmmLhK71tr2QoAiV9f5QmdKF9dGkke From: sip:101@10.1.20.40;tag=3U0osO4h3h2bgCrvnCqO To: sip:102@10.1.20.40;tag=9de7b31b15b69da019f867d4866ff286.f545 Call-ID: 9KoKnFdh285k2jg4 CSeq: 1 ACK Max-Forwards: 70 Supported: path, outbound, gruu SENT: INVITE sip:102@10.1.20.40 SIP/2.0 Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bK1GRkmlTVo7Cb4fg8OMe9g39g096hmn From: sip:101@10.1.20.40;tag=3U0osO4h3h2bgCrvnCqO To: sip:102@10.1.20.40 Call-ID: 9KoKnFdh285k2jg4 CSeq: 2 INVITE Max-Forwards: 70 Supported: path, outbound, gruu Contact: <sip:101@KMkjMf37lVeM.invalid;transport=ws ;gr=urn:uuid:beb-68a9-6396e5f4;ob> Proxy-Authorization: Digest username="101", realm="10.1.20.40", nonce="UDND2VAzQq0Tz8wvIFWNh2eYRxdtu4Re", opaque="", uri="sip:102@10.1.20.40", response= "f4bbe128abf3acb3a4e11882749d8798" Content-Type: application/sdp RESPONSE: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bK1GRkmlTVo7Cb4fg8OMe9g39g096hmn;rport=50906;received=10.1.2.229 From: sip:101@10.1.20.40;tag=3U0osO4h3h2bgCrvnCqO To: sip:102@10.1.20.40;tag=9de7b31b15b69da019f867d4866ff286.0007 Call-ID: 9KoKnFdh285k2jg4 CSeq: 2 INVITE Proxy-Authenticate: Digest realm="10.1.20.40", nonce="UDND2VAzQq0Tz8wvIFWNh2eYRxdtu4Re" Server: kamailio (3.4.0-dev3 (i386/linux)) Content-Length: 0 SENT: ACK sip:102@10.1.20.40 SIP/2.0 Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bKG9v5g7i1LNsoVGo18ULlgqdA1EcFGb From: sip:101@10.1.20.40;tag=3U0osO4h3h2bgCrvnCqO To: sip:102@10.1.20.40;tag=9de7b31b15b69da019f867d4866ff286.0007 Call-ID: 9KoKnFdh285k2jg4 CSeq: 2 ACK Max-Forwards: 70 Supported: path, outbound, gruu SENT: INVITE sip:102@10.1.20.40 SIP/2.0 Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bK8cie6bGSG0eOGh7Ne08Ro4CS1hI0oJ From: sip:101@10.1.20.40;tag=3U0osO4h3h2bgCrvnCqO To: sip:102@10.1.20.40 Call-ID: 9KoKnFdh285k2jg4 CSeq: 3 INVITE Max-Forwards: 70 Supported: path, outbound, gruu Contact: <sip:101@KMkjMf37lVeM.invalid;transport=ws ;gr=urn:uuid:beb-68a9-6396e5f4;ob> Proxy-Authorization: Digest username="101", realm="10.1.20.40", nonce="UDND2VAzQq0Tz8wvIFWNh2eYRxdtu4Re", opaque="", uri="sip:102@10.1.20.40", response= "f4bbe128abf3acb3a4e11882749d8798" Content-Type: application/sdp RESPONSE: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/WS KMkjMf37lVeM.invalid;branch=z9hG4bK8cie6bGSG0eOGh7Ne08Ro4CS1hI0oJ;rport=50906;received=10.1.2.229 From: sip:101@10.1.20.40;tag=3U0osO4h3h2bgCrvnCqO To: sip:102@10.1.20.40;tag=9de7b31b15b69da019f867d4866ff286.b1f7 Call-ID: 9KoKnFdh285k2jg4 CSeq: 3 INVITE Proxy-Authenticate: Digest realm="10.1.20.40", nonce="UDND2VAzQq0Tz8wvIFWNh2eYRxdtu4Re" Server: kamailio (3.4.0-dev3 (i386/linux)) Content-Length: 0 .......and so on in an endless loop with 407 requests Thanks a lot Kind Regards -- --DAVID--

4 9

SIP routing configuration howto
by Kaplan, Michael A 22 Aug '12

22 Aug '12

Folks, I'm working on a 5 node network in the following topology: Host1 - Edge Proxy 1 --- Core Proxy - Edge Proxy 2 - Host2 The proxy machines contain SIP Server installations, the hosts contain user agent software. I am able to make a call end to end between the hosts, but when I look at the traffic in wireshark, the core proxy is actually just forwarding the messages at the IP-layer. I would like actual SIP routing to occur, where a host would send the INVITE to the edge, and the edge has to forward it to the core etc, with these messages actually being processed at the SIP layer for all proxy nodes. I've been trying to use the dynamic routing module, thought I'm not sure this is really right for what I need, simple static routing would likely work as well. Is it necessary for me to rewrite the route{} functions of a proxy script? I'm not sure if I'm approaching this problem the right way. Eventually I would like to have multiple core servers and be able to failover between them, but trying to keep it simple for now. Thanks, Mike -------------------------------- Michael A. Kaplan Senior Research Scientist Applied Communication Sciences 732-699-3805 (office) 973-699-6775 (cell) mkaplan(a)appcomsci.com

2 1

Advertising and instructing company seeking region rep
by serusers＠iptel.org 22 Aug '12

22 Aug '12

Spam detection software, running on the system "mail.iptel.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Collectively, we focus on different sources of power, new green tech, and reusable materials. We are advertising for someone from your region to be employed by us. We require: [...] Content analysis details: (11.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT [189.58.67.119 listed in bb.barracudacentral.org] 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [189.58.67.119 listed in zen.spamhaus.org] 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL, https://senderscore.org/blacklistlookup/ [189.58.67.119 listed in bl.score.senderscore.com] 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [189.58.67.119 listed in dnsbl.sorbs.net] 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 1.7 URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist [URIs: euroinjobs.com] 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: euroinjobs.com] 0.0 T_FRT_PROFILE2 BODY: ReplaceTags: Profile (2) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0001] 1.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: euroinjobs.com] 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS

1 0

New Job position
by serusers＠iptel.org 21 Aug '12

21 Aug '12

Spam detection software, running on the system "mail.iptel.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Collectively, we focus on different sources of power, new green tech, and reusable materials. We are advertising for someone from your region to be employed by us. We require: [...] Content analysis details: (10.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [91.54.224.170 listed in zen.spamhaus.org] 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_FRT_PROFILE2 BODY: ReplaceTags: Profile (2) 1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT [91.54.224.170 listed in bb.barracudacentral.org] 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL, https://senderscore.org/blacklistlookup/ [91.54.224.170 listed in bl.score.senderscore.com] 1.7 URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist [URIs: euroinjobs.com] 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: euroinjobs.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: euroinjobs.com] 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS

1 0

Send/Receive IMs
by Marty Beyers 21 Aug '12

21 Aug '12

Hey guys. I am very new to Kamailio. Basically, at this time, I want to generate a SIP message (from an SMS) within Kannel, and send this message to my Kamailio server, which will forward the SIP message to another SIP server. Therefore my Kamailio Sip server would act as a single user agent connecting to only one other SIP server. So what I am unsure of is: 1. Is there a Kamailio interface (such as an HTTP server) which Kannel can connect to in order for Kannel to send multiple messages to my Kamailio Server, which in turn would be forwarded as SIP instant messages to another SIP server? 2. Which Kamailio api can I use to formulate and send the SIP instant messages? 3. Which Kamailio callback function could be called when I receive acknowledgement responses to the SIP IMs I have sent? 4. Which Kamailio callback function could be called when I receive new SIP instant messages sent to me? It would be great if someone could help point me in the right direction. Many thanks. Fred

2 1

vacancy #428
by serusers＠iptel.org 21 Aug '12

21 Aug '12

Spam detection software, running on the system "mail.iptel.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Collectively, we focus on different sources of power, new green tech, and reusable materials. We are advertising for someone from your region to be employed by us. We require: [...] Content analysis details: (7.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_FRT_PROFILE2 BODY: ReplaceTags: Profile (2) 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [109.100.26.103 listed in zen.spamhaus.org] 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL 1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT [109.100.26.103 listed in bb.barracudacentral.org] 1.7 URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist [URIs: euroinjobs.com] 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: euroinjobs.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS

1 0

SUBSCRIBE/NOTIFY record route
by Spencer Thomason 21 Aug '12

21 Aug '12

Hello all, I'm using Kamailio (on a public IP) as a border proxy that handles NAT traversal (detection and keep alives) for several Freeswitch servers which have public IPs as well. I'm having a problem record-routing SUBSCRIBEs and NOTIFYs for nated UACs. If the UAC is behind NAT, I am adding a Record-Route to the initial SUBSCRIBE and NOTIFY request. This works great until the UAC (in this case a Cisco SPA509G) refreshes the subcription and sends the SUBSCRIBE directly to the Freeswitch server. Since the request doesn't pass through the proxy, Freeswitch then sends NOTIFYs directly to the UAC which only recieves the first NOTIFY as the NAT pinhole is still open from the SUBSCRIBE. The UAC did receive a NOTIFY validating the subscription, and continues to refresh the subscription directly to the freeswitch server. The completely breaks presence. What is the correct way to ensure all SUBSCRIBE/NOTIFYs pass through the proxy? I have found that I can force this behavior by modifying the Contact header in the 202 Accepted to point back to the proxy but I'm not sure if this is what I "should" be doing. Thanks for any assistance and please forgive my ignorance when is comes to SIP presence! Spencer

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
13
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 August 2012