sr-users

sr-users@lists.kamailio.org

19 participants
37529 discussions

Re: [SR-Users] Regarding RTP in IMS Networks.
by Badri Ranganathan 24 Feb '15

24 Feb '15

Hi all, I'll make this question a little clearer. User 1 ---------------- SBC ----+ other IMS network components ---------------------- User 2 Same scenario User 1 Making the call + plays RTP Traffic User 2 Answering the call + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis If user 2, after answering the call, did not play RTP as well, the SBC will not forward the RTP from User 1 to User 2. [The media gateways responsible for the RTP traffic is also a part of the IMS network right?] So why this sort of bi-directional traffic imposition in an IMS Network ? Thanks, Badri. -----Original Message----- From: Badri Ranganathan Sent: 24 February 2015 15:13 To: sr-users(a)lists.sip-router.org Subject: Regarding RTP in IMS Networks. Hi all, I have a doubt w.r.t media traffic in IMS Networks. If I have a setting as follows - User 1 Making the call + plays RTP Traffic User 2 Answering the call + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis I see that User 2 has to play RTP Traffic before it can start recording the RTP coming from user 1. i.e., User 2 Answering the call + (Play RTP Traffic ) + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis. Why am I seeing this behaviour. Is it just a setting in the IMS network that can be changed or is it a standard behaviour in IMS Networks ? If yes, then could anyone please let me know the logic behind such a decision? Please do let me know if you have any ideas. Any responses really appreciated ! Thanks, Badri.

2 1

Regarding RTP in IMS Networks.
by Badri Ranganathan 24 Feb '15

24 Feb '15

Hi all, I have a doubt w.r.t media traffic in IMS Networks. If I have a setting as follows - User 1 Making the call + plays RTP Traffic User 2 Answering the call + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis I see that User 2 has to play RTP Traffic before it can start recording the RTP coming from user 1. i.e., User 2 Answering the call + (Play RTP Traffic ) + records the RTP Traffic coming from User 1 and does a PESQ voice quality analysis. Why am I seeing this behaviour. Is it just a setting in the IMS network that can be changed or is it a standard behaviour in IMS Networks ? If yes, then could anyone please let me know the logic behind such a decision? Please do let me know if you have any ideas. Any responses really appreciated ! Thanks, Badri.

1 0

Drouting Question
by Andrew Okri 24 Feb '15

24 Feb '15

Hi All, Does dropping set the $du or $ru uri when it finds a match in the database? I am getting destination not set error in my debug trace and he call request times out as a result. Regards Andrew Okri

1 0

kamailio crash
by kovarik＠odorik.cz 23 Feb '15

23 Feb '15

Hello, kamailio crash if receive this invite (full pcap in attach): INVITE sip:+420235356120@sip.odorik.cz SIP/2.0 Via: SIP/2.0/TCP 89.103.14.100:5060;branch=z9hG4bKader9m419p44oh1arfvg3q3;rport From: <sip:680114@sip.odorik.cz>;tag=n67dnvutedhc7h8g0723 To: <sip:+420235356120@sip.odorik.cz> Contact: <sip:4WJEcOsCK95r_THu1yoG@89.103.14.100:5060;comp=sigcomp> Supported: 100rel,timer CSeq: 2374 INVITE Call-ID: PKnr_QhkoIfgFw74ch7P9QzSx4Utqm Allow: UPDATE,PRACK,SUBSCRIBE,REFER,NOTIFY,INVITE,ACK,CANCEL,OPTIONS,BYE User-Agent: Nokia RM-469 091.003 (cs) Expires: 120 Privacy: None Session-Expires: 1800 Max-Forwards: 69 Proxy-Authorization: Digest realm="sip.odorik.cz",nonce="VOd181TndMfi5yGjm4maxIr8yb1s/ARs",algorithm=MD5,username="680114",uri="sip:+420235356120@sip.odorik.cz",response="11aa17ebbf02d284c1fa5b03bca7fd89" Content-Type: application/sdp Accept-Language: cs Content-Length: 540 v=0 o=680114 63592714297343250 63592714297343250 IN IP4 89.103.14.100 s=- c=IN IP4 89.103.14.100 t=0 0 m=audio 49152 RTP/AVP 100 96 0 8 97 18 98 13 a=sendrecv a=rtpmap:100 AMR-WB/16000 a=ptime:20 a=maxptime:200 a=fmtp:100 mode-change-period=2; mode-change-neighbor=1 a=rtpmap:96 AMR/8000 a=fmtp:96 mode-set=0,1,2,3,4,5,6,7; mode-change-neighbor=1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:98 telephone-event/8000 a=fmtp:98 0-15 a=rtpmap:13 CN/8000 and in run im kamailio.cfg $var(codecs)="G729,PCMA,GSM,iLBC,speex,telephone-event"; sdp_keep_codecs_by_name($var(codecs)); Kamailio crash with gdb export crash_20.02.2015 in attachments. kamailio -v version: kamailio 4.2.3 (x86_64/linux) 9524b3-dirty 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, F_MALLOC, DBG_F_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 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 9524b3 -dirty compiled on 23:32:12 Feb 19 2015 with gcc 4.7.2 Thank you.

2 2

Best practices for unsetting PVs
by Alex Balashov 23 Feb '15

23 Feb '15

Hi, We have this approach for arrayable PVs (e.g. AVPs, XAVPs): $(avp(var)[*]) = $null; This defines the PV, but sets its value to null. I haven't tested, but I would assume, in the case of an AVP, that this would cause it to fail defined $avp(var) is_avp_set("$avp(var)") But, I see there is also in the 'pv' module now a function pv_unset(), i.e. pv_unset("$avp(var)"); pv_unset("$var(foo)"); I assume this actually deletes the variable itself from the namespace, instead of assigning it an undefined value. Are there pros and cons to using one or the other to mass-reset variables relevant to call processing at the beginning of route script? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

1 0

Re: [SR-Users] kamailio asterisk
by Slava Bendersky 23 Feb '15

23 Feb '15

Hello Everyone, Thank you for reply, On client I configured user @ domain.org and proxy point to kamailio Here 1 debug where on client after doamin.org port is left configured to 5061 http://fpaste.org/188145/44047614/ Second debug where port set to 0 and kamailio tries resolve and crashed http://fpaste.org/188148/24440702/ Here config file http://fpaste.org/188149/24440841/ Thank you, Slava. From: "Olle E. Johansson" <oej(a)edvina.net> To: "Daniel Constantin Mierla" <miconda(a)gmail.com>, "sr-users" <sr-users(a)lists.sip-router.org> Sent: Thursday, February 19, 2015 4:34:04 AM Subject: Re: [SR-Users] kamailio asterisk We also need to check the core file from the crash. /O On 19 Feb 2015, at 09:30, Daniel-Constantin Mierla < miconda(a)gmail.com > wrote: Hello, can you send the REGISTER request received by kamailio and your config to me? As you receive it over TLS, you can get the register by adding the next line in kamailio.cfg at the beginning of request_route: xlog("received request: [[$mb]]\n"); I will like to double check if the issue is still present. You should upgrade to 4.2.3, because it is the latest stable, you have 4.2.1 and there were many fixes meanwhile. If you preserve sips as uri schema, then you force tls further for forwarding. You should change that to sip:domain ... Cheers, Daniel On 18/02/15 00:37, Slava Bendersky wrote: BQ_BEGIN Hello Everyone, I have standard case where kamailio play role of proxy for asterisk servers. Kamailio configured use TLS transport on public side and on private side UDP 5060. When client (SIP soft phone) connect to TLS socket everything goes well until kamailio trying forward request. Kamailio tries DNS resolve tls transport srv records instead of udp then it just crashed when no tls configured on private side of kamailio. Do I need manually fix sips in URI ? Or some different miss configuration ? [root@canlvprx01 kamailio]# rpm -qa | grep kamail kamailio-carrierroute-4.2.1-4.2.fc21.x86_64 kamailio-mysql-4.2.1-4.2.fc21.x86_64 kamailio-outbound-4.2.1-4.2.fc21.x86_64 kamailio-4.2.1-4.2.fc21.x86_64 kamailio-tls-4.2.1-4.2.fc21.x86_64 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <REGISTER> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sips:domain.org> ---> Client come with TLS transport Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==12 && [ domain.org ] == [ 10.18.130.46 ] Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5060 (advertise 0) matches port 5060 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:583]: grep_sock_info(): grep_sock_info - checking if host==us: 13==11 && [ domain.org ] == [67.34.12.56] Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [socket_info.c:587]: grep_sock_info(): grep_sock_info - checking if port 5081 (advertise 0) matches port 5060 Feb 17 11:13:49 canlvprx 01 kernel: [4130713.518667] kamailio[22484]: segfault at 88 ip 0000000 0004bd30c sp 00007fffa2f73a20 error 4 in kamailio[400000+3b8000] Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [forward.c:448]: check_self(): check_self: host != me Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[SIPOUT] c=[/etc/kamailio/kamailio-asterisk.cfg] l=850 a=25 n=append_hf Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[SIPOUT] c=[/etc/kamailio/kamailio-asterisk.cfg] l=851 a=5 n=route Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=16 n=if Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=563 a=25 n=is_method Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=16 n=if Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=567 a=25 n=is_method Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=574 a=16 n=if Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) ERROR: *** cfgtrace:request_route=[RELAY] c=[/etc/kamailio/kamailio-asterisk.cfg] l=571 a=24 n=t_relay Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=1 , global msg id=1 , T on entrance=(nil) Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=48550, isACK=0 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7f598a9ced40, callback type 1, id 0 entered Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_hooks.c:380]: run_reqin_callbacks_internal(): DBG: trans=0x7f598a9ced40, callback type 1, id 0 entered Feb 17 11:13:49 canlvprx 01 kernel: kamailio[22484]: segfault at 88 ip 00000000004bd30c sp 00007 fffa2f73a20 error 4 in kamailio[400000+3b8000] Feb 17 11:13: 49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [md5utils.c:67]: MD5St ringArray(): DEBUG: MD5 calculated: 0475e0d0dd9778e889618cb724403b4d Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:566]: _dns_hash_find(): dns_hash_find(_sips._ tcp.networklab.ca (24), 33), h=646 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [resolve.c:967]: get_record(): get_record: skipping 1 NS (p=0xa1f556, end=0xa1f588) Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [resolve.c:983]: get_record(): get_record: parsing 2 ARs (p=0xa1f568, end=0xa1f588) Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:1772]: dns_get_related(): dns_get_related(0x7f598a9e89b0 (_sips._ tcp.domain.org , 33), 33, *0x7f5995bd55e0) (0) Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: adding _sips._ tcp.domain.org (24) 33 (flags=0) at 646 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:869]: dns_cache_add_unsafe(): dns_cache_add: adding camsgsrv02.domain.org (24) 1 (flags=0) at 967 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [dns_cache.c:566]: _dns_hash_find(): dns_hash_find( camsgsrv02.domain.org (24), 1), h=967 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [msg_translator.c:2871]: create_via_hf(): create_via_hf: id added: <;i=1>, rcv proto=3 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:1818]: tcp_send(): tcp_send: no open tcp connection found, opening new one Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 10.18.130.50 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 5061, type 3 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 3263:0:0, 2 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) WARNING: <core> [tcp_main.c:1221]: tcp_do_connect(): 10.18.130.50 :5061: could not find corresponding listening socket for 10.18.130.46 , using default... Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSc<default> Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tls [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: <core> [tcp_main.c:2697]: tcpconn_1st_send(): pending write on new connection 0x7f598a9d4678 (-1/129 bytes written) Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> [tcp_main.c:3565]: handle_ser_child(): handle_ser_child: read response= 7f598a9d4678, 5, fd 31 from 11 (22480) Feb 17 11:13:49 canlvprx01 kamailio: 15(22484) DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9daf00, 31, 2, 0x7f598a9d4678), fd_no=19 Feb 17 11:13:49 canlvprx01 kamailio: 11(22480) DEBUG: tm [t_funcs.c:394]: t_relay_to(): SER: new transaction fwd'ed Thank you Slava. _______________________________________________ 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 -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com _______________________________________________ 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 BQ_END _______________________________________________ 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

3 3

Dispatcher: Check uri string in Kamailio 3.3
by Jon Bonilla (Manwe) 22 Feb '15

22 Feb '15

Hi all I need to check a given uri against dispatcher destination entries. I see that it's possible in kamailio 4.2 using ds_is_from_list which allows "uri" parameter but it's not available in version 3.3. Moving to 4.x is not an option this time. Any hints about how to check this? Raw sql + string comparation or something more elegant out there? thanks, Jon

2 1

NAT SIPPING in a FreeBSD jail
by Euan Thoms 22 Feb '15

22 Feb '15

I've been running Kamailio 4.2.2/4.2.3 in a FreeBSD 10.1 jail for a few weeks, thanks to a recent port in the FreeBSD ports tree. However, it has been a bit unstable. It crashes randomly. It's hard to debug since it can go three days without crashing, and there is no obvious trigger. I'm also running 4.1.0 on FreeBSD 8.3, compiled from source manually. It is rock solid for a long time now. So, I have 2 theories: 1) My FreeBSd ports patch for ip_addr.h is wrong. I was having to define INADDR_LOOPBACK since compile would fail with 'undeclared identifier'. My patch was to define INADDR_LOOPBACK in ip_addr.h as a 'long' as such: #define INADDR_LOOPBACK (long) 0x7F000001 However, it appears this should have been: #define INADDR_LOOPBACK (unsigned long) 0x7F000001 The previous patch seemed to work, but could have caused the crashes I'm seeing. 2.) The NAT SIPPing feature defined with WITH_NATSIPPING is a new feature since 4.1.0. So my 4.1.0 installation does not use it. Now that I am using it on 4.2.3, I am getting this random crash. I suspect that the feature uses an ICMP ping at some stage. In FreeBSD jails, by default ping is not allowed (security feature). If you really need to ping then you need to explicitly allow raw sockets. So perhaps Kamailio doesn't know how to handle the "operation not permitted" and crashes. I am going to test without NAT SIPping and see if it crashes. Although it's hard to test, since I have no trigger and it can be days between crashes. ** My question is: how do I force the ping behaviour in NAT SIPping feature? I need a trigger to further debug. Output from /var/log/messages after crash: Feb 19 05:39:56 sip /usr/local/sbin/kamailio[52610]: CRITICAL: <core> [pass_fd.c:293]: receive_fd(): EOF on 24 Feb 19 05:39:56 sip /usr/local/sbin/kamailio[52578]: ALERT: <core> [main.c:784]: handle_sigs(): child process 52606 exited by a signal 6 Feb 19 05:39:56 sip /usr/local/sbin/kamailio[52578]: ALERT: <core> [main.c:787]: handle_sigs(): core was generated

2 1

Re-invites from carrier breaks the call
by Will Ferrer 21 Feb '15

21 Feb '15

Hi All We have any issue with re invites coming from the carrier. When a reinvite occurs, our softphone client gets the invite, sends a 100, and then sends 200 ok. However the 200 ok does not have the softphones ip in the record route. Since it's not in the record route the ack from the carrier never makes it's way all the back to the softphone. This causes the softphone to keep sending 200 oks since it never gets the ack. Eventually the softphone gets tired of sending 200 oks and sends a bye. Is there any way that Kamailio can help me correct for this, or do we need to have our clients use different softphones? If it has to be handled via softphones is there even a softphone that can account for this? Thanks for all your assistance in advance. All the best. Will Ferrer Switchsoft

10 29

xhttp module and IPv6
by Sergey Okhapkin 20 Feb '15

20 Feb '15

It looks like when http request comes from ipv6 address, the module inserts Via header without [] around the address: Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/parse_via.c:2193]: parse_via(): ERROR:parse_via: bad port Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/parse_via.c:2708]: parse_via(): ERROR: parse_via on: <SIP/2.0/TCP 2601:3:8840:A:172E:9CAD:6BB2:3F69:45306 Host: sip1.callwithus.com:5060 Connection: Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket Origin: http://www.callwithus.com Sec-WebSocket-Version: 13 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Sec-WebSocket-Key: nyAUyArASVRXTI+Nvx82/Q== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits Sec-WebSocket-Protocol: sip > Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/parse_via.c:2712]: parse_via(): ERROR: parse_via parse error, parsed so far:<SIP/2.0/TCP 2601:3> Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/msg_parser.c:125]: get_hdr_field(): ERROR: get_hdr_field: bad via Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: INFO: <core> [parser/msg_parser.c:338]: parse_headers(): ERROR: bad header field [Via: SIP/2.0/TCP 260] Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: <core> [parser/msg_parser.c:688]: parse_msg(): ERROR: parse_msg: message=<GET / HTTP/1.1 *Via: SIP/2.0/TCP 2601:3:8840:A:172E:9CAD:6BB2:3F69:45306* Host: sip1.callwithus.com:5060 Connection: Upgrade Pragma: no-cache Cache-Control: no-cache Upgrade: websocket Origin: http://www.callwithus.com Sec-WebSocket-Version: 13 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Sec-WebSocket-Key: nyAUyArASVRXTI+Nvx82/Q== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits Sec-WebSocket-Protocol: sip > Feb 20 14:26:17 east /usr/local/sbin/kamailio[30965]: ERROR: xhttp [xhttp_mod.c:264]: xhttp_process_request(): parse_msg failed

2 4

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