sr-users October 2015

sr-users@lists.kamailio.org

77 participants
125 discussions

Kamailio and FreeSwitch - ClueCon Weekly Conference Call

by Daniel-Constantin Mierla

On Wednesday, October 21, 2015, at 17:00GMT (12:00CT, 18:00 London, 19:00 Berlin), the Cluecon weekly conference call will focus on Kamailio and FreeSwitch. I will be joining the call, answering the questions about Kamailio and its options to integrate with FreeSwitch. Expect the FreeSwitch core developers to be around to handle the questions about their project. Participation is open for anyone, you can dial in for audio or video sessions using a SIP phone or webrtc capable browser: - sip:888@conference.freeswitch.org - https://cantina.freeswitch.org/vc More dial in options (e.g., PSTN) are presented at: - https://freeswitch.org/confluence/display/FREESWITCH/ClueCon+Weekly+Confere… Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com

8 years, 6 months

MSILO module

by Safdar Khan

How can i store messages in silo table not only offline also online.Demo code will be appreciated.waiting for response.

8 years, 6 months

htable never

by Juha Heinanen

i noticed that entries that i had added to htable at sip proxy start in event_route [htable:mod-init], e.g., $sht(htable=>app_srv::sbc::<null>) = "sip:SBC:SEMS_PORT"; had disappeared from htable after some (don't know exactly how long) time. i have not specified any autoexpire for that table: modparam("htable", "htable", "htable=>size=HTABLE_SIZE;dbtable=htable;") after restart of sip proxy they reappeared in htable like this: # sip-proxy_ctl htable.get htable 'app_srv::sbc::<null>' { item: { name: app_srv::sbc::<null> value: sip:127.0.0.1:5090 flags: 2 expire: NEVER } } what could explain the disappearance? -- juha

8 years, 6 months

Implementation of RFC 5393

by Guillaume

Hi guys, What do you think about the RFC 5393 on loop detection and amplification attack protection? The RFC is short and still a proposed standard but don't you think it could be useful to prevent loop and amplification attack? Because even if the max-forward field reduces the loop to ~70 hosts (in most cases) with some techniques we could fork the message up to 2^70 messages (as described in the RFC) to crash the servers. Basically the server has to do 2 things: * check if it is not already in the via of the message * the previous check is not enough as a B2BUA could have replace the via headers, so the RFC introduces a new field called max-breadth to limit the forking. I have not seen a lot of implementation of this RFC on the free SIP software and I think it could be a good way to improve kamailio making a module for it (the easier way to implement this feature I think). In fact I'm in a research internship about VoIP security and I have time to develop such a module for kamailio if you think it's a good idea (I'm looking for some security improvements in free software solutions so if you have other idea don't hesitate to tell me). Cheers, Tetram

8 years, 6 months

pua_dialoginfo publish sent without recieved etag (intermittent)

by Asgaroth

Hi All, I've come accross an intermittent issue where an initial publish is sent to our presence server, proxy recieves the subsequent 200 with etag, but the following publish sent does not contain the sip-if-match header of the recieved 200, which ends up causing trouble with BLF on our test devices, it also has the added side affect of not being cleared out of the presentity table, these entries need to be manually removed. This does not occur all the time, I can use the same phone and make several calls before this issue occurs. It is not limited to a device type, we've tried with panasonic, polycom, cisco, zoiper, yealink and linksys devices, all exhibit the same sporadic behaviour. I've attached an example sip trace of the publish messages where this happens, you can see the second publish doesnt have the sip-if-match header whose content should be that of the sip-etag in the previous 200 to the initial publish. I'm not sure if there is something I am misunderstanding here, a configuration issue, or if this is indeed a bug. Both the proxy and the presence server are running kamailio v4.3.3. Any pointers/suggestions/guidance would be appreciated. If you need any additional info, please dont hesitate to ask. Thanks

8 years, 6 months

Sending ReINVITE from Kamailio

by Grant Bagdasarian

Hello, Is it possible to have Kamailio send a ReINVITE every X minutes to determine if a session is still active? I know it's a proxy and doesn't have B2BUA capabilities, but there was a module which allowed Kamailio to generate SIP messages, but I can't find it anymore. If Kamailio is not the place to do this, which component in the voip network should be responsible for this? Are there perhaps other ways to poll for session state in Kamailio? Regards, Grant

8 years, 6 months

Re: [SR-Users] MySQL Connect Errors

by John Billings

Both boxes are running Debian 8. I’m still looking at the mysql logs, but I haven’t found anything relevant, yet. > On Oct 14, 2015, at 5:00 AM, sr-users-request(a)lists.sip-router.org wrote: > > Hello, > > do you have centos+selinux? Because I heard about a lot of limits with > the combination of the two. > > Have you checked the mysqld syslog messages, anything relevant there? > > Cheers, > Daniel >

8 years, 6 months

Far end NAT traversal

by NITESH BANSAL

Hello, I would really appreciate if someone can point me to some documentation for Far end nat traversal in Kamailio. Thanks,Nitesh

8 years, 6 months

Dialog timeout if record route have both strict and loose route

by Arun Kumar

Hi dialog timeout is occurred if 200 ok having mixed loose and strict routing entries in record route header conf file attached INVITE sip:123456789@22.22.22.22:5060 SIP/2.0 Via: SIP/2.0/UDP 176.204.26.157:63939 ;rport;branch=z9hG4bKPjvAKLQD72G88kpqC2IJwbmTcXUlHGULcW Max-Forwards: 70 From: sip:123455555@22.22.22.22;tag=E9YwhssbjdD63KZpXep-UCmOxshWrcwu To: sip:123456789@22.22.22.22 Contact: <sip:123455555@176.204.26.157:63939;ob> Call-ID: VlaYDWuM5COSfEIqydwAxFM76TLv7Syh CSeq: 14602 INVITE Route: <sip:11.11.11.11:345;lr> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: zeo-iphone Opcode: 19815 Content-Type: application/sdp Content-Length: 320 v=0 o=- 3653999880 3653999880 IN IP4 10.220.83.191 s=pjmedia b=AS:25 t=0 0 a=X-nat:0 m=audio 4000 RTP/AVP 18 96 c=IN IP4 10.220.83.191 b=TIAS:8000 a=rtcp:4001 IN IP4 10.123.11.223 a=sendrecv a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=X-adapter:some value SIP/2.0 407 Proxy Authentication required Via: SIP/2.0/UDP 11.11.11.11:345;branch=z9hG4bK3d4f.6f8dff1ec0806cb23f56d847d5fe3934.0,SIP/2.0/UDP 176.204.26.157:63939 ;rport=63939;branch=z9hG4bKPjvAKLQD72G88kpqC2IJwbmTcXUlHGULcW;received=176.204.26.157 From: <sip:123455555@22.22.22.22>;tag=E9YwhssbjdD63KZpXep-UCmOxshWrcwu To: <sip:123456789@22.22.22.22> Call-ID: VlaYDWuM5COSfEIqydwAxFM76TLv7Syh CSeq: 14602 INVITE Proxy-Authenticate: Digest nonce="6b24dc6996de20028c78dbeaf13edc55",realm="22.22.22.22",opaque="",stale=FALSE,algorithm=MD5 Content-Length: 0 ACK sip:123456789@22.22.22.22:5060 SIP/2.0 Via: SIP/2.0/UDP 176.204.26.157:63939 ;rport;branch=z9hG4bKPjvAKLQD72G88kpqC2IJwbmTcXUlHGULcW Max-Forwards: 70 From: sip:123455555@22.22.22.22;tag=E9YwhssbjdD63KZpXep-UCmOxshWrcwu To: sip:123456789@22.22.22.22 Call-ID: VlaYDWuM5COSfEIqydwAxFM76TLv7Syh CSeq: 14602 ACK Route: <sip:11.11.11.11:345;lr> Content-Length: 0 INVITE sip:123456789@22.22.22.22:5060 SIP/2.0 Via: SIP/2.0/UDP 176.204.26.157:63939 ;rport;branch=z9hG4bKPjmWCyQQWaKBZC0fGKfS2LCXCIklN-UIHI Max-Forwards: 70 From: sip:123455555@22.22.22.22;tag=E9YwhssbjdD63KZpXep-UCmOxshWrcwu To: sip:123456789@22.22.22.22 Contact: <sip:123455555@176.204.26.157:63939;ob> Call-ID: VlaYDWuM5COSfEIqydwAxFM76TLv7Syh CSeq: 14603 INVITE Route: <sip:11.11.11.11:345;lr> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: zeo-iphone Opcode: 19815 Proxy-Authorization: Digest username="123455555", realm="22.22.22.22", nonce="6b24dc6996de20028c78dbeaf13edc55", uri=" sip:123456789@22.22.22.22:5060", response="554a1da255084f7a95d3b6e7a0c48933", algorithm=MD5 Content-Type: application/sdp Content-Length: 320 v=0 o=- 3653999880 3653999880 IN IP4 10.220.83.191 s=pjmedia b=AS:25 t=0 0 a=X-nat:0 m=audio 4000 RTP/AVP 18 96 c=IN IP4 10.220.83.191 b=TIAS:8000 a=rtcp:4001 IN IP4 34.220.83.191 a=sendrecv a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=X-adapter:some value SIP/2.0 100 Trying Via: SIP/2.0/UDP 11.11.11.11:345;branch=z9hG4bK4d4f.b793c28bbb6684da0ad60d4320be2d6b.0,SIP/2.0/UDP 176.204.26.157:63939 ;rport=63939;branch=z9hG4bKPjmWCyQQWaKBZC0fGKfS2LCXCIklN-UIHI;received=176.204.26.157 From: <sip:123455555@22.22.22.22>;tag=E9YwhssbjdD63KZpXep-UCmOxshWrcwu To: <sip:123456789@22.22.22.22> Call-ID: VlaYDWuM5COSfEIqydwAxFM76TLv7Syh CSeq: 14603 INVITE Content-Length: 0 SIP/2.0 183 Session progress Via: SIP/2.0/UDP 11.11.11.11:345;branch=z9hG4bK4d4f.b793c28bbb6684da0ad60d4320be2d6b.0,SIP/2.0/UDP 176.204.26.157:63939 ;rport=63939;branch=z9hG4bKPjmWCyQQWaKBZC0fGKfS2LCXCIklN-UIHI;received=176.204.26.157 From: <sip:123455555@22.22.22.22>;tag=E9YwhssbjdD63KZpXep-UCmOxshWrcwu To: <sip:123456789@22.22.22.22>;tag=GB-1445011078679 CSeq: 14603 INVITE Call-ID: VlaYDWuM5COSfEIqydwAxFM76TLv7Syh Contact: <sip:22.22.22.22:5060> Content-Type: application/sdp Record-Route: <sip:22.22.22.22:5060;lr>,<sip:11.11.11.11:345;lr> Content-Length: 298 v=0 o=- 3653999880 3653999880 IN IP4 50.56.154.204 s=zeodialer c=IN IP4 50.33.154.204 b=AS:25 t=0 0 m=audio 53128 RTP/AVP 18 96 c=IN IP4 50.33.154.204 b=TIAS:8000 a=rtpmap:18 G729/8000 a=sendrecv a=fmtp:18 annexb=no a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-16 a=X-adapter:some value SIP/2.0 183 Session Progress Record-Route: <sip:22.22.22.22:5060;lr>,<sip:11.11.11.11:345> Call-ID: VlaYDWuM5COSfEIqydwAxFM76TLv7Syh CSeq: 14603 INVITE Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,NOTIFY,MESSAGE,UPDATE P-Early-Media: sendrecv Contact: <sip:22.22.22.22:5060> Via: SIP/2.0/UDP 11.11.11.11:345;branch=z9hG4bK4d4f.b793c28bbb6684da0ad60d4320be2d6b.0,SIP/2.0/UDP 176.204.26.157:63939 ;rport=63939;branch=z9hG4bKPjmWCyQQWaKBZC0fGKfS2LCXCIklN-UIHI;received=176.204.26.157 To: <sip:123456789@22.22.22.22>;tag=GB-1445011078679 Content-Type: application/sdp From: <sip:123455555@22.22.22.22>;tag=E9YwhssbjdD63KZpXep-UCmOxshWrcwu Content-Length: 212 v=0 o=- 1426744035 1426744035 IN IP4 50.56.154.204 s=Nexge c=IN IP4 50.22.154.204 t=0 0 m=audio 53128 RTP/AVP 18 96 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:96 telephone-event/8000 a=ptime:20 SIP/2.0 200 OK Record-Route: <sip:22.22.22.22:5060;lr>,<sip:11.11.11.11:345> Call-ID: VlaYDWuM5COSfEIqydwAxFM76TLv7Syh CSeq: 14603 INVITE Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,NOTIFY,MESSAGE,UPDATE Contact: <sip:22.22.22.22:5060> Via: SIP/2.0/UDP 11.11.11.11:345;branch=z9hG4bK4d4f.b793c28bbb6684da0ad60d4320be2d6b.0,SIP/2.0/UDP 176.204.26.157:63939 ;rport=63939;branch=z9hG4bKPjmWCyQQWaKBZC0fGKfS2LCXCIklN-UIHI;received=176.204.26.157 To: <sip:123456789@22.22.22.22>;tag=GB-1445011078679 Content-Type: application/sdp From: <sip:123455555@22.22.22.22>;tag=E9YwhssbjdD63KZpXep-UCmOxshWrcwu Content-Length: 212 v=0 o=- 1426744035 1426744035 IN IP4 50.56.154.204 s=Nexge c=IN IP4 50.33.44.204 t=0 0 m=audio 53128 RTP/AVP 18 96 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:96 telephone-event/8000 a=ptime:20 ACK sip:11.11.11.11:345 SIP/2.0 Via: SIP/2.0/UDP 176.204.26.157:63939 ;rport;branch=z9hG4bKPjldbprXw3ybGOxoeKWwvtdxLmNp8jXsOX Max-Forwards: 70 From: sip:123455555@22.22.22.22;tag=E9YwhssbjdD63KZpXep-UCmOxshWrcwu To: sip:123456789@22.22.22.22;tag=GB-1445011078679 Call-ID: VlaYDWuM5COSfEIqydwAxFM76TLv7Syh CSeq: 14603 ACK Route: <sip:22.22.22.22:5060;lr> Route: <sip:22.22.22.22:5060> Content-Length: 0

8 years, 6 months

kamctl rtpproxy nh_show_rtpp not working

by amar Smart Telecom

Dear all, I have installed Kamailio and Rtpproxy. Following is the process (ps) info: "kamailio 648 1 0 Oct08 ? 00:00:05 /usr/bin/rtpproxy -s udp:127.0.0.1 7722 -u kamailio kamailio -p /var/run/rtpproxy/rtpproxy.pid -l 192.168.58.25" But when I give command: " kamctl mi nh_show_rtpp" it returns following: "500 command 'nh_show_rtpp' not available" What could be the problem? Thanks, Amar.

8 years, 6 months

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