sr-users October 2009

sr-users@lists.kamailio.org

63 participants
106 discussions

Re: [Kamailio-Users] How to fetch SIP Data from Asterisk?
by Henning Westerholt 09 Oct '09

09 Oct '09

On Freitag, 9. Oktober 2009, Vibhor Singhal wrote: > 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: > [..] > > For this we are trying Kamailio as Asterisk frontend.Plz tell us … [View More]

1 0

[Kamailio-Users] Presence issue - pua dialoginfo
by Francisco Javier Lizarán Vilches 09 Oct '09

09 Oct '09

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 … [View More]

3 6

Re: [Kamailio-Users] How to fetch SIP Data from Asterisk?
by Iñaki Baz Castillo 09 Oct '09

09 Oct '09

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.

2 2

Re: [Kamailio-Users] How to fetch SIP Data from Asterisk?
by Raúl Alexis Betancor Santana 09 Oct '09

09 Oct '09

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 … [View More]

2 1

[Kamailio-Users] How to fetch SIP Data from Asterisk?
by Vibhor Singhal 09 Oct '09

09 Oct '09

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 … [View More]

1 0

[Kamailio-Users] Thousands of CANCEL messages - problem with my configuration?
by CSB 08 Oct '09

08 Oct '09

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. … [View More] 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 [View Less]

3 3

[Kamailio-Users] BLF and MWI problem on Grandstreams
by David 08 Oct '09

08 Oct '09

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())… [View More]

3 4

[Kamailio-Users] Somebody going to Astricon?
by Klaus Darilion 08 Oct '09

08 Oct '09

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

4 3

[Kamailio-Users] help with custom module
by liran tal 07 Oct '09

07 Oct '09

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. … [View More]

2 1

[Kamailio-Users] PostgreSQL TLS support
by Olle E. Johansson 07 Oct '09

07 Oct '09

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

2 4

← Newer
1
...
5
6
7
8
9
10
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 October 2009