sr-users October 2010

sr-users@lists.kamailio.org

77 participants
157 discussions

Kamailio unable to forward Register request to asterisk

by Sundeep Kumar Mishra

Hi all, I have installed an asterisk server at 10.3.3.143:5080 and a kamailio at 10.3.3.85:5060. I am using sip communicator as softphone SIP Client. It is able to register at kamailio but the kamailio is not able to forward register request to asterisk. We have gone through the tutorial http://kb.asipto.com/asterisk:realtime:kamailio-3.0.x-asterisk-1.6.2-astdba… used the configuration file after changing the asterisk ip and kamailio ip. We found out that when a normal softphone authenticates directly to asterisk it sends and recieve |--softphone -- REGISTER |--asterisk -- 401 Unauthorised . CHallenge |--softphone -- REGISTER - Response to Challenge |--asterisk -- 200 OK (If response was correct) But I saw that when kamailio forwards register to asterisk, it sends first REGISTER packet but doesn't second the second one. It sends SUBSCRIBE instead of REGISTER with response to the challenge. Regards, Sundeep Kumar Mishra

14 years, 1 month

Error in syslog: BUG tm [t_msgbuilder.c:351]: unhandled reason cause -18344

by Mikko Lehto

Hi I am testing certain UAC behavior on proxy initiated 408 response with SIP Router. Call canceling is working fine - UAC gets 408 and GW gets CANCEL. However this error message is seen in syslog after fr_inv_timeout fires: BUG: tm [t_msgbuilder.c:351]: unhandled reason cause -18344 In script I set t_set_fr before t_relay, otherwise it is default: route[RELAY] { if (is_method("INVITE")) { t_on_reply("REPLY_ONE"); t_on_failure("FAIL_TEST"); } t_set_fr(4000); if (!t_relay()) { sl_reply_error(); } exit; } SIP Router is self compiled from Git: sip-router 3.1.0 (i386/linux) 34d2f6 Here are TM parameters: #modparam("tm", "local_cancel_reason", "0") modparam("tm", "noisy_ctimer", 1) modparam("tm", "auto_inv_100_reason", "tryink") modparam("tm", "failure_reply_mode", 3) modparam("tm", "fr_timer", 30000) modparam("tm", "fr_inv_timer", 120000) The above error message is found in t_msgbuilder.c on #ifdef CANCEL_REASON_SUPPORT -block. Looks like I do not have compiled in support for that new feature as I get error when uncommenting local_cancel_reason tm parameter: ERROR: <core> [modparam.c:150]: set_mod_param_regex: parameter <local_cancel_reason> not found in module <tm> Is this bug as log message suggests? -- Mikko Lehto Setera

14 years, 1 month

Siremis user guide

by Shrouk Khan

hi has anyone ever found any user guide for siremis ? it seems to take information directly from database and showing it . there is no tool tip or any clue as to what is what -- Regards Shrouk Khan (Khan) System Administrator / Telecommunication System Developer Office: +354 4400807 (Reykjavik) +44 2031370800 (London) Mobile: +66 875049439 (Bangkok) Web: www.softverk.is Reykjavik, Iceland // London, UK // Bangkok, Thailand

14 years, 1 month

[OT] Fwd: [dispatch] proposed SIXPAC charter

by Victor Pascual Avila

---------- Forwarded message ---------- From: Elwell, John <john.elwell(a)siemens-enterprise.com> Date: Wed, Oct 20, 2010 at 9:45 AM Subject: Re: [dispatch] proposed SIXPAC charter To: Peter Saint-Andre <stpeter(a)stpeter.im>, "dispatch(a)ietf.org" <dispatch(a)ietf.org> I find this a worthwhile topic to pursue. I had been wondering whether this activity would turn out to be more of a profiling exercise, and whether the IETF might not be the best choice of venue for such work. >From the current draft charter it looks like there will be at least some protocol extension work, for which I believe the IETF is the correct venue. On the other hand, the Unified Communications Interoperability Forum (UCIF) is seeking to advance the state of play on XMPP interoperability, and if we were just talking about a profile or BCP, that might have been a better venue. Perhaps the IETF should focus on requirements and protocol extensions, and consider whether the BCP work would be better done elsewhere. Or at least, there should be some coordination with other activities relating to XMPP interoperability. John > -----Original Message----- > From: dispatch-bounces(a)ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Saint-Andre > Sent: 19 October 2010 21:17 > To: dispatch(a)ietf.org > Subject: [dispatch] proposed SIXPAC charter > > Earlier this year, some folks in the RAI area proposed an > initiative to > define a few small extensions to both SIP and XMPP that would make it > easier to develop and deploy dual-stack SIP+XMPP endpoints. Based on > feedback provided on the DISPATCH list and received from the RAI ADs, > I've taken the liberty of rewriting the proposed charter, in the hopes > that fresh text will spur a more conclusive discussion. I'm > mostly just > trying to help the proponents put their best foot forward, so if folks > here have more feedback I'd expect that people like Simo Veikkolainen > and Emil Ivov will be able to engage in further discussion. > > /psa > > ### > > SIXPAC (SIP Integration with XMPP in Presence Aware Clients) > ============================================================== > =========== > > Problem Statement > > Both the Session Initiation Protocol (SIP) and the Extensible > Messaging > and Presence Protocol (XMPP) are widely deployed technologies for > real-time communication over the Internet. In order to offer > a complete > suite of features as well as communication across multiple networks, > several user-oriented software applications support both SIP and XMPP, > and more software developers have expressed interest in building such > "dual-stack" solutions. Unfortunately, it is difficult to provide a > good end-user experience in such applications because SIP and XMPP are > not aware of each other. For example: > > - XMPP presence does not include availability states related to a SIP > voice call or video call (e.g., "on the phone"), thus preventing an > a dual-stack endpoint from showing presence-based > communication hints > > - There is no correlation between an XMPP IM session and a SIP voice > or video session, thus preventing a dual-stack endpoint > from providing > integrated user interfaces and communications history > > - SIP accounts and XMPP accounts are not directly correlated > in contact > lists or vCards (and not all deployed services support > storage of such > information), thus preventing a dual-stack endpoint from > knowing that > a contact has both SIP and XMPP capabilities > > Although some proprietary solutions exist to the foregoing > problems, it > would be preferable to define standardized solutions for the sake of > improved interoperability. > > Objectives > > Because both SIP and XMPP are easily extended through new SIP headers > and XMPP elements, it should be possible to provide tighter > integration > within dual-stack SIP/XMPP user agents to improve the user experience. > > Any such extensions should meet the following criteria: > > - Be completely optional and backwards-compatible for all endpoints > > - Work without changes to deployed infrastructure such as existing > SIP and XMPP servers, B2BUAs, firewalls, etc. > > The SIXPAC WG will define a small number of SIP and XMPP extensions to > solve the following use cases in dual-stack endpoints: > > - Including SIP-based availability states in XMPP presence (limited to > basic presence and availability states only, not the full range of > PIDF extensions) > > - Correlating an XMPP IM session with a SIP voice/video session, and > vice-versa > > - Advertising a SIP account address over XMPP and an XMPP account > address over SIP > > Additional use cases are out of scope, including anything > related to or > requiring server integration, multiparty communication, SIP-based IM > and presence, XMPP-based voice and video, file transfer, generalized > service discovery and capabilities exchange, full protocol translation > in communication gateways, shared credentials across both SIP and XMPP > accounts, rich presence extensions for features such as geolocation, > etc. Although such topics are important and interesting, they are out > of scope for this group. > > However, in addition to the protocol extensions explicitly mentioned > above, the group may also define best practices related to the > implementation and deployment of dual-stack SIP/XMPP endpoints, > including topics such as user agent configuration. > > Deliverables > > - Use cases and protocol requirements > > - XMPP presence extension for SIP-based availability states > > - Media session correlation extensions for SIP and XMPP > > - Contact address advertisement extensions for SIP and XMPP > > - Best practices for implementation and deployment of dual-stack > endpoints > > Milestones > > Feb 2011 Submit use cases and protocol requirements document to > IESG (Informational) > > Oct 2011 Submit XMPP presence extension document to IESG > (Standards Track) > > Oct 2011 Submit media session correlation extensions document to IESG > (Standards Track) > > Oct 2011 Submit contact address advertisement extension document to > IESG (Standards Track) > > Oct 2011 Submit best practices document to IESG (Informational) > > ### > > > _______________________________________________ dispatch mailing list dispatch(a)ietf.org https://www.ietf.org/mailman/listinfo/dispatch -- Victor Pascual Ávila

14 years, 1 month

Re: [SR-Users] Kamailio 3.0 cann't access the RTPProxy

by Daniel-Constantin Mierla

Hello, apart of the email with logs, or private data that was required, please continue the discussion on public mailing list. I need some time to check the logs, the first inconvenience is the rar archive, a zip or tgz is much better -- not a fan of installing binaries from unknown companies on mac os x, going to get unrar from macports. Then solaris is not an OS i have at hand nor use frequently, so need to read about. It is also why using mailing list keeps you in touch with others that can help. Cheers, Daniel On 8/18/10 7:04 PM, KevinJin wrote: > Hi Daniel, > > Does the logs have any hint for what's cause of the issue? I didn't > include the user list in the previous email since logs have the actual > IP info. > > Thanks in advance! > > Best Regard > Kevin > > ------------------------------------------------------------------------ > From: kevin.jzh(a)hotmail.com > To: miconda(a)gmail.com > Subject: RE: [SR-Users] Kamailio 3.0 cann't access the RTPProxy > Date: Tue, 17 Aug 2010 18:51:02 +0800 > > > Hi Daniel, > > Attached are the two kamailio logs, > unix_socket_log --- run rtp proxy wth -s unix:/tmp/rtpproxy.sock > udp_rtpproxy_log --- run rtp proxy with -s udp:*:7722 > > Please help to check what's wrong with it. > > Thanks, > Kevin > ------------------------------------------------------------------------ > Date: Tue, 17 Aug 2010 11:29:46 +0200 > From: miconda(a)gmail.com > To: kevin.jzh(a)hotmail.com > CC: sr-users(a)lists.sip-router.org > Subject: Re: [SR-Users] Kamailio 3.0 cann't access the RTPProxy > > Hello, > > please send full log at startup, your snippets include just few lines > per process, being mixed from different processes. > > Cheers, > Daniel > > > On 8/14/10 3:54 AM, KevinJin wrote: > > Hello, > > ------------------------------------------------------------------------ > Date: Thu, 12 Aug 2010 22:16:18 +0200 > From: miconda(a)gmail.com <mailto:miconda@gmail.com> > To: kevin.jzh(a)hotmail.com <mailto:kevin.jzh@hotmail.com> > CC: sr-users(a)lists.sip-router.org > <mailto:sr-users@lists.sip-router.org> > Subject: Re: [SR-Users] Kamailio 3.0 cann't access the RTPProxy > > Hello, > > On 8/12/10 8:34 PM, KevinJin wrote: > > Hello, > > ------------------------------------------------------------------------ > Date: Thu, 12 Aug 2010 18:46:19 +0200 > From: miconda(a)gmail.com <mailto:miconda@gmail.com> > To: kevin.jzh(a)hotmail.com <mailto:kevin.jzh@hotmail.com> > CC: sr-users(a)lists.sip-router.org > <mailto:sr-users@lists.sip-router.org> > Subject: Re: [SR-Users] Kamailio 3.0 cann't access the RTPProxy > > Hello, > > On 8/12/10 4:47 PM, KevinJin wrote: > > Hi Daniel, > > What does the log below means? Does it mean nathelper has > issue to send the request to RTP proxy first or nathelper > doesn't receive a response after sending a request to the > rtp proxy? > 0(27429) ERROR: nathelper [nathelper.c:2457]: can't send > command to a RTP proxy > > this error is printed when write to socket fails. Do you have > any firewall running on the system? Is the user under which > kamailio runs allowed to write to sockets? > > > There's no firewall on the system, and I run the kamailio > as root, > root 26310 1 0 02:24:19 ? 0:00 > /usr/local/kamailio-3.0.2/sbin/kamailio -f > /usr/local/kamailio-3.0.2/etc/kamail > > You can edit module_k/nathelper/nathelper.c and replace > the line 2457 with: > > LM_ERR("can't send command to a RTP proxy (%s/%d)\n", > strerror(errno), errno); > > Recompile and reinstall. Hopefully will get more hints > about what happens. > > > Here is the error message after the change: > 2(26312) ERROR: nathelper [nathelper.c:2457]: can't send > command to a RTP proxy(Invalid argument/22) > 2(26312) ERROR: nathelper [nathelper.c:2492]: proxy > <udp:210.13.124.15:7722> does not respond, disable it > 2(26312) ERROR: nathelper [nathelper.c:3144]: no available proxies > what could be the cause? > > hmm, invalid argurment ... try with this line: > > LM_ERR("can't send command to a RTP proxy (%s/%d) [sock %d (%d), > vcnt %d]\n", > strerror(errno), errno, rtpp_socks[node->idx], node->idx, vcnt); > > maybe will give some hints about which value is invalid. > > Here's the log after the change: > 4(14415) ERROR: nathelper [nathelper.c:2457]: can't send command > to a RTP proxy (Invalid argument/22) [sock 7 (0), vcnt 18] > 4(14415) ERROR: nathelper [nathelper.c:2492]: proxy > <udp:210.13.x.y:7722> does not respond, disable it > 4(14415) ERROR: nathelper [nathelper.c:3144]: no available proxies > > > Can you try as well with an unix file socket: > > modparam("nathelper", "rtpproxy_sock", "unix:/tmp/rtpproxy.sock") > > then start rtpproxy with -s unix:/tmp/rtpproxy.sock > > > 4(17530) INFO: nathelper [nathelper.c:2369]: rtp proxy > <unix:/tmp/rtpproxy.sock> found, support for it re-enabled > 3(17529) ERROR: nathelper [nathelper.c:2429]: can't send command > to a RTP proxy > 3(17529) ERROR: nathelper [nathelper.c:2492]: proxy > <unix:/tmp/rtpproxy.sock> does not respond, disable it > 3(17529) ERROR: nathelper [nathelper.c:3144]: no available proxies > > Thanks, > Kevin > > I have no solaris (sparc) to try myself... > > Cheers, > Daniel > > > > Test env: > UA1 (Behind NAT) --------> Kamailio & RTPproxy (Public IP) > --------->UA2 (Public IP) > > Thanks, > Kevin > Cheers, > Daniel > > > > 0(27429) ERROR: nathelper [nathelper.c:2492]: proxy > <udp:210.13.124.15:7722> does not respond, disable it > > There's no problem for the resource(CPU, mem etc.) on the > server, the load is very low. > > Thanks in advance! > ---------- > 0(27429) DEBUG: nathelper [nhelpr_funcs.c:148]: type > <application/sdp> found valid > 0(27429) ERROR: nathelper [nathelper.c:3144]: no available > proxies > 0(27429) ERROR: nathelper [nathelper.c:2627]: no available > proxies > 0(27429) DEBUG: nathelper [nhelpr_funcs.c:148]: type > <application/sdp> found valid > 0(27429) INFO: nathelper [nathelper.c:2369]: rtp proxy > <udp:210.13.124.15:7722> found, support for it re-enabled > 0(27429) DEBUG: nathelper [nathelper.c:3196]: proxy reply: > 42040 210.13.124.14 > 0(27429) DEBUG: nathelper [nhelpr_funcs.c:148]: type > <application/sdp> found valid > 0(27429) ERROR: nathelper [nathelper.c:2457]: can't send > command to a RTP proxy > 0(27429) ERROR: nathelper [nathelper.c:2492]: proxy > <udp:210.13.124.15:7722> does not respond, disable it > 0(27429) ERROR: nathelper [nathelper.c:3144]: no available > proxies > 0(27429) ERROR: nathelper [nathelper.c:2627]: no available > proxies > > Thanks, > Kevin > ------------------------------------------------------------------------ > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierla > http://www.asipto.com/ > > > -- > Daniel-Constantin Mierla > http://www.asipto.com/ > > > -- > Daniel-Constantin Mierla > http://www.asipto.com/ -- Daniel-Constantin Mierla http://www.asipto.com/

14 years, 1 month

Integrate xmpp module with kamailio 3.0.1

by Huy Nguyen

Hi all, Sorry for restore this topic, but i till confused about the guide on xmpp module page. I'm integrating xmpp module to kamailio 3.0.x at my local network, with server mode. The kamailio server have domain: kamailio1.com (192.168.1.26), the xmpp server have domain: xmpp1.com (192.168.1.20). SIP user: 101(a)kamailio1.com XMPP user: 109(a)xmpp1.com Below is the part mention in xmpp doc I confused about, so i'm pasting that: In the destination address we need an extra character as a domain separator, apart from @. The address of the XMPP(jabber) client looks like this: "sip:username<domain_separator>jabber_server@gateway_domain". The address of a SIP client has the following pattern : "sip_username<domain_separator>openser_domain@xmpp_domain"; A common used character in XMPP transports is "%". It mean, from sip client 101(a)kamailio1.com, if I want to chat with xmpp client 109(a)xmpp1.com, I'll add 109 to the contact list of 101 as: sip:109%xmpp1.com@kamailio1.com. It right ? As the similar, i'll add to the buddy list of 109 as: 101%kamailio1.com(a)xmpp1.com ? Can anyone suggest how to test xmpp module ? Thanks, Huy Nguyen www.htk-inc.com

14 years, 1 month

by Iñaki Baz Castillo

Hi, not sure if this question has already taken place in this maillist: For some exotic reason sometimes the registrar receives a REGISTER with "To: sip:alice@domain.com" but I want to save it in the location table as "sip:bob@domain.com". AFAIK there is no way to do it, am I wrong? -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years, 1 month

Needed in Dallas, Texas, Network Voice Engineer and Field Service Install Technician

by JR Richardson

We have a couple of positions open, please respond to the posting if qualified and interested. http://www.ntegrated.net/resources/job-opportunities/field-service-install-… http://www.ntegrated.net/resources/job-opportunities/network-engineering-vo… These are full time positions in Dallas, no telecommuters please. Thanks. JR -- JR Richardson Engineering for the Masses

14 years, 1 month

Kamalio 3.1 based turn-key distribution released !

by X- x -X

Hey all, Just wanted to share this link. A distribution based on debian (lenny) & kamailio 3.1 pre-configured with presence server/RTP thing has been released. size: 245 MB. http://ciitix.ciit.net.pk/index.php/home/6-announcements-/14-ciitix-voip-10… Download link http://ciitix.ciit.net.pk/index.php/downloads Cheers --- X

14 years, 1 month

siremis 1.0.1 with kamalio 3.1 ?

by X- x -X

Hi all, Not sure if this should be put to siremis list or dev list or whatever but bear with me if you could. Since siremis v 2.0 is not out. Is siremis 1.0.1 known to work fine with kamalio 3.1 ? (ref: siremis 1.0.1 install http://siremis.asipto.com/install/ ) Is it ready for production deployment etc.. ? Will greatly appreciate any response from anyone since Ramona seems to be on her sabbatical . Thanks. --

14 years, 1 month

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

Jump to page:

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 2010