Hi,
I came across an interesting scenario yesterday related to early media:
A calls B and an early media session is setup. If A decides to "cancel" the
request with a BYE (instead of CANCEL), TM ignores this as a tear down of
the transaction. After a timeout, TM sends a "408 request canceled"
upstream and a CANCEL request downstream (to B). This happens even though
the BYE was correctly routed (loose routing) to B and the 200OK routed
back. Both UAs (A and B) behave as if the session has been
correctly terminated. Kamailio (TM) however seems to think otherwise???
According to the SIP RFC, a UE MAY send either a BYE OR CANCEL with Early
Media. (See section 15 of RFC3261 on page 88) - "The caller's UA MAY send a
BYE for either confirmed or early dialogs, and the callee's UA MAY send a
BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs."
Is this a known issue or should I look into it?
Cheers
Jason
Hi! I have 2 questions regarding the receive buffer:
1. Core parameter: tcp_clone_rcvbuf
> Control if the received buffer should be cloned from the TCP stream, needed by functions working inside the SIP message buffer (such as msg_apply_changes()).
>
> Default is 0 (don't clone), set it to 1 for cloning.
Does this mean that in the default setting msg_apply_changes() does not
work for messages received via TCP? If yes, we should add this
information to the documentation of msg_apply_changes().
2. in udp_server.c function udp_rcv_loop():
{
#ifdef DYN_BUF
char* buf;
#else
static char buf [BUF_SIZE+1];
#endif
...
#ifdef DYN_BUF
buf=pkg_malloc(BUF_SIZE+1);
if (buf==0){
LOG(L_ERR, "ERROR: udp_rcv_loop: could not
allocate receive"
" buffer\n");
goto error;
}
#endif
...
/* receive_msg must free buf too!*/
receive_msg(buf, len, &ri);
...
}
a) I think the /* receive_msg must free buf too!*/ comment is wrong as
receive_msg does not free the buffer. It does not even know if it is a
static buffer or allocated. -> remove the comment?
b) It seems that if DYN_BUF is defined, "buf" will not be freed at all.
regards
Klaus
Hi!
We're doing fine. Yesterday, I used Kamailio 4.0 in the SPIRAL multiparty test. Everything worked as expected.
Today I used Kamailio heavily during the RTCweb test. Kamailio was the core proxy for all tests done with developers from Firefox and Google Chrome in the room, as well as Iñaki and Peter available on the Jabber channel. I found one small bug that I believe I fixed, a missing Contact in a CANCEL that caused Kamailio segfault and core dump.
It took a while to configure everything properly and the examples in the READMEs where a bit confusing so I'll try to document and update later.
Thank you to Iñaki; jose and Peter for the assistance!
Greetings from North Carolina!
/O
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#271 - Max-forwards header missing
User who did this - Morten Tryfoss (mtryfoss)
----------
Hi,
It's the OPTIONS generated by Kamailio (dispatcher) for detecting if a destination is alive this is about. Sorry for not specifying this.
Microsoft got their own understanding of how things should be done. This is the behaviour in both Lync 2010 and 2013.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=271#comment771
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#271 - Max-forwards header missing
User who did this - Carsten Bock (carstenbock)
----------
Hi,
for me this looks more like a bug in Microsoft Lync rather than in Kamailio.
If you need to add this header in the reply to an OPTIONS request, did you consider using append_to_reply("Max-Forwards: 20\r\n") before replying instead?
Thanks,
Carsten
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=271#comment770
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Morten Tryfoss (mtryfoss)
Attached to Project - sip-router
Summary - Max-forwards header missing
Task Type - Bug Report
Category - tm
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - 3.3
Due in Version - Undecided
Due Date - Undecided
Details - Microsoft Lync requires a Max-forwards header when trying to ping the server with OPTIONS. It doesn't answer the request at all if it's not present.
Please see attached patch. This is working for me, but I don't know if it's the right way to do it.
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=271
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hi,
my kamailio v3.3.2 has problems with tm module if it cannot resolv
hostname. I had typoo in carrierroute, so it rewrited the host and
segfaulted. It is normal behaviour?
Feb 20 14:17:45 cr kamailio[17928]: WARNING: tm [t_lookup.c:1543]: WARNING:
script writer didn't release transaction
Feb 20 14:17:45 cr kernel: [87677.608617] kamailio[17928]: segfault at 13
ip a726e440 sp bfbf8aa0 error 6 in tm.so[a7236000+71000]
#0 atomic_dec_and_test_int (p_msg=0xa769bd68) at
../../parser/../mem/../atomic/atomic_x86.h:231
231 ATOMIC_FUNC_TEST(dec_and_test, "decl %0", int, int)
(gdb) back
#0 atomic_dec_and_test_int (p_msg=0xa769bd68) at
../../parser/../mem/../atomic/atomic_x86.h:231
#1 t_unref (p_msg=0xa769bd68) at t_lookup.c:1553
#2 0xa729bd6d in w_t_unref (foo=0xa769bd68, flags=2147483649, bar=0x0) at
tm.c:709
#3 0x08100908 in exec_post_script_cb (msg=0xa769bd68,
type=REQUEST_CB_TYPE) at script_cb.c:195
#4 0x080d9866 in receive_msg (
buf=0x8296840 "INVITE ...
#5 0x08163615 in udp_rcv_loop () at udp_server.c:544
#6 0x080a6793 in main_loop () at main.c:1633
#7 0x080a94ef in main (argc=5, argv=0xbf935d14) at main.c:2546
Mino
Hi!
The modules "statistics" and "counters" overlap quite a lot. THey use the same core functionality, but counters have RPC interface and statistics use the MI. Counters talk about "core counters" and statistics talk about "statistic variables" - but they are the same. If I add a core counter, it shows up as a "statistic variable" using the statistic module.
If this was pre-4.0 code freeze I would like to merge these modules into one.
Since we can't do that now, is it OK that I add cross-references in the README's and explain the situation and add references to the "other" module?
/O
Module: sip-router
Branch: master
Commit: 6369444761d44526ded2620e33438abb182d2bdc
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6369444…
Author: Olle E. Johansson <oej(a)edvina.net>
Committer: Olle E. Johansson <oej(a)edvina.net>
Date: Tue Feb 19 23:08:13 2013 +0100
outbound Fix core dump crash
When we got a CANCEL without Contact the parse_contact was sent a null
pointer. Changing the "or" to "and" fixed this and Kamailio no longer cores
on Cancel coming on over websockets from jssip.
Tested at SIPit 30. Core dumps and backtraces available.
Pdunkley - please check this patch
---
modules/outbound/ob_mod.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/modules/outbound/ob_mod.c b/modules/outbound/ob_mod.c
index caf10f4..f7fd63f 100644
--- a/modules/outbound/ob_mod.c
+++ b/modules/outbound/ob_mod.c
@@ -294,7 +294,7 @@ int use_outbound(struct sip_msg *msg)
/* Look for ;reg-id in REGISTER Contact-URIs and ;ob in any
Contact-URIs */
- if (msg->contact || parse_headers(msg, HDR_CONTACT_F, 0) != -1)
+ if (msg->contact && parse_headers(msg, HDR_CONTACT_F, 0) != -1)
{
if (parse_contact(msg->contact) < 0)
{