sr-users July 2014

sr-users@lists.kamailio.org

98 participants
140 discussions

by Alex Villacís Lasso

Just a quick question. What is supposed to be wrong with the below message? Jun 23 12:47:16 elx /usr/sbin/kamailio[20891]: ERROR: <core> [parser/parse_fline.c:243]: parse_first_line(): parse_first_line: bad message (offset: 22) Jun 23 12:47:16 elx /usr/sbin/kamailio[20891]: ERROR: <core> [parser/msg_parser.c:705]: parse_msg(): ERROR: parse_msg: message=<HTTP/1.1 101 Switching Protocols#015#012Via: SIP/2.0/TLS 192.168.3.2:58657#015#012Sec-WebSocket-Protocol: sip#015#012Upgrade: websocket#015#012Connection: upgrade#015#012Sec-WebSocket-Accept: Er/CgVyBNzVGREBmt+w3FTff8s4=#015#012Server: kamailio (4.1.4 (x86_64/linux))#015#012Content-Length: 0#015#012#015#012>

9 years, 9 months

Plz help: MSILO on TLS + cert based client auth enabled server

by Marc M.

Hi, I have a SIP server with TLS + client certificate based authentication. The server is listening for SIP(UDP) on port 5060, and for SIPS(TLS) on port 5061) The client certificate based authentication is enforced on port 5061. I would like to fire up MSILO and face now a strange problem: At each REGISTER, the stored messages get dumped. Dumped messages get sent to the clients from senders logged in over port 5060(UDP) as SIP:xxxxxxxxx@xx.xx.xx.xx however Dumped messages are NOT sent to clients from senders logged in on port 5061(TLS) as SIPS:xxxxxxxx@xx.xx.xx.xx It looks like the messages get dumped so M-dump() is working, but they will never enter the route. I would assume TLS is stopping the dumped messages to entering the route logic. I would either 1. somehow force m_dump() to pipe the messages over SIP(and not SIPS), or 2. disable client auth for messages recieved from local ip Can you help me how to proceed? What would be the correct approach? Can you help me with either 1 or 2. You help is greatly appreciated!!! Marc

9 years, 9 months

Only a redirect server

by Jack Smith

Dear friends, Just new to this mailing list, new to Kamailio, and new to running a sip server. I would like to try only a redirect server. I had a look at http://sourceforge.net/p/openser/code/HEAD/tree/trunk/examples/redirect.cfg which was friendly, but then the default file kamailio.cfg looked frightening ! Could someone help me set up a minimal Kamailio installation only to handle state-less redirect? Best, Jack

9 years, 9 months

append_branch and t_replicate issue

by Asgaroth

Hi All, I have an issue that I cant seem to get to the bottom of, I would appreciate if someone could point me in the right direction. I have 3 registrar's and would like to replicate the registration regest from 1 to the other 2, I am trying this with t_replicate, the docs say that to send to multiple destinations an append_branch should be performed prior to the t_replicate, which is what I am trying to do. What appears to happen is that the replication only sends the REGISTER to the server defined in the t_replicate command, it doesnt appear to be sending it to the destination defined in append_branch. Kamailio Version: version: kamailio 4.1.4 (x86_64/linux) 84c1ff 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: 84c1ff compiled on 14:36:04 Jul 20 2014 with gcc 4.4.7 Here is what I have tried so far (on registrar 1): #!define BACKUP_REGISTRAR_1 '1.1.1.1' #!define BACKUP_REGISTRAR_2 '1.1.1.2' #!define BACKUP_REGISTRAR_3 '1.1.1.3' save("location"); if ( src_ip != BACKUP_REGISTRAR_2 && src_ip != BACKUP_REGISTRAR_3 ) { append_branch("sip:" + BACKUP_REGISTRAR_2 + ":5060"); t_replicate("sip:" + BACKUP_REGISTRAR_3 + ":5060"); }; With the above in place, I only see the system attempting to replicate to BACKUP_REGISTRAR_3, I dont see any request to BACKUP_REGISTRAR_2. Am I doing something wrong here? Thanks Bruce

9 years, 9 months

possible regression on 4.1.3 vs 4.1.4

by Kelvin Chua

using the default cfg file, whenever a WITHINDLG BYE is received, 4.1.4 needs a retransmission before passing it through, the first BYE would generate this in syslog tm [tm.c:1518]: _w_t_relay_to(): ERROR: w_t_relay_to: unsupported route type: 64 and the 2nd retransmitted BYE would go on fine. i believe route type 64 is branch failure, but using the same cfg and reverting back to 4.1.3 solves it. so whatever changes was done to 4.1.4 broke it. Kelvin Chua

9 years, 9 months

Rtpengine vs. TURN?

by Peter Villeneuve

Hi, On my server, I have the option of using either Rtpengine for NAT traversal or pure TURN without rtpengine. Rtpengine has the obvious plus that it only needs 1 public IP, while TURN (with STUN) will need 2 public IPs, although that's not a problem in my case. Having said that, I'd like to take advantage of the huge experience that users of this list have in real world deployments. in your experience, which option is more reliable in a real world deployment? Cheers, Peter

9 years, 9 months

MSILO not checking Expires header if Allow: is absent and Contact: is present but without expires

by Anthony Messina

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

9 years, 9 months

407 Proxy Authentication Required with Cisco

by proLogika

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

9 years, 9 months

MESSAGE forking bug(?)

by Allen Zhang

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

9 years, 9 months

Late parallel forking

by Guillaume Bour

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

9 years, 9 months

← Newer
1
2
3
4
5
6
7
8
...
14
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 July 2014