sr-dev June 2011

sr-dev@lists.kamailio.org

32 participants
167 discussions

siptrace failure when used from mi_datagram

by Helmut Grohne

Hi, I am observing the following sequence in kamailio 3.1.2 log files: | ERROR: <core> [db.c:421]: invalid parameter value | DEBUG: siptrace [siptrace.c:530]: storing info... | ERROR: <core> [db_query.c:152]: invalid parameter value | ERROR: siptrace [siptrace.c:532]: error storing trace It happens after executing t_uac_dlg via mi_datagram. The interesting part of the configuration file is: | event_route[tm:local-request]{ | xlog("L_NOTICE", "event_route tm:local-request ..."); | sip_trace(); | } Both use_table and insert first check for NULL values among their parameters. The only common parameter to both functions is the db connection. I verified that it is actually NULL as it arrives in db_use_table (lib/srdb1/db.c). So why should the db_con module level variable (modules_k/siptrace/siptrace.c) be uninitialized? This question is answered in the child_init function of the same file: The db_con is not initialized if the passed rank is one out of PROC_INIT, PROC_MAIN and PROC_TCP_MAIN. Might be a good point to look at mi_datagram's child_init (modules_k/mi_datagram/mi_datagram.c). Well yeah. It forks of a process when rank is PROC_MAIN. And that process has no db_con in the siptrace module. So logging from mi_datagram is doomed to fail. An obvious idea is to open up a database connection for PROC_MAIN, too. The db_con would then (with luck) be inherited to the mi_datagram module and in fact this happens on my instance. The sharing of a db_con with multiple processes is obviously not that a brilliant idea. Nasty race conditions can occur later. So how to solve this issue instead of working around the symptoms? Helmut

12 years, 11 months

[tracker] Task changed: tcp_connect_timeout has no effect

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#136 - tcp_connect_timeout has no effect User who did this: Iñaki Baz Castillo (ibc) Task details edited: ------- It seems that tcp_connect_timeout has no effect at all. I set it to 3 seconds and try sending a request with RURI "sip:lalalala@91.121.79.216:7777;transport=tcp". The server 91.121.79.216 refuses the TCP connection (REJECT action in iptables rather than DROP), try yourself: <pre><code> ~# telnet 91.121.79.216 7777 Trying 91.121.79.216... telnet: Unable to connect to remote host: Connection refused </code></pre> However when my Kamailio tries to open a TCP connection with such destination, it produces a local 408 after 30 seconds (fr_timer = 30000)! Since Kamailio should detect that the TCP connection is rejected, I expect that it should generate a local 503 for the client transaction as RFC 3261 states. I attach a file kamailio-tcp-reject.log which shows the issue. It clearly shows that tcp connection attemp fails inmediately (due to TCP reject) but it does not terminate the client transaction and instead it takes 30 seconds until it generates local 408: <pre><code> Jun 15 12:40:51 kamailio[7275]: ERROR: <core> [tcp_main.c:4137]: connect 91.121.79.216:7777 failed Jun 15 12:41:21 kamailio[7270]: DEBUG: tm [t_reply.c:1132]: ->>>>>>>>> T_code=100, new_code=408 </code></pre> I've also tested sending a TCP INVITE to a host which is not reachable (1.2.3.4) so TCP timeouts occurs (after 5 seconds rather than 3 however...) but as in the other case, such TCP timeout does not terminate the client transaction and instead local 408 is generated after 30 seconds (I attach kamailio-tcp-timeout.log): <pre><code> Jun 15 12:42:23 kamailio[7338]: DEBUG: <core> [io_wait.h:390]: DBG: io_watch_add(0x890f60, 18, 2, 0x7fae6c97d278), fd_no=10 Jun 15 12:42:28 kamailio[7338]: DEBUG: <core> [tcp_main.c:4304]: tcp_main: entering timer for 0x7fae6c97d278 (ticks=1376168512, timeout=1376170384 (117 s), wr_timeout=1376168512 (0 s)), write queue: 940 bytes Jun 15 12:42:28 kamailio[7338]: ERROR: <core> [tcp_main.c:4322]: connect 1.2.3.4:5060 failed (timeout) Jun 15 12:42:28 kamailio[7338]: DEBUG: <core> [tcp_main.c:4346]: tcp_main: timeout for 0x7fae6c97d278 Jun 15 12:42:28 kamailio[7338]: DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (0x890f60, 18, -1, 0x10) fd_no=11 called Jun 15 12:42:53 kamailio[7333]: DEBUG: tm [t_reply.c:1132]: ->>>>>>>>> T_code=100, new_code=408 </code></pre> Kamailio info: version: kamailio 3.2.0-dev5 (x86_64/linux) 552425 flags: STATS: Off, USE_IPV6, 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: 552425 compiled on 09:46:21 Jun 15 2011 with gcc 4.5.2 ------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=136 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.

12 years, 11 months

[tracker] Task closed: Segfault parsing STUN body

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#129 - Segfault parsing STUN body User who did this - Daniel-Constantin Mierla (miconda) Reason for closing: Fixed Additional comments about closing: I understood was fixed by Andrei's patches. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=129 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.

12 years, 11 months

[tracker] Task changed: tcp_connect_timeout has no effect

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#136 - tcp_connect_timeout has no effect User who did this: Iñaki Baz Castillo (ibc) Task details edited: ------- It seems that tcp_connect_timeout has no effect at all. I set it to 3 seconds and try sending a request with RURI "sip:lalalala@91.121.79.216:7777;transport=tcp". The server 91.121.79.216 refuses the TCP connection (REJECT action in iptables rather than DROP), try yourself: <code> ~# telnet 91.121.79.216 7777 Trying 91.121.79.216... telnet: Unable to connect to remote host: Connection refused </code> However when my Kamailio tries to open a TCP connection with such destination, it produces a local 408 after 30 seconds (fr_timer = 30000)! Since Kamailio should detect that the TCP connection is rejected, I expect that it should generate a local 503 for the client transaction as RFC 3261 states. I attach a file kamailio-tcp-reject.log which shows the issue. It clearly shows that tcp connection attemp fails inmediately (due to TCP reject) but it does not terminate the client transaction and instead it takes 30 seconds until it generates local 408: <code> Jun 15 12:40:51 kamailio[7275]: ERROR: <core> [tcp_main.c:4137]: connect 91.121.79.216:7777 failed Jun 15 12:41:21 kamailio[7270]: DEBUG: tm [t_reply.c:1132]: ->>>>>>>>> T_code=100, new_code=408 </code> I've also tested sending a TCP INVITE to a host which is not reachable (1.2.3.4) so TCP timeouts occurs (after 5 seconds rather than 3 however...) but as in the other case, such TCP timeout does not terminate the client transaction and instead local 408 is generated after 30 seconds (I attach kamailio-tcp-timeout.log): <code> Jun 15 12:42:23 kamailio[7338]: DEBUG: <core> [io_wait.h:390]: DBG: io_watch_add(0x890f60, 18, 2, 0x7fae6c97d278), fd_no=10 Jun 15 12:42:28 kamailio[7338]: DEBUG: <core> [tcp_main.c:4304]: tcp_main: entering timer for 0x7fae6c97d278 (ticks=1376168512, timeout=1376170384 (117 s), wr_timeout=1376168512 (0 s)), write queue: 940 bytes Jun 15 12:42:28 kamailio[7338]: ERROR: <core> [tcp_main.c:4322]: connect 1.2.3.4:5060 failed (timeout) Jun 15 12:42:28 kamailio[7338]: DEBUG: <core> [tcp_main.c:4346]: tcp_main: timeout for 0x7fae6c97d278 Jun 15 12:42:28 kamailio[7338]: DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (0x890f60, 18, -1, 0x10) fd_no=11 called Jun 15 12:42:53 kamailio[7333]: DEBUG: tm [t_reply.c:1132]: ->>>>>>>>> T_code=100, new_code=408 </code> Kamailio info: version: kamailio 3.2.0-dev5 (x86_64/linux) 552425 flags: STATS: Off, USE_IPV6, 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: 552425 compiled on 09:46:21 Jun 15 2011 with gcc 4.5.2 ------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=136 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.

12 years, 11 months

[PATCH] t_reply_callid over MI?

by Helmut Grohne

Hi, I was wondering why t_reply_callid is not exported to MI. Since I needed it, I wrote a patch to make it available via MI. It might be interesting to others as well, so here goes the patch. Helmut

12 years, 11 months

git:master: - Merge of the implementation of the RFC3680 (reginfo-package) into master

by Carsten Bock

Module: sip-router Branch: master Commit: 552425a497e4d6cba9ba2dd74267e14b220ff58d URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=552425a… Author: Carsten Bock <carsten(a)bock.info> Committer: Carsten Bock <carsten(a)bock.info> Date: Mon Jun 13 15:04:27 2011 +0200 - Merge of the implementation of the RFC3680 (reginfo-package) into master --- modules_k/presence_reginfo/Makefile | 33 ++ modules_k/presence_reginfo/add_events.c | 52 +++ modules_k/presence_reginfo/add_events.h | 30 ++ modules_k/presence_reginfo/doc/Makefile | 4 + .../presence_reginfo/doc/presence_reginfo.xml | 39 ++ .../doc/presence_reginfo_admin.xml | 74 ++++ modules_k/presence_reginfo/presence_reginfo.c | 94 +++++ modules_k/presence_reginfo/presence_reginfo.h | 29 ++ modules_k/pua/add_events.c | 72 ++++ modules_k/pua/add_events.h | 1 + modules_k/pua/doc/pua_admin.xml | 26 ++ modules_k/pua/hash.h | 7 + modules_k/pua/pua.c | 2 + modules_k/pua/pua.h | 2 + modules_k/pua_reginfo/Makefile | 19 + modules_k/pua_reginfo/doc/Makefile | 4 + modules_k/pua_reginfo/doc/pua_reginfo.xml | 39 ++ modules_k/pua_reginfo/doc/pua_reginfo_admin.xml | 253 +++++++++++++ modules_k/pua_reginfo/notify.c | 390 ++++++++++++++++++++ modules_k/pua_reginfo/notify.h | 31 ++ modules_k/pua_reginfo/pua_reginfo.c | 181 +++++++++ modules_k/pua_reginfo/pua_reginfo.h | 37 ++ modules_k/pua_reginfo/subscribe.c | 102 +++++ modules_k/pua_reginfo/subscribe.h | 33 ++ modules_k/pua_reginfo/usrloc_cb.c | 288 +++++++++++++++ modules_k/pua_reginfo/usrloc_cb.h | 26 ++ 26 files changed, 1868 insertions(+), 0 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=552…

12 years, 11 months

[tracker] Task changed: tcp_connect_timeout has no effect

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#136 - tcp_connect_timeout has no effect User who did this: Iñaki Baz Castillo (ibc) Task details edited: ------- It seems that tcp_connect_timeout has no effect at all. I set it to 3 seconds and try sending a request with RURI "sip:lalalala@91.121.79.216:7777;transport=tcp". The server 91.121.79.216 refuses the TCP connection (REJECT action in iptables rather than DROP), try yourself: --------------- ~# telnet 91.121.79.216 7777 Trying 91.121.79.216... telnet: Unable to connect to remote host: Connection refused --------------- However when my Kamailio tries to open a TCP connection with such destination, it produces a local 408 after 30 seconds (fr_timer = 30000)! Since Kamailio should detect that the TCP connection is rejected, I expect that it should generate a local 503 for the client transaction as RFC 3261 states. I attach a file kamailio-tcp-reject.log which shows the issue. It clearly shows that tcp connection attemp fails inmediately (due to TCP reject) but it does not terminate the client transaction and instead it takes 30 seconds until it generates local 408: ----------------- Jun 15 12:40:51 kamailio[7275]: ERROR: <core> [tcp_main.c:4137]: connect 91.121.79.216:7777 failed Jun 15 12:41:21 kamailio[7270]: DEBUG: tm [t_reply.c:1132]: ->>>>>>>>> T_code=100, new_code=408 ----------------- I've also tested sending a TCP INVITE to a host which is not reachable (1.2.3.4) so TCP timeouts occurs (after 5 seconds rather than 3 however...) but as in the other case, such TCP timeout does not terminate the client transaction and instead local 408 is generated after 30 seconds (I attach kamailio-tcp-timeout.log): ------------------ Jun 15 12:42:23 kamailio[7338]: DEBUG: <core> [io_wait.h:390]: DBG: io_watch_add(0x890f60, 18, 2, 0x7fae6c97d278), fd_no=10 Jun 15 12:42:28 kamailio[7338]: DEBUG: <core> [tcp_main.c:4304]: tcp_main: entering timer for 0x7fae6c97d278 (ticks=1376168512, timeout=1376170384 (117 s), wr_timeout=1376168512 (0 s)), write queue: 940 bytes Jun 15 12:42:28 kamailio[7338]: ERROR: <core> [tcp_main.c:4322]: connect 1.2.3.4:5060 failed (timeout) Jun 15 12:42:28 kamailio[7338]: DEBUG: <core> [tcp_main.c:4346]: tcp_main: timeout for 0x7fae6c97d278 Jun 15 12:42:28 kamailio[7338]: DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (0x890f60, 18, -1, 0x10) fd_no=11 called Jun 15 12:42:53 kamailio[7333]: DEBUG: tm [t_reply.c:1132]: ->>>>>>>>> T_code=100, new_code=408 ------------------ Kamailio info: version: kamailio 3.2.0-dev5 (x86_64/linux) 552425 flags: STATS: Off, USE_IPV6, 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: 552425 compiled on 09:46:21 Jun 15 2011 with gcc 4.5.2 ------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=136 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.

12 years, 11 months

[tracker] Task opened: tcp_connect_timeout has no effect (Attachment added)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Iñaki Baz Castillo (ibc) Attached to Project - sip-router Summary - tcp_connect_timeout has no effect Task Type - Bug Report Category - tcp Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - Linux Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - It seems that tcp_connect_timeout has no effect at all. I set it to 3 seconds and try sending a request with RURI "sip:lalalala@91.121.79.216:7777;transport=tcp". The server 91.121.79.216 refuses the TCP connection (REJECT action in iptables rather than DROP), try yourself: ~# telnet 91.121.79.216 7777 Trying 91.121.79.216... telnet: Unable to connect to remote host: Connection refused However when my Kamailio tries to open a TCP connection with such destination, it produces a local 408 after 30 seconds (fr_timer = 30000)! Since Kamailio should detect that the TCP connection is rejected, I expect that it should generate a local 503 for the client transaction as RFC 3261 states, am I wrong? PS: I attach the log of a call to "sip:lalalala@91.121.79.216:7777;transport=tcp". Kamailio info: version: kamailio 3.2.0-dev5 (x86_64/linux) 552425 flags: STATS: Off, USE_IPV6, 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: 552425 compiled on 09:46:21 Jun 15 2011 with gcc 4.5.2 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=136 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.

12 years, 11 months

[tracker] Assignee added: tcp_connect_timeout has no effect

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#136 - tcp_connect_timeout has no effect User who did this - Iñaki Baz Castillo (ibc) http://sip-router.org/tracker/index.php?do=details&task_id=136 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.

12 years, 11 months

Fwd: 200OK Retransmission Error

by Jijo

Hi All, In an INVITE transaction, no ACK from A party and B party continue retransmission of 200 OK. I have observed that kamailio is not passing the retransmitted 200 OK message from B party to the Application(script) after 3 seconds. Instead kamailio directly sending to A party without passing to the script. I see in the logs that kamailio is cleaning up the transaction after 3 seconds..look for the string "DEBUG: t_lookup_request: no transaction found" before this log it is cleaning up the timer in the log "DEBUG: cleanup_uac_timers: RETR/FR timers reset" What does it mean by that?? How can we make the kamailio to pass the response to the application? Please let me know your comments.. Here is the flow. I cannot send the complete logs which is quite big. so i grep'd using the stirng "tcp_read_req: content-length|get_hdr_field|t_reply_matching|cleanup_uac_timers|RR11" from the complete log.. A kamailo B ----INVITE-->- --------------------INVITE 180 Ringing--<---------------180 Ringing 200 OK-----------<---------------200 OK 0 200 OK-----------<---------------200 OK 500ms 200 OK-----------<---------------200 OK 1s 200 OK-----------<---------------200 OK 2s < From here it is not passing to the application- script> 200 OK-----------<---------------200 OK 4s 200 OK-----------<---------------200 OK 4s 28 102:2011-06-13T19:47:37+01:00 [debug] sipserver: [26177] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [50]; uri=[ sip:5616990102@192.168.243.151:5060] 36 95:2011-06-13T19:47:37+01:00 [debug] sipserver: [26177] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 267 86:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 0 282 102:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 284 95:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 285 89:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 286 90:2011-06-13T19:47:38+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 292 96:2011-06-13T19:47:38+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:180 Reason=Ringing CT=5616990102 <sip: 5616990102@192.168.243.161:5060;transport=tcp> 331 86:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 346 102:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 348 95:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 349 89:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 350 90:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 356 96:2011-06-13T19:47:39+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102 @192.168.243.161:5060;transport=tcp> 398 89:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: tm [t_reply.c:1467]: DEBUG: cleanup_uac_timers: RETR/FR timers reset 406 86:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 421 102:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 423 95:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 424 89:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 425 90:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 431 96:2011-06-13T19:47:40+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102 @192.168.243.161:5060;transport=tcp> 481 86:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 496 102:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 498 95:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 499 89:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 500 90:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 506 96:2011-06-13T19:47:41+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102 @192.168.243.161:5060;transport=tcp> 556 86:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 571 102:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 573 95:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 574 89:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 575 90:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 581 96:2011-06-13T19:47:43+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102 @192.168.243.161:5060;transport=tcp> 631 86:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 646 102:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 648 95:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 649 89:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 650 90:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 651 90:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 693 86:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 708 102:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 710 95:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 711 89:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 712 90:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 713 90:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 755 86:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 770 102:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 772 95:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 773 89:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 774 90:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 775 90:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 817 86:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 832 102:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 834 95:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 835 89:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 836 90:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 837 90:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 879 86:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 894 102:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 896 95:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 897 89:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 898 90:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 899 90:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 941 86:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 956 102:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 958 95:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 959 89:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 960 90:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 961 90:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 1003 86:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 1018 102:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 1020 95:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 1021 89:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 1022 90:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 1023 90:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction

12 years, 11 months

← Newer
1
...
7
8
9
10
11
12
13
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2011