sr-users March 2010

sr-users@lists.kamailio.org

60 participants
118 discussions

Re: [Kamailio-Users] Is Timestamp supported in kamailio?
by Iñaki Baz Castillo 16 Mar '10

16 Mar '10

2010/3/16 mustafa rifaee <mustafa.rifaee(a)gmail.com>: > Hi Castillo, > I would like to asking you about the Time-stamp header in SIP messages, and > why this header does not supported in most open SIP servers, Is it > recommended or not? > Is there any open source support the time stamp header. > > Is this fact true ?? I think The problem is that both UAS and UAC must have > the same system time to generate a useful result. So therefore both or all > SIP devices (think about an intermediate proxy) must have NTP activated. > > Please Help me; I think I *already* helped you as you *already* asked me directly. Please, keep the threads in the maillist, nobody likes to give private free support. -- Iñaki Baz Castillo <ibc(a)aliax.net>

1 0

[Kamailio-Users] Is Timestamp supported in kamailio?
by mustafa rifaee 16 Mar '10

16 Mar '10

Hi all; I would like to ask you about the timestamp in kamailio, Is it supported or not ? if yes how i can enable it ? Please Help me; Thanks. Best Regards Mustafa Rifaee

3 3

[Kamailio-Users] [dialog module] dialog is not terminated when no ACK is received
by Iñaki Baz Castillo 16 Mar '10

16 Mar '10

Hi, using Kamailio 1.5.4. I use dlg_manage() for an INVITE. 200 Ok is replied by the callee but the UAC doesn't send the ACK (due to a crash). The dialog remains in Kamailio dialog memory/table in state 3 and would expire after default_timeout (which usually is 3600 seconds or more, unsuitable for this case). Yes, it could occur that the proxy is not doing loose_routing, but in that case it doesn't make sense to use dialog module, so shouldn't dialog module expire dialogs in state 3 after ~32 seconds? I'm using profiles_with_value to limit the number of calls per user, so this issue is a bit important, as a UAC not sending the ACK for a 200 means one less available channel for this user during dialog module default_timeout. -- Iñaki Baz Castillo <ibc(a)aliax.net>

3 8

[Kamailio-Users] maintenance this afternoon
by Daniel-Constantin Mierla 15 Mar '10

15 Mar '10

Hello, some small maintenance tasks will be performed afternoon today to the server hosting the mailing lists and kamailio.org site, if you notice some downtime, try again a bit later. Thanks, Daniel

2 2

[Kamailio-Users] kamailio crashes
by Panagiotis Skoulikaritis 14 Mar '10

14 Mar '10

Dear fellow kaimailio users We have a kamailio server which crashes. below is the backtrace from the core files any idea why the kamailio is crashing Regards Panagiotis core.29568 Mar 10 09:27 #0 fm_status (qm=0x73a040) at mem/f_malloc.c:609 #1 0x0000000000423d5c in sig_usr (signo=15) at main.c:563 #2 <signal handler called> #3 0x00000037e3cd4711 in __recvfrom_nocancel () from /lib64/libc.so.6 #4 0x00000000004790cc in udp_rcv_loop () at udp_server.c:408 #5 0x000000000042760e in main (argc=3, argv=0x7fff8bf6abc8) at main.c:774 core.19350 Mar 10 09:05 (gdb) backtrace #0 free_to (tb=0x775c00) at parser/parse_to.c:79 #1 0x000000000047fd42 in clean_hdr_field (hf=0x2ad2432de100) at parser/hf.c:187 #2 0x00002ad23fe3e525 in run_trans_callbacks (type=<value optimized out>, trans=<value optimized out>, req=0x2ad2432dcf58, rpl=0x772d28, code=<value optimized out>) at sip_msg.h:54 #3 0x00002ad23fe47b46 in t_reply_matching (p_msg=0x772d28, p_branch=<value optimized out>) at t_lookup.c:888 #4 0x00002ad23fe47fa2 in t_check (p_msg=0x772d28, param_branch=0x7ffff9c016bc) at t_lookup.c:964 #5 0x00002ad23fe58ac2 in reply_received (p_msg=0x73a040) at t_reply.c:1395 #6 0x000000000041eebc in forward_reply (msg=0x772d28) at forward.c:521 #7 0x0000000000445313 in receive_msg ( buf=0x718dc0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 77.247.97.11;branch=z9hG4bK45f7.70f91294.0;received=77.247.97.11\r\nV", len=920, rcv_info=0x7ffff9c017a0) at receive.c:212 #8 0x00000000004794ae in udp_rcv_loop () at udp_server.c:449 #9 0x000000000042760e in main (argc=3, argv=0x7ffff9c019b8) at main.c:774 (gdb) core.29567 Mar 10 09:27 gdb) backtrace #0 free_to (tb=0x776460) at parser/parse_to.c:79 #1 0x000000000047fd42 in clean_hdr_field (hf=0x2ad1805fa100) at parser/hf.c:187 #2 0x00002ad17d15a525 in run_trans_callbacks (type=<value optimized out>, trans=<value optimized out>, req=0x2ad1805f8f58, rpl=0x771920, code=<value optimized out>) at sip_msg.h:54 #3 0x00002ad17d163b46 in t_reply_matching (p_msg=0x771920, p_branch=<value optimized out>) at t_lookup.c:888 #4 0x00002ad17d163fa2 in t_check (p_msg=0x771920, param_branch=0x7fff8bf6a8cc) at t_lookup.c:964 #5 0x00002ad17d174ac2 in reply_received (p_msg=0x73a040) at t_reply.c:1395 #6 0x000000000041eebc in forward_reply (msg=0x771920) at forward.c:521 #7 0x0000000000445313 in receive_msg ( buf=0x718dc0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 77.247.97.11;branch=z9hG4bKddc9.fa58f7e.0;received=77.247.97.11\r\nVia: SIP/2.0/UDP 213.170.194.47:5060;branch=z9hG4bKb973f6a69c9bea270e9db867dd7cc90f\r\nRecord-Route: <si"..., len=919, rcv_info=0x7fff8bf6a9b0) at receive.c:212 #8 0x00000000004794ae in udp_rcv_loop () at udp_server.c:449 #9 0x000000000042760e in main (argc=3, argv=0x7fff8bf6abc8) at main.c:774 (gdb) core.5326 Mar 10 09:02 (gdb) backtrace #0 free_to (tb=0x772c48) at parser/parse_to.c:79 #1 0x000000000047fd42 in clean_hdr_field (hf=0x2b2578e22560) at parser/hf.c:187 #2 0x00002b257597b525 in run_trans_callbacks (type=<value optimized out>, trans=<value optimized out>, req=0x2b2578e213b8, rpl=0x771b50, code=<value optimized out>) at sip_msg.h:54 #3 0x00002b2575984b46 in t_reply_matching (p_msg=0x771b50, p_branch=<value optimized out>) at t_lookup.c:888 #4 0x00002b2575984fa2 in t_check (p_msg=0x771b50, param_branch=0x7fff7cdc63ac) at t_lookup.c:964 #5 0x00002b2575995ac2 in reply_received (p_msg=0x772c48) at t_reply.c:1395 #6 0x000000000041eebc in forward_reply (msg=0x771b50) at forward.c:521 #7 0x0000000000445313 in receive_msg ( buf=0x718dc0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 77.247.97.11;branch=z9hG4bKec2f.dc3d97a7.0;received=77.247.97.11\r\nVia: SIP/2.0/UDP 213.170.194.47:5060;branch=z9hG4bK47703457194f5be415efc231f6b3e923\r\nRecord-Route: <s"..., len=918, rcv_info=0x7fff7cdc6490) at receive.c:212 #8 0x00000000004794ae in udp_rcv_loop () at udp_server.c:449 #9 0x000000000042760e in main (argc=5, argv=0x7fff7cdc66a8) at main.c:774 (gdb) quit

3 5

[Kamailio-Users] Loadbalancer/outbound_proxy and ACK problem
by Pavel Miskov 13 Mar '10

13 Mar '10

Hello list, let me first show my scenario: UAC_A ---> LB ---> | | PROXY+REG #1 | or | PROXY+REG #2 UAC_B <--- LB <--- | LB cfg: modparam("path", "use_received", 1) loose_route(); #for REG+PROXY if(is_method("REGISTER")){ add_path_received(); ds_select_dst("1", "0"); fix_nated_register(); } else { record_route(); add_path(); ds_select_dst("1", "0"); fix_nated_register(); } PROXY+REG cfg: ------------- modparam("registrar", "use_path", 1) modparam("registrar", "path_mode", 0) modparam("registrar", "path_use_received", 1) INVITE if working fine until ACK. UAC_A sends ACK to LB "ACK sip:UAC_B@LB_IP:5678;" insted of "ACK sip:UAC_B@UAC_B_PUB_IP:". In "200 OK" which PROXY sends to LB Contact is rewritten with ip addres of LB "Contact: <sip:UAC_B@LB_IP:5678;" and this is why UAC_A sends wrong ACK. Obviously I miss something so if someone could point me where to look. Thanks Pavel U UAC_A_PUB_IP:31488 -> LB_IP:5678 INVITE sip:UAC_B@test.com SIP/2.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport..Max-Forwards: 70..Contact: <sip:UAC_A@UAC_A_PRIV_IP:31488>..To: "UAC_B"<sip:UAC_B@test.com>..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID:ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE.. # U LB_IP:5678 -> UAC_A_PUB_IP:31488 SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488;received=UACs_PUB_IP..To: "UAC_B"<sip:UAC_B@test.com>..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..Server: Kamailio (1.5.1-tls (x86_64/linux))..Content-Length: 0.... # U LB_IP:5678 -> REG_PROXY_IP:5166 INVITE sip:UAC_B@test.com SIP/2.0..Record-Route: <sip:LB_IP:5678;lr=on>..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Max-Forwards: 69..Contact: <sip:UAC_A@UAC_A_PUB_IP:31488>..To: "UAC_B"<sip:UAC_B@test.com>..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..Path: <sip:LB_IP:5678;lr>.... # U REG_PROXY_IP:5166 -> LB_IP:5678 SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..To: "UAC_B"<sip:UAC_B@test.com>..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..Server: Kamailio (1.5.1-tls (x86_64/linux))..Content-Length: 0.... # U REG_PROXY_IP:5166 -> LB_IP:5678 INVITE sip:UAC_B@UAC_B_PRIV_IP:31468;rinstance=ed47096f240b6b6d SIP/2.0..Record-Route: <sip:REG_PROXY_IP:5166;lr=on;nat=yes>..Record-Route: <sip:LB_IP:5678;lr=on>..Via: SIP/2.0/UDP REG_PROXY_IP:5166;branch=z9hG4bKa1b1.c7ca19a7.0..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Route: <sip:LB_IP:5678;lr;received="sip:UAC_B_PUB_IP:31468">..Max-Forwards: 68..Contact: <sip:UAC_A@UAC_A_PUB_IP:31488>..To: "UAC_B"<sip:UAC_B@test.com>..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..Path: <sip:LB_IP:5678;lr>.... # U LB_IP:5678 -> REG_PROXY_IP:5166 SIP/2.0 100 Giving a try..Via: SIP/2.0/UDP REG_PROXY_IP:5166;branch=z9hG4bKa1b1.c7ca19a7.0;rport=5166;received=REG_PROXY_IP..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..To: "UAC_B"<sip:UAC_B@test.com>..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..Server: Kamailio (1.5.1-tls (x86_64/linux))..Content-Length: 0.... # U LB_IP:5678 -> UAC_B_PUB_IP:31468 INVITE sip:UAC_B@UAC_B_PRIV_IP:31468;rinstance=ed47096f240b6b6d SIP/2.0..Record-Route: <sip:REG_PROXY_IP:5166;lr=on;nat=yes>..Record-Route: <sip:LB_IP:5678;lr=on>..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.56778065.0..Via: SIP/2.0/UDP REG_PROXY_IP:5166;rport=5166;received=REG_PROXY_IP;branch=z9hG4bKa1b1.c7ca19a7.0..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Max-Forwards: 67..Contact: <sip:UAC_A@UAC_A_PUB_IP:31488>..To: "UAC_B"<sip:UAC_B@test.com>..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..Path: <sip:LB_IP:5678;lr>.... # U UAC_B_PUB_IP:31468 -> LB_IP:5678 SIP/2.0 180 Ringing..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.56778065.0..Via: SIP/2.0/UDP REG_PROXY_IP:5166;rport =5166;received=REG_PROXY_IP;branch=z9hG4bKa1b1.c7ca19a7.0..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Record-Route: <sip:REG_PROXY_IP:5166;lr;nat=yes>..Record-Route: <sip:LB_IP:5678;lr=on>..Contact: <sip:UAC_B@UAC_B_PRIV_IP:31 468;rinstance=ed47096f240b6b6d>..To: "UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41.. Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..User-Agent: X-Lite release 1100l stamp 47546..Content-Length: 0.... # U LB_IP:5678 -> REG_PROXY_IP:5166 SIP/2.0 180 Ringing..Via: SIP/2.0/UDP REG_PROXY_IP:5166;rport=5166;received=REG_PROXY_IP;branch=z9hG4bKa1b1.c7ca19a7.0..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Record-Route: <sip:REG_PROXY_IP:5166;lr;nat=yes>..Record-Route: <sip: LB_IP:5678;lr=on>..Contact:<sip:UAC_B@UAC_B_PRIV_IP:31468;rinstance=ed47096f240b6b6d>..To: "UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From:"UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..User-Agent: X-Lite release 1100l stamp 47546..Content-Length: 0.... # U REG_PROXY_IP:5166 -> LB_IP:5678 SIP/2.0 180 Ringing..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Record-Route: <sip:REG_PROXY_IP:5166;lr;nat=yes>..Record-Route: <sip:LB_IP:5678;lr=on>..Contact: <sip:UAC_B@LB_IP:5678;rinstance=ed47096f240b6b6d>..To:"UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..User-Agent: X-Lite release 1100l stamp 47546..Content-Length: 0.... # U LB_IP:5678 -> UAC_A_PUB_IP:31488 SIP/2.0 180 Ringing..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Record-Route: <sip:REG_PROXY_IP:5166;lr;nat=yes>..Record-Route: <sip:LB_IP:5678;lr=on>..Contact: <sip:UAC_B@LB_IP:5678;rinstance=ed47096f240b6b6d>..To: "UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From:"UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE..User-Agent: X-Lite release 1100l stamp 47546..Content-Length: 0.... # U UAC_B_PUB_IP:31468 -> LB_IP:5678 SIP/2.0 200 OK..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.56778065.0..Via: SIP/2.0/UDP REG_PROXY_IP:5166;rport=5166;received=REG_PROXY_IP;branch=z9hG4bKa1b1.c7ca19a7.0..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Record-Route: <sip:REG_PROXY_IP:5166;lr;nat=yes>..Record-Route: <sip:LB_IP:5678;lr=on>..Contact: <sip:UAC_B@UAC_B_PRIV_IP:31468;r instance=ed47096f240b6b6d>..To: "UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE.. # U LB_IP:5678 -> REG_PROXY_IP:5166 SIP/2.0 200 OK..Via: SIP/2.0/UDP REG_PROXY_IP:5166;rport=5166;received=REG_PROXY_IP;branch=z9hG4bKa1b1.c7ca19a7.0..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Record-Route: <sip:REG_PROXY_IP:5166;lr;nat=yes>..Record-Route: <sip:LB_IP:5678;lr=on>..Contact:<sip:UAC_B@UAC_B_PRIV_IP:31468;rinstance=ed47096f240b6b6d>..To: "UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE.. # U REG_PROXY_IP:5166 -> LB_IP:5678 SIP/2.0 200 OK..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Record-Route: <sip:REG_PROXY_IP:5166;lr;nat=yes>..Record-Route: <sip:LB_IP:5678;lr=on>..Contact: <sip:UAC_B@LB_IP:5678;rinstance=ed47096f240b6b6d>..To: "UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From:"UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE.. # U LB_IP:5678 -> UAC_A_PUB_IP:31488 SIP/2.0 200 OK..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-d33a97176d49f84b-1---d8754z-;rport=31488..Record-Route: <sip:REG_PROXY_IP:5166;lr;nat=yes>..Record-Route: <sip:LB_IP:5678;lr=on>..Contact: <sip:UAC_B@LB_IP:5678;rinstance=ed47096f240b6b6d>..To: "UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From: "UAC_A"<sip:UAC_A@test.com >;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 INVITE.. # U UAC_A_PUB_IP:31488 -> LB_IP:5678 ACK sip:UAC_B@LB_IP:5678;rinstance=ed47096f240b6b6d SIP/2.0..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;branch=z9hG4bK-d8754z-0472a03b5d1aa106-1---d8754z-;rport..Max-Forwards: 70..Route: <sip:LB_IP:5678;lr>..Route: <sip:REG_PROXY_IP:5166;lr;nat=yes>..Contact: <sip:UAC_A@UAC_A_PRIV_IP:31488>..To: "UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From: "UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 ACK.. # U LB_IP:5678 -> REG_PROXY_IP:5166 ACK sip:REG_PROXY_IP:5166;lr;nat=yes SIP/2.0..Via: SIP/2.0/UDP LB_IP:5678;branch=z9hG4bKa1b1.46778065.2..Via: SIP/2.0/UDP LB_IP:5678;rport=5678;received=LB_IP;branch=z9hG4bKa1b1.46778065.2..Via: SIP/2.0/UDP UAC_A_PRIV_IP:31488;received=UACs_PUB_IP;branch=z9hG4bK-d8754z-0472a03b5d1aa106-1---d8754z-;rport=31488..Max-Forwards: 68..Contact: <sip:UAC_A@UAC_A_PUB_IP:31488>..To: "UAC_B"<sip:UAC_B@test.com>;tag=2e79423e..From:"UAC_A"<sip:UAC_A@test.com>;tag=8c3b5c41..Call-ID: ZTliZWQ4 YTM5MjVkYjUxYTk3MmUxZmVhOGY5MzlmM2Q...CSeq: 2 ACK..

3 5

[Kamailio-Users] What is the best module for routing INVITE based on DID in R-URI?
by Geoffrey Mina 13 Mar '10

13 Mar '10

Hello, I am putting up a Kamailio server which will do nothing but route INVITE requests from my upstream carrier to individual offices on my side. The office locations will NOT be registered SIP UAs, but other Kamailio proxy servers. What I want to have is a database of DIDs associated with a forwarding IP:Port and/or SRV records. 5555551212 ==> 1.2.3.4:5060 5555551213 ==> 1.2.3.5:5060 etc. Any guidance on what the best approach to achieving my goal would be much appreciated. Thanks, Geoff

4 12

[Kamailio-Users] need help to use the Kamailio register to remote sip proxy
by Cucku Cucku 12 Mar '10

12 Mar '10

Hi all i found the Kamailio supports register to remote sip proxy: http://www.mail-archive.com/users@lists.kamailio.org/msg07451.html it mentions to use : SQL to create the mysql table is in utils/kamctl/mysql/uac-create.sql but i didnt find the sql script My sip proxy version : sercmd> core.version Server: kamailio (3.0.1 (i386/linux)) 679736 my util folder : [root@localhost kamailio-3.0.1]# ls utils/kamctl/mysql/ acc-create.sql domainpolicy-create.sql purple-create.sql alias_db-create.sql drouting-create.sql registrar-create.sql auth_db-create.sql group-create.sql rls-create.sql avpops-create.sql htable-create.sql siptrace-create.sql carrierroute-create.sql imc-create.sql speeddial-create.sql cpl-create.sql lcr-create.sql standard-create.sql dialog-create.sql msilo-create.sql uri_db-create.sql dialplan-create.sql pdt-create.sql userblacklist-create.sql dispatcher-create.sql permissions-create.sql usrloc-create.sql domain-create.sql presence-create.sql please help Thank you Muốn đổi mới cách xưng hô với ông xã/ bà xã của bạn? Xem có bao nhiêu cách xưng hô giữa vợ và chồng nhé! http://vn.answers.yahoo.com

3 3

[Kamailio-Users] Stateless failover
by Santiago Soares 12 Mar '10

12 Mar '10

We're using Kamailio as a stateless load balancer, and would like to add failover support. Is it possible to have failover support in stateless mode? What i want is that when a server doesn't answer to a request, Kamailio set its state to probing, and start to ping it until it answer, then setting its state to active again. And that only active servers are selected by ds_select_dst(). Is it possible? How can I do this? Thank you. Santiago

4 4

[Kamailio-Users] Advanced Call Scenario / One Way Audio
by Brandon Armstead 12 Mar '10

12 Mar '10

Hello, As always, thank you for all / any help and input you may provide in advance. Call Scenario: UA1 -> REGISTRAR-01 -> Kamailio-01 -> Asterisk (New Call-ID + Asterisk in Media Path) -> Kamailio-01 -> REGISTRAR-02 -> UA2 UA1 is behind NAT UA2 is behind NAT The purpose of this is when using a shared "USRLOC" database to simulate calls from "PSTN" to generate both legs of the call, i.e. incoming and outgoing, and also allow for easier / cleaner "traversal" This aids from scenario's happening where UA1 calls UA2 (while UA1 exists on P1 and UA2 exists on P2) this prevents P1 -> UA2, and forces P2 -> UA2 We determine that this is a call from P1 to P2 (internal call) and thus create this "bridge / interconnection" We are running into a problem it seems with one way audio, i.e. the CALLEE can hear the CALLER, however the CALLER CAN NOT hear the CALLEE. REGISTRAR-01 AND REGISTRAR-02 are both "proxying" RTP As well as the initial Asterisk in "the middle" SDP. Let me know if this makes sense and if you guys have any further thoughts on what may possibily be going wrong. Perhaps there are better ways to go about this, let me know if I am way off course, thank you! Sincerely, Brandon Armstead

3 2

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

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 March 2010