sr-dev June 2011

sr-dev@lists.kamailio.org

32 participants
167 discussions

git:master: db schema: updated column sizes of rls_watchers table

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 760ae2dcf7133d9211287485e03cd2b3d2432b0d URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=760ae2d… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Sat Jun 18 19:39:11 2011 +0200 db schema: updated column sizes of rls_watchers table - size for callid and contact columns set to &uri_len; - patch by Peter Dunkley --- lib/srdb1/schema/rls_watchers.xml | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/srdb1/schema/rls_watchers.xml b/lib/srdb1/schema/rls_watchers.xml index b982ffc..1faac29 100644 --- a/lib/srdb1/schema/rls_watchers.xml +++ b/lib/srdb1/schema/rls_watchers.xml @@ -97,7 +97,7 @@ <column id="callid"> <name>callid</name> <type>string</type> - <size>&domain_len;</size> + <size>&uri_len;</size> <description>Call ID</description> </column> @@ -118,7 +118,7 @@ <column> <name>contact</name> <type>string</type> - <size>&domain_len;</size> + <size>&uri_len;</size> <description>Contact</description> </column>

13 years, 6 months

git:master: tmx: documented t_reply_callid MI command

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: cd22e9d5a8e7dee60aabdfb6ca2d7e0ad19e8b10 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=cd22e9d… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Sat Jun 18 19:35:11 2011 +0200 tmx: documented t_reply_callid MI command --- modules_k/tmx/doc/tmx_admin.xml | 37 +++++++++++++++++++++++++++++++++++++ 1 files changed, 37 insertions(+), 0 deletions(-) diff --git a/modules_k/tmx/doc/tmx_admin.xml b/modules_k/tmx/doc/tmx_admin.xml index 185af4f..86a8946 100644 --- a/modules_k/tmx/doc/tmx_admin.xml +++ b/modules_k/tmx/doc/tmx_admin.xml @@ -377,6 +377,43 @@ route[abc] { </para></listitem> </itemizedlist> </section> + <section> + <title> + <function moreinfo="none">t_reply_callid</function> + </title> + <para> + Generates and sends a reply for an existing inbound SIP transaction. + </para> + <para>Parameters: </para> + <itemizedlist> + <listitem><para> + <emphasis>code</emphasis> - reply code + </para></listitem> + <listitem><para> + <emphasis>reason</emphasis> - reason phrase. + </para></listitem> + <listitem><para> + <emphasis>callid</emphasis> - SIP Call-ID header + </para></listitem> + <listitem><para> + <emphasis>cseq</emphasis> - SIP CSeq header + </para></listitem> + <listitem><para> + <emphasis>to_tag</emphasis> - To tag to be added to TO header + </para></listitem> + <listitem><para> + <emphasis>new_headers</emphasis> - extra headers to be + appended to the reply; use a dot (<quote>.</quote>) char + only if there are no headers; + </para></listitem> + <listitem><para> + <emphasis>body</emphasis> - (optional, may not be present) + reply body (if present, requires the + <quote>Content-Type</quote> and <quote>Content-length</quote> + headers) + </para></listitem> + </itemizedlist> + </section> </section>

13 years, 6 months

[tracker] Comment added: tcp_async=yes breaks connect_timeout (no effect) and TCP reject detection

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#136 - tcp_async=yes breaks connect_timeout (no effect) and TCP reject detection User who did this - Iñaki Baz Castillo (ibc) ---------- I assume what is happening: When tcp_async=no, the worker itself open the TCP connection (which of course is bad as it gets blocked for a while) and can detect TCP failures or timeouts. When tcp_async=yes, the worker just sends the message to some TCP process and inmediately returns so can handle other TCP requests. Then it just expects a SIP response associated to the client transaction from the transactiin layer, and it's not aware of TCP rejection or timeouts. If I'm not wrong in the above, could the tcp_async=yes mode be improved so some worker is notified about TCP rejection or timeout? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=136#comment228 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.

13 years, 6 months

[tracker] Task changed: tcp_async=yes breaks connect_timeout (no effect) and TCP reject detection

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_async=yes breaks connect_timeout (no effect) and TCP reject detection User who did this: Iñaki Baz Castillo (ibc) Summary: tcp_connect_timeout has no effect -> tcp_async=yes breaks connect_timeout (no effect) and TCP reject detection Task details edited: ------- When using tcp_async=yes, 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 an inmediate 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 --------- If I set tcp_async=no, then the above issues don't occur at all. 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.

13 years, 6 months

[tracker] Comment added: tcp_connect_timeout has no effect

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#136 - tcp_connect_timeout has no effect User who did this - Iñaki Baz Castillo (ibc) ---------- The issue just occurs in case of tcp_async=yes. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=136#comment227 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.

13 years, 6 months

Async TLS, is supported or not?

by Iñaki Baz Castillo

Hi, AFAIK sip-router already supports async TLS (maybe I'm wrong) but devel doc still says that it's not supported: http://sip-router.org/wiki/cookbooks/core-cookbook/devel#tcp_async ------------------------------------------------------ tcp_async Alias name: tcp_buf_write If enabled, all the tcp writes that would block / wait for connect to finish, will be queued and attempted latter (see also tcp_conn_wq_max and tcp_wq_max). Note: Using TLS over asynch TCP is not supported at the moment. If you use TLS you have to disable asynch TCP! ------------------------------------------------------- -- Iñaki Baz Castillo <ibc(a)aliax.net>

13 years, 6 months

200 OK 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

13 years, 6 months

[tracker] Task reopened: dialplan reload, out of memory

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been re-opened: FS#86 - dialplan reload, out of memory User who did this - Iñaki Baz Castillo (ibc) More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=86 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.

13 years, 6 months

OT: How to add code into the tracker (FLYSPRAY)?

by Iñaki Baz Castillo

Hi, does somebody know how to add code text when writing an issue in the tracker? http://sip-router.org/tracker I've tryed several ways as writing the code within <pre>_MY_CODE_</pre> or indenting with 2 and 4 spaces the text. It does not work. Thanks. -- Iñaki Baz Castillo <ibc(a)aliax.net>

13 years, 6 months

[tracker] Comment added: kamailio 3.1.3 Presence + XCAP problem, is it a bug?

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#133 - kamailio 3.1.3 Presence + XCAP problem, is it a bug? User who did this - laura testi (lau.testi) ---------- Hello, I would update the ticket with the last result of the discussion on sr-dev. The step 5): 5) the script kamailio.cfg calls pres_refresh_watchers a) PS sends NOTIFY to B(from A to B) with event type: presence and content type:application:pdif+xml (open, online, pdif entity:A,...) b) the PC client of B shows a popup by saying 5has authorized the B adds A as contact request seems to be a bug. But I think the step 4a) may be a bug: the subscription STATUS of B (watcher of A) to A should remain ACTIVE (1) instead of PENDING(2). this state is very strange and that causes the strange step 4b) after A having removed B. Because B does still subscribe A's presentity! And probably do this causes the incorrect behavior of step 5)... Should the presence server also remove the record of the subscription from A(watcher) to B(presentity) from both active_watchers and watchers tables instead of only from active_wtachers table? Because if A remove B (unsubscribe B), that mean A don't want to see the presentity of B. Or maybe it's correct put A's subscription status of B in TERMINATED(3) instead of removing the record (actually remains in ACTIVE(1)). About step in 5): When the presence server is doing pres_refresh_watchers in step 5), I think it checks the xcap table and see A is watcher of B (A is in B's presence_allow rule) and is in B's resource-list, and B is also active_watcher of A in the active_watchers table, A's subscription status of B is ACTIVE(1) in watchers table, B's subscription status of A is in Pending(2), it send a NOTIFY to B. That's really strange! Probably the step 4) also causes this strange behavior. I think that the right behaviour is: In step 1, in addition to remove the record of A's subscription of B from active_watchers table, the PS should also remove the record of A's subscription of B from the watchers table or put the STATUS=TERMINATED. That's because A is not interested the B's presentity anymore. In step 4, the PS should not change watchers table, because B's subscription of A is still active (should not becomes pending), and should not send the Pending notify too. Same for step 5. Could you please help us? Thanks in advance laura ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=133#comment225 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.

13 years, 6 months

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev June 2011