sr-users

sr-users@lists.kamailio.org

35 participants
37544 discussions

MSILO not checking Expires header if Allow: is absent and Contact: is present but without expires
by Anthony Messina 25 Jul '14

25 Jul '14

In setting up Kamailio with MSILO, I've noticed that some sip clients (I'm using CSipSimple), upon un-REGISTER-ing do not send an Allow header, but do send an "Expires: 0" header as well as a Contact header. However as the Contact header doesn't contain "expires=0", it appears as though the MSILO skips over checking the Expires header. As such, I've had to add the following workaround to my route[REGISTRAR] block or else these clients trigger the m_dump. # Ensure we aren't unregistering # Right now, CSipSimple doesn't send an Allow header with an un-REGISTER, # so Kamailio skips to checking the Contact header for expires, and appears # to ignore the fact that an Expires: 0 header is present. if($hdr(Expires) != 0) m_dump(); Looking through the msilo check_message_support function, it appears that it never checks for the Expires header if there is no Allow header and the Contact header does not specify an expire setting. I do believe that we're missing the check for the Expires header, regardless of whether or not there is an Allow header, or a Contact header with expires=0 -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

2 4

407 Proxy Authentication Required with Cisco
by proLogika 25 Jul '14

25 Jul '14

Hello, I am using Kamailio as SIP register with asterisk integration describe from hire: http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb . asterisk is listen on public ip: 2.3.4.5:5060 kamailio is listen on public ip: 1.2.3.4:5060 everything is working well except some software VoIP clients (like Yate) and CISCO phone like Cisco-CP7940G/8.0 and the new one from Cisco series. I’m testing now with Yate client and Cisco. They are register OK but when a call is made Kamailio is answer back with 407 Proxy Authentication Required. When I register Yate or Cisco to asterisk directly the call is passing normaly. I was trying to manipulate kamailio.cfg and more specifically the part: #!ifdef WITH_ASTERISK if (!auth_check("$fd", "sipusers", "1")) { #!else if (!auth_check("$fd", "subscriber", "1")) { #!endif auth_challenge("$fd", "0"); exit; If i commented out this part the call is passing, but I do not have auth anymore (everyone can register) Here is ngrep: U 2014/07/23 19:17:08.108458 192.168.0.40:5060 -> 1.2.3.4:5060 INVITE sip:0896995837@1.2.3.4 SIP/2.0. Max-Forwards: 20. Via: SIP/2.0/UDP 192.168.0.40:5060;rport;branch=z9hG4bK1899510692. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>. Call-ID: 931919626(a)1.2.3.4. CSeq: 13 INVITE. User-Agent: YATE/5.3.0. Contact: <sip:10891@192.168.0.40:5060>. Allow: ACK, INVITE, BYE, CANCEL, OPTIONS, INFO. Content-Type: application/sdp. Content-Length: 481. . v=0. o=yate 1406132227 1406132227 IN IP4 192.168.0.40. s=SIP Call. c=IN IP4 192.168.0.40. t=0 0. m=audio 29696 RTP/AVP 0 8 11 98 97 102 103 104 105 106 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:11 L16/8000. a=rtpmap:98 iLBC/8000. a=fmtp:98 mode=20. a=rtpmap:97 iLBC/8000. a=fmtp:97 mode=30. a=rtpmap:102 SPEEX/8000. a=rtpmap:103 SPEEX/16000. a=rtpmap:104 SPEEX/32000. a=rtpmap:105 iSAC/16000. a=rtpmap:106 iSAC/32000. a=rtpmap:101 telephone-event/8000. a=ptime:30. U 2014/07/23 19:17:08.108805 1.2.3.4:5060 -> 192.168.0.40:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.0.40:5060;rport=5060;branch=z9hG4bK1899510692. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>;tag=6be166fd53062bbc5b6dd79656b620cd.1950. Call-ID: 931919626(a)1.2.3.4. CSeq: 13 INVITE. Proxy-Authenticate: Digest realm="1.2.3.4", nonce="U8/hMFPP4AR+N3A+ZccNiTw6rV9JTq1I". Server: kamailio (4.0.6 (x86_64/linux)). Content-Length: 0. . U 2014/07/23 19:17:08.128626 192.168.0.40:5060 -> 1.2.3.4:5060 ACK sip:0896995837@1.2.3.4 SIP/2.0. Via: SIP/2.0/UDP 192.168.0.40:5060;rport;branch=z9hG4bK1899510692. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>;tag=6be166fd53062bbc5b6dd79656b620cd.1950. Call-ID: 931919626(a)1.2.3.4. CSeq: 13 ACK. Max-Forwards: 20. Contact: <sip:10891@192.168.0.40:5060>. User-Agent: YATE/5.3.0. Content-Length: 0. . U 2014/07/23 19:17:08.129076 192.168.0.40:5060 -> 1.2.3.4:5060 INVITE sip:0896995837@1.2.3.4 SIP/2.0. Max-Forwards: 20. Via: SIP/2.0/UDP 192.168.0.40:5060;rport;branch=z9hG4bK302777344. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>. Call-ID: 931919626(a)1.2.3.4. User-Agent: YATE/5.3.0. Contact: <sip:10891@192.168.0.40:5060>. Allow: ACK, INVITE, BYE, CANCEL, OPTIONS, INFO. CSeq: 14 INVITE. Proxy-Authorization: Digest username="10891", realm="1.2.3.4", nonce="U8/hMFPP4AR+N3A+ZccNiTw6rV9JTq1I", uri="sip:0896995837@1.2.3.4", response="b96eebd48b3734e1d018a970fa3a2283", algorithm=MD5. Content-Type: application/sdp. Content-Length: 481. . v=0. o=yate 1406132227 1406132227 IN IP4 192.168.0.40. s=SIP Call. c=IN IP4 192.168.0.40. t=0 0. m=audio 29696 RTP/AVP 0 8 11 98 97 102 103 104 105 106 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:11 L16/8000. a=rtpmap:98 iLBC/8000. a=fmtp:98 mode=20. a=rtpmap:97 iLBC/8000. a=fmtp:97 mode=30. a=rtpmap:102 SPEEX/8000. a=rtpmap:103 SPEEX/16000. a=rtpmap:104 SPEEX/32000. a=rtpmap:105 iSAC/16000. a=rtpmap:106 iSAC/32000. a=rtpmap:101 telephone-event/8000. a=ptime:30. U 2014/07/23 19:17:08.129622 1.2.3.4:5060 -> 192.168.0.40:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.0.40:5060;rport=5060;branch=z9hG4bK302777344. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>. Call-ID: 931919626(a)1.2.3.4. CSeq: 14 INVITE. Server: kamailio (4.0.6 (x86_64/linux)). Content-Length: 0. . U 2014/07/23 19:17:08.130107 1.2.3.4:5060 -> 2.3.4.5:5060 INVITE sip:0896995837@1.2.3.4 SIP/2.0. Record-Route: <sip:1.2.3.4;lr=on;ftag=838449717;nat=yes>. Max-Forwards: 16. Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK73f1.c43865a50d7a342a46dcebf824782de0.0. Via: SIP/2.0/UDP 192.168.0.40:5060;rport=5060;branch=z9hG4bK302777344. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>. Call-ID: 931919626(a)1.2.3.4. User-Agent: YATE/5.3.0. Contact: <sip:10891@192.168.0.40:5060>. Allow: ACK, INVITE, BYE, CANCEL, OPTIONS, INFO. CSeq: 14 INVITE. Content-Type: application/sdp. Content-Length: 499. . v=0. o=yate 1406132227 1406132227 IN IP4 1.2.3.4. s=SIP Call. c=IN IP4 1.2.3.4. t=0 0. m=audio 21888 RTP/AVP 0 8 11 98 97 102 103 104 105 106 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:11 L16/8000. a=rtpmap:98 iLBC/8000. a=fmtp:98 mode=20. a=rtpmap:97 iLBC/8000. a=fmtp:97 mode=30. a=rtpmap:102 SPEEX/8000. a=rtpmap:103 SPEEX/16000. a=rtpmap:104 SPEEX/32000. a=rtpmap:105 iSAC/16000. a=rtpmap:106 iSAC/32000. a=rtpmap:101 telephone-event/8000. a=ptime:30. a=nortpproxy:yes. U 2014/07/23 19:17:08.130593 2.3.4.5:5060 -> 1.2.3.4:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK73f1.c43865a50d7a342a46dcebf824782de0.0;received=1.2.3.4;rport=5060. Via: SIP/2.0/UDP 192.168.0.40:5060;rport=5060;branch=z9hG4bK302777344. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>;tag=as31a58bb2. Call-ID: 931919626(a)1.2.3.4. CSeq: 14 INVITE. Server: Asterisk PBX 1.8.29.0. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7531867c". Content-Length: 0. . U 2014/07/23 19:17:08.130770 1.2.3.4:5060 -> 2.3.4.5:5060 ACK sip:0896995837@1.2.3.4 SIP/2.0. Max-Forwards: 16. Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK73f1.c43865a50d7a342a46dcebf824782de0.0. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>;tag=as31a58bb2. Call-ID: 931919626(a)1.2.3.4. CSeq: 14 ACK. Content-Length: 0. . U 2014/07/23 19:17:08.131361 1.2.3.4:5060 -> 192.168.0.40:5060 SIP/2.0 401 Unauthorized. Via: SIP/2.0/UDP 192.168.0.40:5060;rport=5060;branch=z9hG4bK302777344. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>;tag=as31a58bb2. Call-ID: 931919626(a)1.2.3.4. CSeq: 14 INVITE. Server: Asterisk PBX 1.8.29.0. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7531867c". Content-Length: 0. . U 2014/07/23 19:17:08.149847 192.168.0.40:5060 -> 1.2.3.4:5060 ACK sip:0896995837@1.2.3.4 SIP/2.0. Via: SIP/2.0/UDP 192.168.0.40:5060;rport;branch=z9hG4bK302777344. From: <sip:10891@1.2.3.4>;tag=838449717. To: <sip:0896995837@1.2.3.4>;tag=as31a58bb2. Call-ID: 931919626(a)1.2.3.4. CSeq: 14 ACK. Max-Forwards: 20. Contact: <sip:10891@192.168.0.40:5060>. Proxy-Authorization: Digest username="10891", realm="1.2.3.4", nonce="U8/hMFPP4AR+N3A+ZccNiTw6rV9JTq1I", uri="sip:0896995837@1.2.3.4", response="b96eebd48b3734e1d018a970fa3a2283", algorithm=MD5. User-Agent: YATE/5.3.0. Content-Length: 0. — And kamailio.cfg attached: proLogika Sent with Airmail

2 1

MESSAGE forking bug(?)
by Allen Zhang 24 Jul '14

24 Jul '14

Hi, I believe there is a bug on MESSAGE forking. Test scenario: User A has two records in the location table, with different instance ids: 111 and 222. One of user A's instance is killed, hence 222 is not reachable. User B send a MESSAGE to user A. Kamailio forked the MESSAGE. Kamailio got a '200 Message delivered' response from 111 and forwarded it to user B. The MESSAGE forked to 222 timed out. Kamailio send a '408 Time out' to user B. This violates RFC 3428 section 4. It states that the forking UAS should only send ONE final response to the sender UAC. Forking is done by t_relay(), and the registrar parameter 'append_branches' is set to default value 1. Did I do something wrong, or there is a bug? Regards, Allen

2 5

Late parallel forking
by Guillaume Bour 24 Jul '14

24 Jul '14

Hi, I would like to do some kind of "late parallel forking" (see the example below). Is there a way to do such thing with Kamailio ? Here is an example: . A call B . B device 1 is connected so INVITE is forwarded to it . B device 2 registers succesfully . as device 1 as not yet answered and INVITE transaction is not expired, I want INVITE message to be forwarded to device 2 (so both are ringing) Regards, Guillaume Bour

4 6

Outbound registration?
by James Cloos 23 Jul '14

23 Jul '14

I don't see anything relevant in the docs, nor greping the src, but in case I missed something: Does the core, or do any of the modules support originating registration requests to other proxies a/o endpoints? I'd like to move registration responsibility to kama, and have it add a header on incoming INVITEs and the like from anything with which it has REGISTERed indicating which outbound registration is relevant to said request. If I'm right that there isn't support for that, do any of the app modules expose enough sip capability easily to write such? -JimC -- James Cloos <cloos(a)jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

3 4

Configuration kamailio + siremis
by Tomasz Sidło 23 Jul '14

23 Jul '14

Hello all I'm looking for the person who configures my kamailio + siremis I'll pay for the full configuration. Kamailio is to work together with a asterisk if anyone willing please contact me mail tomasz(a)sidlo.pl

1 0

Kamailio RtpProxy MHomed
by Pascal Fautré 23 Jul '14

23 Jul '14

Hi, I tried to use Kamailio / RTPProxy in mhomed setup without any luck. I had no problem to configure it with only 1 interface, without mhomed, everything worked perfectly. The RTP streams where not established correctly even if I managed to have to proper IP in the SIP INVITE (C & O). Versions: version: kamailio 4.1.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 04:23:19 Jun 13 2014 with gcc 4.7.2 RTPProxy -v: 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 Here is my RTPProxy config (/etc/default/rtpproxy) : CONTROL_SOCK=udp:127.0.0.1:7722 EXTRA_OPTS=“-l PU.BL.IC.IP/PRI.VA.TE.IP -m 11000 -M 12000 -d DBUG:LOG_LOCAL3 Here are snippets of my kamailio.cfg: port=5060 mhomed=1 # 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; xlog("NATMANAGE M=$rm OU=$ou RURI=$ru RD=$rd F=$fu T=$tu NH=$nh(d) IP=$si ID=$ci\n"); if(dst_ip == PUBLIC_IP) { if(is_ipv4($nh(d)) && is_in_subnet($nh(d), PRIVATE_NET)) { xlog("NATMANAGE coei\n"); rtpproxy_manage("coei", PRIVATE_IP); } else { xlog("NATMANAGE coee\n"); rtpproxy_manage("coee", PUBLIC_IP); } } else { if(is_ipv4($nh(d)) && is_in_subnet($nh(d), PRIVATE_NET)) { xlog("NATMANAGE coii\n"); rtpproxy_manage("coii", PRIVATE_IP); } else { xlog("NATMANAGE coie\n"); rtpproxy_manage("coie", PUBLIC_IP); } } if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) set_contact_alias(); } } #!endif return; } Calls were correctly going to the desired rtpproxy_manage options. Now I’m not quite sure I’m using the correct ones. I had to specify the PUBLIC_IP or PRIVATE_IP in the rtpproxy_manage calls in order to have the correct IP address in the C and O headers of the SIP INVITE. Without that, the public IP would be sent as C and O params to phones on the private subnet. In fact not a single call direction would give correct RTP streams. Any idea where I missed the turn? Cheers

4 10

core:drop_requests meaning
by Alex Balashov 23 Jul '14

23 Jul '14

Hi, I was wondering what precisely these stats mean: core:drop_replies = 0 core:drop_requests = 3 Assuming one does not explicitly drop() requests anywhere in script, would a continuous monotonic increase in drop_requests be considered a problem? Or are there some normal circumstances and ordinary behaviours (i.e. auth challenges) that would register a request drop? Thanks, -- Alex -- Alex Balashov - Principal Evariste Systems LLC Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ Please be kind to the English language: http://www.entrepreneur.com/article/232906

2 3

server for git repository is down
by Daniel-Constantin Mierla 22 Jul '14

22 Jul '14

Hello, a short note to say that the server for git repository on sip-router.org is down. The hosting provider hasn't reported any maintenance, I am digging further into it to see what happened. Meanwhile, the mirror on github can be used if anyone wants to fetch the source tree: - https://github.com/kamailio/kamailio Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 1

How install Kamailio with Asterisk
by ANTHONY HESNAUX 22 Jul '14

22 Jul '14

hello all, I would install kamailio with ASTERISK in realtime on CENTOS 6.5 x64. I followed the tutorial aspito: http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb but its not work. I have a problem with kamailio.cfg Its not possible to start kamailio When I loadmodule "uac.so" I want to make this configuration: SIP phone1 -> Register Kamailio -> ASTERISK Register SIP phone 2 -> Register Kamailio -> ASTERISK Register kamailio: 192.168.0.100 Port: 5060 ASTERISK: 192.168.0.100 Port 5080

3 6

Jump to page:

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