sr-users October 2009

sr-users@lists.kamailio.org

63 participants
105 discussions

[Kamailio-Users] Presence issue - pua dialoginfo

by Francisco Javier Lizarán Vilches

Hi all: I have a problem using Kamailio 1.5.2 as proxy&presence server. User A is subscribed to B's event dialog, and Kamailio handles this subscription. When a call arrives to pstn number C, the proxy resolves it via ENUM and sends the INVITE to B. The issue is that the PUBLISH request uri is C, because pua_dialoginfo module looks into To uri instead of Request uri, so A is not informed about B state. Has anybody any idea to work around this? Thanks: Francisco Javier Lizarán Vilches ---------------------------------------------- BARIK (Grupo Ormazabal) Departamento Técnico Tel.: +34 917 479 900 www.barik.es <http://www.barik.es/> ----------------------------------------------

15 years, 1 month

Re: [Kamailio-Users] How to fetch SIP Data from Asterisk?

by Iñaki Baz Castillo

2009/10/9 Vibhor Singhal <vibhor.singhal(a)coraltele.com>: > We are a telcom company in Noida developing CTI applications. > We are using Asterisk-1.4.and have configured manager.conf file and > connection with the AMI is successfull using username and password. We want > to monitor/fetch SIP packets from TCP port. Please let us know how to take > SIP data from tcp port. This is a list about Kamailio, not about Asterisk.

15 years, 1 month

Re: [Kamailio-Users] How to fetch SIP Data from Asterisk?

by Raúl Alexis Betancor Santana

On Friday 09 October 2009 06:56:51 Vibhor Singhal wrote: > Hi, > > > We are a telcom company in Noida developing CTI applications. > We are using Asterisk-1.4.and have configured manager.conf file and > connection with the AMI is successfull using username and password. We want > to monitor/fetch SIP packets from TCP port. Please let us know how to take > SIP data from tcp port. First of all .. this is not the correct list to ask this kind of questions . Then Asterisk does not support SIP over TCP (not yet). > Our scenario: > > We are developing CTI applications where we need SIP data from PBX such as > SourceIP,Username,Destination IP,TAG,VIA,Contact,CALL-ID,C-Sequence etc for > each of the SIP packets such as REGISTER,BYE,INVITE,ACK,SUBSCRIBE,NOTIFY > etc. Asterisk will not give you that information over the AMI, you will need to develop a module for asterisk or modify chan_sip to archive that goal. > e.g Wrieshark displays SIP packets for activities going on SIP port in the > below mentioned format: > After receiving these SIP Packets from Asterisk,we can parse that data > according to our requirements. > Is there any text/data file or database where asterisk stores all the > information in above format? No > If we need to fetch this data at realtime from the port than how can we do > that? You have toons of ways for skying a cat ... you could ... : - Develop your custom sip-cature program, using libpcap for example - Work with ngrep for getting about what you need - Develop a wireshark filter. - ... > For this we are trying Kamailio as Asterisk frontend.Plz tell us about the > installation process and how to make kamailio as asterisk's fromtend > > > Request for an early reply!!! > Regards If you need such kind of work and you don't have time to learn yourself, better to look up for a consultant and pay for that work. -- Raúl Alexis Betancor Santana Dimensión Virtual

15 years, 1 month

[Kamailio-Users] How to fetch SIP Data from Asterisk?

by Vibhor Singhal

Hi, We are a telcom company in Noida developing CTI applications. We are using Asterisk-1.4.and have configured manager.conf file and connection with the AMI is successfull using username and password. We want to monitor/fetch SIP packets from TCP port. Please let us know how to take SIP data from tcp port. Our scenario: We are developing CTI applications where we need SIP data from PBX such as SourceIP,Username,Destination IP,TAG,VIA,Contact,CALL-ID,C-Sequence etc for each of the SIP packets such as REGISTER,BYE,INVITE,ACK,SUBSCRIBE,NOTIFY etc. e.g Wrieshark displays SIP packets for activities going on SIP port in the below mentioned format: o SIP Packet as displayed on wireshark******************* SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.3.35:5060;branch=z9hG4bK10e203f8;rport=5060 Contact: <sip:1000000@192.168.3.15:45118> To: <sip:1000@192.168.3.15:45118>;tag=1f0f342c From: "Unknown"<sip:Unknown@192.168.3.35>;tag=as4a585648 Call-ID: 38670a55c46d1235YzY2YWQxZTM0ODk4NTRhZDI5MjY3YjMyYjE4OTlhZjc. CSeq: 102 NOTIFY User-Agent: X-Lite release 1003l stamp 30942 Content-Length: 0 After receiving these SIP Packets from Asterisk,we can parse that data according to our requirements. Is there any text/data file or database where asterisk stores all the information in above format? If we need to fetch this data at realtime from the port than how can we do that? For this we are trying Kamailio as Asterisk frontend.Plz tell us about the installation process and how to make kamailio as asterisk's fromtend Request for an early reply!!! Regards Regards, Vibhor Singhal Software Engineer Mob : +919891380819 " If you fail to plan,you plan to fail" Coral Telecom Limited E2, Sector 63, Noida - 201301, UP, India. F: +91-120-4035888 E: corporate(a)coraltele.com www.coraltele.com <http://www.coraltele.com/index.asp>

15 years, 1 month

[Kamailio-Users] Thousands of CANCEL messages - problem with my configuration?

by CSB

We had a very strange situation last night with our proxy (running OpenSer 1.3). We received an INVITE from a UA. This was then cancelled by the UA. This then resulted in OpenSER generating 40000+ cancel messages with our server talking to itself i.e. the toip and fromip are the same in the sip_trace table. Incidentally, this proxy processes thousands of calls a day so I'm not sure what gave rise to this problem but I guess a particular set of events has highlighted a bug in my config file. The other very curious thing is that somehow our other SIP proxy gets in on the act. Cancel message 40000-odd looks like this: CANCEL sip:031234567@domain.com SIP/2.0 Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.002;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Record-Route: <sip:147.202.001.001;lr=on;ftag=as02736614> Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.5d037b85.0 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.2d037b85.0 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.67037b85.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.20037b85.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.8ff27b85.0 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.e16dcb3.0 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.516dcb3.0 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.3c5dcb3.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.05e27b85.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.b4e27b85.0 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.365dcb3.0 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.52e27b85.0 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.be4dcb3.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.33c27b85.1 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.2d3dcb3.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.84a27b85.1 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.da2dcb3.1 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.002dcb3.1 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.561dcb3.1 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.111dcb3.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.4b627b85.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.ca627b85.0 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.5a627b85.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.1a627b85.0 Via: SIP/2.0/UDP 147.202.001.002;branch=z9hG4bK223e.ed0dcb3.0 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.d9627b85.1 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.c9627b85.0 Via: SIP/2.0/UDP 147.202.001.001;branch=z9hG4bK223e.b9627b85.0 Via: SIP/2.0/UDP 210.48.001.001:5060;branch=z9hG4bK519fe576;rport=5060 From: "Customer" <sip:12345678@domain.com>;tag=as02736614 To: <sip:031234567@domain.com> Contact: <sip:6496306317@210.48.001.001> Call-ID: 771d537932ab79225888a341190691c2(a)domain.com CSeq: 102 CANCEL User-Agent: Asterisk PBX Max-Forwards: 41 Content-Length: 0 I have pasted what I think are the relevant parts from the config file. Could anyone advise where the problem might be? route { # ----------------------------------------------------------------- ### SipTrace. # ----------------------------------------------------------------- if ! is_method("OPTIONS|SUBSCRIBE|NOTIFY") { sip_trace(); setflag(28); } # ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); return; }; if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); return; }; # ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- #If it's an INVITE & client is NATed, #xlog("welcome"); if (method=="INVITE" && client_nat_test("3")) { #Record-route and specify the record-route header explicitly record_route_preset("147.202.001.001:5060;nat=yes"); # insert IP address xlog("invite and nated so record_route_preset"); #If not Nated and not REGISTER then normal record-route } else if (method!="REGISTER") { record_route(); xlog("not register and not nated so record_route"); }; # ----------------------------------------------------------------- # Call Tear Down Section # ----------------------------------------------------------------- if (method=="BYE" || method=="CANCEL") { setflag(1); #call end_media_session in case we're proxying media end_media_session(); }; # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { #Ensure we are dealing with a re-INVITE. Only connected calls have tag= #entry in the To header. So if it's loose routed and doesn't have totag #and it's an invite or reply then something's wrong xlog("loose_route"); if ((method=="INVITE" || method=="REFER") && !has_totag()) { sl_send_reply("403", "Forbidden"); xlog("403 in lr"); return; }; if (method=="INVITE") { if (!allow_trusted()) { xlog("!allow_ trusted for r-uri <$ru>"); if (!proxy_authorize("","subscriber")) { proxy_challenge("domain.com","1"); return; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); return; }; consume_credentials(); }; #check client is nated or that we've already identified it's nated xlog("Re-invite. rs $rs si $si rm $rm ru $ru tu $tu fu $fu fd $fd rr $rr"); if (client_nat_test("3") || search("^Route:.*;nat=yes")) { setbflag(6); xlog("Recipient is nated so setbflag 6 and use mediaproxy: r-uri <$ru>"); use_media_proxy(); }; }; route(1); return; }; # ----------------------------------------------------------------- # Call Type Processing Section # ----------------------------------------------------------------- # Processes out-of-dialogue messages i.e. # 1. new dialogue # 2. message not destined for us (but we are relaying or proxying) xlog("Call Type Processing Section"); if (!is_uri_host_local()) { xlog("!is_uri_host_local"); if (is_from_local() || allow_trusted() ) { xlog("is_from_local() || allow_trusted()"); route(5); route(1); } else { sl_send_reply("403", "Forbidden"); xlog("403 in call type processing. rs $rs si $si rm $rm ru $ru tu $tu fu $fu fd $fd rr $rr"); }; return; }; sip_trace(); if (method=="ACK") { route(1); return; } else if (method=="CANCEL") { route(1); return; } else if (method=="INVITE") { route(3); return; } else if (method=="REGISTER") { route(2); return; } else if (method=="SUBSCRIBE") { route(7); return; }; route[1] { # ----------------------------------------------------------------- # Default Message Handler # ----------------------------------------------------------------- xlog("hit route(1). rs $rs si $si rm $rm ru $ru tu $tu fu $fu rr $rr"); #Call reply_route(1) to intercept response messages heading to the client t_on_reply("1"); #Try to relay the message to its destination if (!t_relay()) { #If it can't and it's an INVITE or ACK end the media proxying log(1,"route[1] !t_relay"); if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); } else { log(1,"route[1] t_relay"); }; } onreply_route[1] #Handles message that are returned to the sender i.e. response to caller's original request { xlog("hit onreply_route(1). rs $rs si $si rm $rm ru $ru tu $tu fu $fu rr $rr"); if (isbflagset(6)) { xlog("flag(6) is set for $fu . We're currently in onreply_route(1)"); }; if (isbflagset(7)) { xlog("flag(7) is set for $fu . We're currently in onreply_route(1)"); }; if (status=~"(180)|(183)|2[0-9][0-9]") { xlog("status matches for $fu . We're currently in onreply_route(1)"); }; if ((isbflagset(6) || isbflagset(7)) && (status=~"(180)|(183)|2[0-9][0-9]")) { #Check the SDP payload length. Assume if we have something we can call mediaproxy if (!search("^Content-Length:[ ]*0")) { log(1,"using media proxy in onreply_route(1)"); use_media_proxy(); }; }; if (client_nat_test("1")) { fix_nated_contact(); }; } Any advice appreciated. Cameron

15 years, 1 month

[Kamailio-Users] BLF and MWI problem on Grandstreams

by David

All, I upgraded to Kamailio 1.5 and had a lot of problems getting BLF and MWI working. So I will list here some of my notes in case some body else ever has the same issue. Firstly, in my tests I am using a GXP2000, GXP2020 and a SPA962. I also tested with a SNOM360. my issue was the MWI seemed to fail after an hour, and I could not find why. So in searching my config, I found that when the phones were resubscribing to MWI and BLF, it was being caught in this condition : if (has_totag()) { if (loose_route()) { if (is_method("BYE")) { setflag(1); # do accouting ... setflag(3); # ... even if the transaction fails } route(4); } else { sl_send_reply("404","Not here"); exit; } } My subscribe code handling was after this block, I noticed the issue from the 404 the grandstream was getting when trying to subscribe. I therefore added handling for the subscribe packets in this section, and my MWI and BLF seems to be working. else if ( is_method("PUBLISH") || is_method("SUBSCRIBE") ) { route(5); exit ; } Where route(5) does the appropriate handling of these two types of SIP packets. It should be noted, when I speak of MWI I am referring to presence message-summary which is sent via a publish by my media application. When I write BLF, I am referring to Presence Dialog. So when my phones were resubscribing, they are being sent a 404. I tested the Grandstream and the Linksys, and both seem to have the problem resolved. I will test this with the Snom tomorrow and post my results. David

15 years, 1 month

[Kamailio-Users] Somebody going to Astricon?

by Klaus Darilion

..so we should hang out for a beer :-)

15 years, 1 month

[Kamailio-Users] help with custom module

by liran tal

Hey list, I've written a very simple module, just exporting one function I need which does something simple like checking a file and returns -1 or 1 if the file exist or not. The problem I'm facing is as follows: During call flow (extension1 calling extension2), it seems that the logic of the call flow is passed via that module and hangs the entire call process. And this happens without even calling that single exported function, but rather just by including the module itself via loadmodule. Log from the call flow: ... 8(3827) SIP Reply (status): 8(3827) version: <SIP/2.0> 8(3827) status: <100> 8(3827) reason: <Trying> 8(3827) parse_headers: flags=2 8(3827) Found param type 232, <branch> = <z9hG4bKde5a.32fd75d7.0>; state=9 8(3827) parse_via: next_via 8(3827) Found param type 232, <branch> = <z9hG4bK-d8754z-303e27391e65ac7d-1---d8754z->; state=6 8(3827) Found param type 235, <rport> = <21644>; state=16 8(3827) end of header reached, state=5 8(3827) parse_headers: Via found, flags=2 8(3827) parse_headers: this is the first via 8(3827) After parse_msg... * 8(3827) forward_reply: found module exec_custom, passing reply to it * 8(3827) DEBUG:destroy_avp_list: destroying list (nil) 8(3827) receive_msg: cleaning up ... that forward_reply thing has the module involved there for whatever reason, I've no idea. This is on openser1.0.1 I'd appreciate some feedback Regards, Liran.

15 years, 1 month

[Kamailio-Users] PostgreSQL TLS support

by Olle E. Johansson

The db_postgres documentation doesn't say much about anything, really... Is there support for TLS connections and how do I configure it if it exist? Thanks, /O

15 years, 1 month

[Kamailio-Users] LDAP and TLS

by Olle E. Johansson

Greetings, fellow Kamailians! Looking at the LDAP module for Kamailio, I see that we can use LDAPS: and get TLS connections. But where are the SSL configurations so I can use a client cert, or verify the server cert? /O

15 years, 1 month

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

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 October 2009