sr-users August 2013

sr-users@lists.kamailio.org

93 participants
176 discussions

by אורן אברהם

Dear list. Hi, I was reading the documentation & implementation code for the AUTH_EPHEMERAL module, but i still don't understand how the webservice works. (and where it is implemented) to where i send the 'GET...' request and who returns the reply. Is there any working example or configuration script that can shed some light on this ? thanks, oren.

10 years, 12 months

Issues Kamailio 4.0 and Asterisk 11

by Nishar M.H

Hi, I am Trying to make a Seperate SIP Server (Kamailio) and Asterisk PBX Server. http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb But in Above link the issue is actually both are in same server. But I need to make seperate server SIP Authentication and Asterisk. I tried to follow the the link step by step. But issue is actually, i made some changes to make separate server for SIP server and PBX. But issue that i am facing is when i copied kamailio.cfg from the link, I tried to start kamctl after that but i am got : INFO: Starting Kamailio : ERROR: PID file /var/run/kamailio.pid does not exist -- Kamailio start failed Can you help me out. ? -- Thanks & Regards, -------------------------------------------------------------------------------------------- *Nishar Hamsa * --------------------------------------------------------------------------------------------

10 years, 12 months

Re: [SR-Users] Kamailio / rtpproxy behaviour on dual-homed box

by Steve Davies

On 16 August 2013 16:31, Alex Balashov <abalashov(a)evaristesys.com> wrote: > I think this thread may help you: > > http://lists.sip-router.org/**pipermail/sr-users/2010-** > October/065669.html<http://lists.sip-router.org/pipermail/sr-users/2010-October/065669.html> > > Hi Alex, Thanks for the pointer! I see that the kamailio.cfg that comes with 4.0.3 handles rtpproxy via the new rtpproxy_manage call: # RTPProxy control route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; rtpproxy_manage("co"); # <--------------------------------------------------- if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { add_contact_alias(); } } #!endif return; } this route block is called from a few places. Seems like I will need to improve this to take account of the direction of the message and use "ie" or "ei" as appropriate? Thanks, Steve

10 years, 12 months

Kamailio / rtpproxy behaviour on dual-homed box

by Steve Davies

Hi all, I have a fresh install of Kamailio 4.0.3 - built from source - and rtpproxy, version: Basic version: 20040107 Extension 20050322: Support for multiple RTP streams and MOH Extension 20060704: Support for extra parameter in the V command Extension 20071116: Support for RTP re-packetization Extension 20071218: Support for forking (copying) RTP stream Extension 20080403: Support for RTP statistics querying Extension 20081102: Support for setting codecs in the update/lookup command Extension 20081224: Support for session timeout notifications My system is Ubuntu 13.04. My box is dual homed - eth0 is 10.64.5.16/24, eth1 is 172.16.230.128/24 My rtpproxy command line is: /usr/sbin/rtpproxy -s udp:127.0.0.1:7722 -u rtpproxy:rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -l 172.16.230.128/10.64.5.16 My Kamalio config is "out of the box", except that I defined "WITH_NAT", added "mhomed=1" and added a couple of aliases. I have a soft phone running on another box. Also dual homed on 10.64.5.146 and 172.16.230.1. The soft phone is configured to register to a server that is here called " xxx.connection-telecom.com". That server is an OpenSIPs instance with Asterisk behind it. No rtpproxy on that side, but nathelper is used. There is no NAT between the 10.64.5.0/24 network and the xxx.connection-telecom.com server. >From xxx.connection-telecom.com 172.16.230.0/24 cannot be reached. The soft phone uses 172.16.230.128 as its outbound proxy. The idea is to test outbound calling from the soft phone via Kamailio/RTPProxy. I'm expecting "bridge mode" - IE for rtp to get passed through rtpproxy, passing the RTP between the two interfaces. What I actually get is one way audio - audio from 172.16.230.1 gets to xxx.connection-telecom.com; audio back does not. Also, the call drops after 30 seconds. I'll pick up the trace with the authenticated INVITE from the phone: So here is the invite from the phone: U 172.16.230.1:61762 -> 172.16.230.128:5060 INVITE sip:7171001@xxx.connection-telecom.com;transport=udp SIP/2.0. Via: SIP/2.0/UDP 172.16.230.1:61762 ;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport. Max-Forwards: 70. Contact: <sip:2686959@172.16.230.1:61762;transport=udp>. To: <sip:7171001@xxx.connection-telecom.com>. From: "vc2 2686959"<sip:2686959@xxx.connection-telecom.com>;tag=c601fd36. Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Proxy-Authorization: Digest username="2686959",realm=" xxx.connection-telecom.com ",nonce="520e1e50ef047461c3b0dbc731ccdc19e99990ce",uri=" sip:7171001@xxx.connection-telecom.com ;transport=udp",response="yyyyyyy",algorithm=MD5. Supported: replaces. User-Agent: Bria 3 release 3.5.3 stamp 70600. Content-Length: 256. . v=0. o=- 1376656946792420 1 IN IP4 172.16.230.1. s=Bria 3 release 3.5.3 stamp 70600. c=IN IP4 172.16.230.1. t=0 0. m=audio 59984 RTP/AVP 8 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. "Trying" from Kamailio: # U 172.16.230.128:5060 -> 172.16.230.1:61762 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 172.16.230.1:61762 ;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport=61762. To: <sip:7171001@xxx.connection-telecom.com>. From: "vc2 2686959"<sip:2686959@xxx.connection-telecom.com>;tag=c601fd36. Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU. CSeq: 2 INVITE. Server: kamailio (4.0.3 (i386/linux)). Content-Length: 0. Here's what Kamailio sent to the remote server. * The from address is set to the eth0 interface address thanks to mhomed=1 (without that it uses the 172.16 address) * But In sdp, wrong address is used. It is changed to "our" address, but our address on the eth1 interface. Surely since we are talking on the eth0 side, 10.64.5.16 should have been used? * Contact is not changed (not sure if it should be?) U 10.64.5.16:5060 -> 41.000.000.60:5060 INVITE sip:7171001@xxx.connection-telecom.com;transport=udp SIP/2.0. Record-Route: <sip:10.64.5.16;r2=on;lr=on;nat=yes>. Record-Route: <sip:172.16.230.128;r2=on;lr=on;nat=yes>. Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bK9b0c.951b94b1.0. Via: SIP/2.0/UDP 172.16.230.1:61762 ;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport=61762. Max-Forwards: 16. Contact: <sip:2686959@172.16.230.1:61762;transport=udp>. To: <sip:7171001@xxx.connection-telecom.com>. From: "vc2 2686959"<sip:2686959@xxx.connection-telecom.com>;tag=c601fd36. Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. Proxy-Authorization: Digest username="2686959",realm=" xxx.connection-telecom.com ",nonce="520e1e50ef047461c3b0dbc731ccdc19e99990ce",uri=" sip:7171001@xxx.connection-telecom.com ;transport=udp",response="yyyyyyy",algorithm=MD5. Supported: replaces. User-Agent: Bria 3 release 3.5.3 stamp 70600. Content-Length: 278. P-hint: outbound. . v=0. o=- 1376656946792420 1 IN IP4 172.16.230.128. s=Bria 3 release 3.5.3 stamp 70600. c=IN IP4 172.16.230.128. t=0 0. m=audio 44320 RTP/AVP 8 18 101. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=yes. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=sendrecv. a=nortpproxy:yes. U 41.000.000.60:5060 -> 10.64.5.16:5060 SIP/2.0 100 Giving a try. <detail skipped> U 41.000.000.60:5060 -> 10.64.5.16:5060 SIP/2.0 180 Ringing. <detail skipped> OK comes back: U 41.000.000.60:5060 -> 10.64.5.16:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.64.5.16;rport=5060;received=10.64.5.16;branch=z9hG4bK9b0c.951b94b1.0. Via: SIP/2.0/UDP 172.16.230.1:61762 ;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport=61762. Record-Route: <sip:41.000.000.60;lr=on;ftag=c601fd36>. Record-Route: <sip:10.64.5.16;r2=on;lr=on;nat=yes>. Record-Route: <sip:172.16.230.128;r2=on;lr=on;nat=yes>. From: "vc2 2686959"<sip:2686959@xxx.connection-telecom.com>;tag=c601fd36. To: <sip:7171001@xxx.connection-telecom.com>;tag=as2a8e6d98. Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU. CSeq: 2 INVITE. Server: Enswitch. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH. Supported: replaces, timer. Contact: <sip:7171001@41.000.000.60:5070>. Content-Type: application/sdp. Content-Length: 306. . v=0. o=root 1056055966 1056055966 IN IP4 41.000.000.60. s=Asterisk PBX 1.8.12.2. c=IN IP4 41.000.000.60. t=0 0. m=audio 18130 RTP/AVP 8 18 101. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. a=direction:active. Sent on to phone, this one correctly munged. U 172.16.230.128:5060 -> 172.16.230.1:61762 SIP/2.0 200 OK. Via: SIP/2.0/UDP 172.16.230.1:61762 ;branch=z9hG4bK-d8754z-b743784d961b291c-1---d8754z-;rport=61762. Record-Route: <sip:41.000.000.60;lr=on;ftag=c601fd36>. Record-Route: <sip:10.64.5.16;r2=on;lr=on;nat=yes>. Record-Route: <sip:172.16.230.128;r2=on;lr=on;nat=yes>. From: "vc2 2686959"<sip:2686959@xxx.connection-telecom.com>;tag=c601fd36. To: <sip:7171001@xxx.connection-telecom.com>;tag=as2a8e6d98. Call-ID: ZTU1ODYyODY0YjJmMzk2ZmVhZmM5YTUzYWQzZTEzNGU. CSeq: 2 INVITE. Server: Enswitch. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH. Supported: replaces, timer. Contact: <sip:7171001@41.000.000.60:5070>. Content-Type: application/sdp. Content-Length: 326. . v=0. o=root 1056055966 1056055966 IN IP4 172.16.230.128. s=Asterisk PBX 1.8.12.2. c=IN IP4 172.16.230.128. t=0 0. m=audio 41166 RTP/AVP 8 18 101. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. a=direction:active. a=nortpproxy:yes. Watching the RTP flows, on the eth1 (internal) side I can see a flow from 172.16.230.1 (the phone) to 172.16.230.128 (the rtpproxy), but no flow back. On the eth0 side, I see a flow out from 172.16.230.128 going to my xxx.connection-telecom.com box. Wrong source address but it does get there and can be heard. There is no return flow. Most likely the Asterisk behind the opensips is sending audio to 172.16.230.128 since that is where it is getting audio from (i.e. Asterisk nat=yes). How to get the right address in the sdp of the outgoing invite? Thanks, Steve Davies

10 years, 12 months

Re: [SR-Users] kamailio STUN Server

by Olle E. Johansson

16 aug 2013 kl. 11:44 skrev "Premchandiran" <premchandiran.marimuthu(a)plintron.com>: > Hi All, > I am trying kamailio with STUN , I was able to enable STUN using > make cfg STUN=1 > my question is does kamailio itself STUN server? Since stun request (bind request) is sent from client kamailio is not responding. Somewhere read that kamailio uses liseten port as STUN also. > Kamailio is not a stun/turn server. What you enable here (or by using the new stun module) is the ability to respond to STUN requests on the SIP ports. /O

10 years, 12 months

Re: [SR-Users] Issues Kamailio 4.0 and Asterisk 11

by nisharmh85＠gmail.com

Any body please help me. What are the modifications required in that code if i use individual servers for sip server and media server. Regards, Nishar Hamsa -----Original Message----- From: SamyGo Sent: 15/08/2013, 4:15 PM To: "Kamailio (SER) - Users Mailing List" Subject: Re: [SR-Users] Issues Kamailio 4.0 and Asterisk 11

10 years, 12 months

Re: [SR-Users] kamailio STUN Server

by Peter Dunkley

If you are building from Git master STUN is now a module and is not compiled with "STUN=1". Whether you are using Git master or not, the Kamailio STUN implementation is limited. It is a partial implementation designed to run on the same port as SIP for the purposes of signalling NAT traversal. It works best in combination with SIP outbound (RFC 5626). If you are looking to use STUN for media NAT traversal (either in an ICE or non-ICE environment) you probably want to use a different (and more complete) STUN implementation. Regards, Peter On 16 August 2013 10:44, Premchandiran <premchandiran.marimuthu(a)plintron.com > wrote: > Hi All,**** > > I am trying kamailio with STUN , I was able to enable STUN using **** > > make cfg STUN=1**** > > my question is does kamailio itself STUN server? Since stun request (bind > request) is sent from client kamailio is not responding. Somewhere read > that kamailio uses liseten port as STUN also.**** > > ** ** > > Thanks and Regards,**** > > *Prem Chandiran M*** > > _______________________________________________ > 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 > > -- Peter Dunkley Technical Director Crocodile RCS Ltd

10 years, 12 months

kamailio STUN Server

by Premchandiran

Hi All, I am trying kamailio with STUN , I was able to enable STUN using make cfg STUN=1 my question is does kamailio itself STUN server? Since stun request (bind request) is sent from client kamailio is not responding. Somewhere read that kamailio uses liseten port as STUN also. Thanks and Regards, Prem Chandiran M

10 years, 12 months

usrloc error "Duplicate entry 'uloc-XXXXXXXX-XXXX-XXX' for key 'ruid_idx'"

by Victor Seva

Hello, I'm getting this kind of error running my unit test scenarios from time to time with no obvious reason, same tests usually runs without problems. Any pointers to figure out what is the problem? Cheers, Victor

10 years, 12 months

DID Routing

by Daniel W. Graham

Wondering how others handle DID routing? I have seen some former posts that talk about using alaias_db, however the request URI gets changed to the users SIP URI and the receiving device (asterisk) cant distinguish the DID as a result. Any thoughts are appreciated. -dan

10 years, 12 months

← Newer
1
...
9
10
11
12
13
14
15
...
18
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 August 2013