Hi Carsten,
After more testing, I just realized that the notification works only if I
use "-f" parameter in RTPPROXY. If I omit this parameter (to run in
background mode), the session timeout but there's no notification sent
(BYE). Why's that?
Thanks,
Alexandre.
-----Mensagem original-----
De: Alexandre Abreu [mailto:alexandre.abreu@redt.com.br]
Enviada em: quarta-feira, 16 de março de 2011 14:41
Para: 'Carsten Bock'
Cc: 'sr-users(a)lists.sip-router.org'
Assunto: RES: RTPPROXY timeout patch.…
[View More]
Carsten,
Here it goes:
[root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l 192.168.200.90
-s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1:7723
INFO:main: rtpproxy started, pid 22495
rtpproxy: >>> Running Timeout-Process
DBUG:handle_command: received command "22428_8 Uc0,8,101 080b5d23d1603667
192.168.200.114 6380 0073852a;1"
INFO:handle_command: new session 080b5d23d1603667, tag 0073852a;1 requested,
type strong
INFO:handle_command: new session on a port 48662 created, tag 0073852a;1
INFO:handle_command: pre-filling caller's address with 192.168.200.114:6380
DBUG:doreply: sending reply "22428_8 48662 192.168.200.90"
DBUG:handle_command: received command "22436_8 Lc0,8,101 080b5d23d1603667
192.168.200.149 7614 0073852a;1 c758967a;1
xmlrpc:http://127.0.0.1:8000/RPC2"
INFO:handle_command: lookup on ports 48662/58604, session timer restarted
INFO:handle_command: setting custom timeout handler
(xmlrpc:http://127.0.0.1:8000/RPC2)
INFO:handle_command: pre-filling callee's address with 192.168.200.149:7614
DBUG:doreply: sending reply "22436_8 58604 192.168.200.90"
INFO:process_rtp: session timeout
INFO:remove_session: RTP stats: 982 in from callee, 4 in from caller, 986
relayed, 0 dropped
INFO:remove_session: RTCP stats: 5 in from callee, 1 in from caller, 6
relayed, 0 dropped
INFO:remove_session: session on ports 48662/58604 is cleaned up
ERR:do_timeout_notification: Timeout socket is: èîÈÄÐÊ@ÍÈÄÈÄ`ê
DBUG:reconnect_timeout_handler: reconnecting timeout socket
ERR:reconnect_timeout_handler: can't create timeout socket: Address family
not supported by protocol
ERR:do_timeout_notification: unable to send timeout notification
Very weird chars in the debug of what Timeout socket is...
But the custom timeout handler are being printed correctly from the config
file.
INFO:handle_command: setting custom timeout handler
(xmlrpc:http://127.0.0.1:8000/RPC2)
Here I am running CentOS 5.2 32-bit.
Thanks,
Alexandre
-----Mensagem original-----
De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em nome
de Carsten Bock Enviada em: quarta-feira, 16 de março de 2011 14:18
Para: Alexandre Abreu
Cc: sr-users(a)lists.sip-router.org
Assunto: Re: RTPPROXY timeout patch.
Hi Alexandre,
My version of RTP-Proxy is following:
bock@bock-tde:~/ims/rtpproxy$ ./rtpproxy -v Basic version: 20040107
Extension 20050322: Support for multiple RTP streams and MOH Extension
20060704: Support for extra parameter in the V command Extension 20071116:
Support for RTP re-packetization Extension 20071218: Support for forking
(copying) RTP stream Extension 20080403: Support for RTP statistics querying
Extension 20081102: Support for setting codecs in the update/lookup command
Extension 20081224: Support for session timeout notifications Extension
20090810: Support for automatic bridging Extension 20100819: Support for
timeout notifications using XML-RPC towards Kamailio/sip-router.org
Please find attached a modified rtpp_notify.c file. I have just added some
tiny debug output in order to see some points.
Now you should see the following Debug-Outputs:
rtpproxy: >>> Running Timeout-Process
Then the notifier process is running. That would be good. If not, that's the
reason why it is not working. When the request comes in, you should see the
following:
INFO:handle_command: setting custom timeout handler
(xmlrpc:http://localhost:8000/RPC2)
Then the Timeout-Socket was properly set, that would be good as well.
Now the timeout:
INFO:process_rtp: session timeout
[...]
ERR:do_timeout_notification: Timeout socket is:
xmlrpc:http://localhost:8000/RPC2
That would be great, because then the Timeout towards the Kamailio should be
triggerd.
If these parts are ok, then there must be some issue either in the XML-RPC
client library or in the communication between the RTP-Proxy and Kamailio. I
hope you did a trace on the XML-RPC Port both on the RTPproxy and on the
Kamailio? What distro are you using? My tests were only on Ubuntu and
Debian, which are quite similar.
Hope we find this issue,
Kind regards,
Carsten
P.S.: I think i removed that check for the port for testing, that's why my
version accepted the socket without port... (now i'm using "-n
tcp:127.0.0.1:9999")
2011/3/16 Alexandre Abreu <alexandre.abreu(a)redt.com.br>:
> Carsten,
>
> Indeed. Very strange.
>
> Are we running the same RTPPROXY version? How can you start using '-n
> tcp:127.0.0.1' without specifying a port?
>
> [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l
> 192.168.200.90 -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1
> rtpproxy: can't parse host:port in TCP address
> rtpproxy: can't start notification thread
>
> [root@devel rtpproxy-carsten]# ./rtpproxy -T 10 -f -F -i -l
> 192.168.200.90 -s udp:*:7722 -d DBUG ERR INFO -n tcp:127.0.0.1:7723
> INFO:main: rtpproxy started, pid 21169
>
> DBUG:handle_command: received command "17828_9 Uc0,8,101
> 4b10ce04de4f8818
> 192.168.200.114 6380 9c4b6265;1"
> INFO:handle_command: new session 4b10ce04de4f8818, tag 9c4b6265;1
> requested, type strong
> INFO:handle_command: new session on a port 43750 created, tag
> 9c4b6265;1
> INFO:handle_command: pre-filling caller's address with
> 192.168.200.114:6380
> DBUG:doreply: sending reply "17828_9 43750 192.168.200.90 "
> DBUG:handle_command: received command "17847_9 Lc0,8,101
> 4b10ce04de4f8818
> 192.168.200.149 7386 9c4b6265;1 dd69ab1d;1
> xmlrpc:http://localhost:8000/RPC2"
> INFO:handle_command: lookup on ports 43750/55796, session timer
> restarted
> INFO:handle_command: setting custom timeout handler
> (xmlrpc:http://localhost:8000/RPC2)
> INFO:handle_command: pre-filling callee's address with
> 192.168.200.149:7386
> DBUG:doreply: sending reply "17847_9 55796 192.168.200.90 "
> INFO:process_rtp: session timeout
> INFO:remove_session: RTP stats: 548 in from callee, 5 in from caller,
> 553 relayed, 0 dropped
> INFO:remove_session: RTCP stats: 3 in from callee, 1 in from caller, 4
> relayed, 0 dropped
> INFO:remove_session: session on ports 43750/55796 is cleaned up
> DBUG:reconnect_timeout_handler: reconnecting timeout socket
> ERR:reconnect_timeout_handler: can't create timeout socket: Address
> family not supported by protocol
> ERR:do_timeout_notification: unable to send timeout notification
>
> Above the error message.
>
> [root@devel ~]# md5sum rtpproxy-carsten.tar.gz
> c02b1e2ac57d39562e86bcfc4ee592b8 rtpproxy-carsten.tar.gz
>
> Thanks,
> Alexandre.
>
> -----Mensagem original-----
> De: kaiserbock2(a)googlemail.com [mailto:kaiserbock2@googlemail.com] Em
> nome de Carsten Bock Enviada em: quarta-feira, 16 de março de 2011
> 13:03
> Para: Alexandre Abreu
> Cc: sr-users(a)lists.sip-router.org
> Assunto: Re: RTPPROXY timeout patch.
>
> Hi Alexandre,
>
> That is strange:
>
> I run the RTP-Proxy like this (directly from the TAR-File, i sent you)
> and Kamailio with attached config-file.
>
> bock@bock-tde:~/ims/rtpproxy$ sudo ./rtpproxy -T 10 -f -F -i -l
> 127.0.0.1 -s udp:*:22222 -d DBUG -n tcp:127.0.0.1
> rtpproxy: Timer started.
> INFO:main: rtpproxy started, pid 4203
> [... Kamailio connects to RTP-Proxy...]
> DBUG:handle_command: received command "4259_8
> UAc98,97,99,104,3,0,8,9,96 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5
> 195.71.4.203 4008 5371f039-40d0-4944-aae7-6f75071a2f8c;1"
> INFO:handle_command: new session 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5,
> tag 5371f039-40d0-4944-aae7-6f75071a2f8c;1 requested, type strong
> INFO:handle_command: new session on a port 45508 created, tag
> 5371f039-40d0-4944-aae7-6f75071a2f8c;1
> INFO:handle_command: pre-filling caller's address with
> 195.71.4.203:4008
> DBUG:doreply: sending reply "4259_8 45508 127.0.0.1 "
> DBUG:handle_command: received command "4259_9 LAc98,96
> 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5 195.71.4.203 4000
> 5371f039-40d0-4944-aae7-6f75071a2f8c;1
> 9915df0c-30fc-49c5-aa8a-c86b4242c094;1
> xmlrpc:http://localhost:8000/RPC2"
> INFO:handle_command: lookup on ports 45508/45238, session timer
> restarted
> INFO:handle_command: setting custom timeout handler
> (xmlrpc:http://localhost:8000/RPC2)
> INFO:handle_command: pre-filling callee's address with
> 195.71.4.203:4000
> DBUG:doreply: sending reply "4259_9 45238 127.0.0.1 "
> INFO:process_rtp: session timeout
> ERR:rtpp_notify_schedule: XMLRPC xmlrpc:http://localhost:8000/RPC2
> INFO:remove_session: RTP stats: 0 in from callee, 0 in from caller, 0
> relayed, 0 dropped
> INFO:remove_session: RTCP stats: 0 in from callee, 0 in from caller, 0
> relayed, 0 dropped
> INFO:remove_session: session on ports 45508/45238 is cleaned up
> ERR:do_timeout_notification: Timeout socket:
> xmlrpc:http://localhost:8000/RPC2
>
> And it works for me:
>
> U 2011/03/16 16:50:14.350721 127.0.0.1:5060 -> 127.0.0.1:15061 BYE
> sip:2@127.0.0.1:15061;ob SIP/2.0.
> Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK06e9.245e2dd7.0.
> To: sip:2@localhost;tag=5371f039-40d0-4944-aae7-6f75071a2f8c.
> From: sip:1@localhost;tag=9915df0c-30fc-49c5-aa8a-c86b4242c094.
> CSeq: 7905 BYE.
> Call-ID: 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5.
> Content-Length: 0.
> User-Agent: kamailio (3.2.0-dev2 (x86_64/linux)).
> Max-Forwards: 70.
> .
>
> U 2011/03/16 16:50:14.350801 127.0.0.1:5060 -> 127.0.0.1:15060 BYE
> sip:1@127.0.0.1:15060;transport=UDP;ob SIP/2.0.
> Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK06e9.345e2dd7.0.
> To: sip:1@localhost;tag=9915df0c-30fc-49c5-aa8a-c86b4242c094.
> From: sip:2@localhost;tag=5371f039-40d0-4944-aae7-6f75071a2f8c.
> CSeq: 7905 BYE.
> Call-ID: 56f0f83a-5373-46a1-b6f6-9ce2f93e68d5.
> Content-Length: 0.
> User-Agent: kamailio (3.2.0-dev2 (x86_64/linux)).
> Max-Forwards: 70.
> .
> [...]
>
> Maybe, you can add some more debug-info from RTP-Proxy...
> And can you verify, that the RTP-Proxy is not trying to send the request?
>
> Kind regards,
> Carsten
>
> 2011/3/16 Alexandre Abreu <alexandre.abreu(a)redt.com.br>:
>> Hi Carsten,
>>
>> Even with your RTPPROXY tarball I was unable to get this working.
>> Session remains after RTPPROXY timeout.
>> I am using KAMAILIO 3.1 branch from GIT and as I told you, I moved
>> the rtpproxy/ from GIT-MASTER to the Kamailio branch (waiting your
backport).
> Is
>> there anything else regarding this feature that should also should be
> moved
>> (beyond rtpproxy/)?
>>
>> Thanks,
>> Alexandre
[View Less]
I am attempting to put together code which will allow us to redirect a
call to a different tn if the route failed.
Example:
User dials 11235551234
Kamailio uses LCR to route to 192.168.0.100 (404 error)
Change $rU to 11235550000 in failure_route
The only way I can get $rU to show up in the SIP message is to call
append_branch() which is not a solution because I now end up with two
SIP messages one that is correct and one that is incorrect.
Here is the failure_route I am using. Any input …
[View More]would be appreciated.
failure_route[ECRC] {
if (t_is_canceled()) {
xlog("L_INFO", "Call has been canceled in 'ECRC'.");
exit;
}
xlog("L_INFO", "SIP Response Code: $T_reply_code");
# We should fail over if we received one of these response codes.
if (!t_check_status("[45][0-9][0-9]")) {
xlog("L_INFO", "Not a failover error.");
exit;
}
# Translate the dialed number into the ECRC DID.
dp_translate("1", "$rU/$rU");
# Load the gateways for normal dialing.
xlog("L_INFO", "Trying to find LCR route for $rU");
if (! load_gws("1", "$rU")) {
xlog("Unable to load routing");
t_reply("503", "Unable to load routing");
exit;
}
xlog("L_INFO", "Trying gateway '$avp(i:709)'");
if (!next_gw()) {
xlog("L_INFO", "No LCR route for $rU");
t_reply("404", "No available gateways");
exit;
}
$rd=$dd;
$rp=$dp;
$du=$ru;
xlog("L_INFO", "ru: $ru");
xlog("L_INFO", "du: $du");
#at this point $ru and $du contain the correct uri.
append_branch();
# Send out the request.
xlog("L_INFO", "Now we're sending the request out.");
if (!t_relay()) {
xlog("L_INFO" "Relay failed!");
t_reply("502", "Bad Gateway");
exit;
}
}
Now I have two SIP messages one containing the correct phone number:
INVITE sip:11235550000@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:xxx.xxx.xxx.xxx;lr=on>
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bK2e2f.4145be65.2
Via: SIP/2.0/UDP
xxx.xxx.xxx.xxx:5060;branch=z9hG4bK28aa7440;rport=5060
Max-Forwards: 69
From: "Steven Wheeler"
<sip:6124243265@xxx.xxx.xxx.xxx>;tag=as30b3d6f5
To: <sip:11235551234@xxx.xxx.xxx.xxx:5060>
...
And one containing the wrong phone number:
INVITE sip:11235551234@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:xxx.xxx.xxx.xxx;lr=on>
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bK2e2f.4145be65.3
Via: SIP/2.0/UDP
xxx.xxx.xxx.xxx:5060;branch=z9hG4bK28aa7440;rport=5060
Max-Forwards: 69
From: "Steven Wheeler"
<sip:6124243265@xxx.xxx.xxx.xxx>;tag=as30b3d6f5
To: <sip:11235551234@xxx.xxx.xxx.xxx:5060>
...
Steven Wheeler
swheeler(a)usinternet.com
952-253-3252
[View Less]
All,
I am a long time lurker but never posted. I am running ser 0.9.6 for many years with no problems. Just recently none of my users can register. Well - they register once then expire out. I noticed that several ser processes are cpu- bound consuming all available cycles.
Once they drop register they can never reregister.
I restored the ser DB to an older one that was saved when the system was working properly. Any ideas why the ser processes would be CPU bound?
Nothing has been …
[View More]changed on the ser proxy in years and the system has been super stable for 2 years. Has anyone seen this behavior in the past?
This is from top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4466 root 25 0 39960 1948 1368 R 35.8 0.0 1:43.97 ser
4477 root 25 0 39960 2028 1448 R 34.5 0.1 0:21.85 ser
4471 root 25 0 39960 2040 1456 R 32.8 0.1 0:47.63 ser
4475 root 25 0 39960 1940 1360 R 32.5 0.0 2:08.90 ser
4470 root 25 0 39960 1916 1336 R 32.2 0.0 1:09.92 ser
4480 root 25 0 39960 1828 1248 R 30.5 0.0 4:45.16 ser
Any ideas would be greatly apreciated.
Michael
See what's next from IPC
www.UnigyfromIPC.com<http://www.UnigyfromIPC.com>
[cid:unigy-logo-compr64b7.png]<http://www.unigyfromipc.com/>
Join the Conversation: LinkedIn<http://www.linkedin.com/groups?mostPopular=&gid=3808474> * Twitter<http://twitter.com/IPC_Systems_Inc>
[cid:tree5326.png]Please consider the environment before printing this email.
________________________________
DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.
[View Less]
Thanks for the quick response, I actually just ended up moving to a
newer version of Kamailio (v3.1.2) and that fixed my problem.
Steven Wheeler
swheeler(a)usinternet.com
952-253-3252
-----Original Message-----
From: sr-users-bounces(a)lists.sip-router.org
[mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Klaus
Darilion
Sent: Friday, March 18, 2011 1:00 PM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
UsersMailing List
Cc: Steven Wheeler
Subject: Re: [SR-Users] …
[View More]$rU isn't used in t_relay() in failure_route
Am 16.03.2011 21:09, schrieb Steven Wheeler:
> $rd=$dd;
> $rp=$dp;
> $du=$ru;
This one I do not understand. Also I do not see the code where you
change $dU?
Anyway, it seems that 2 branches are added: maybe one by lcr module
internally via next_gw and one manually? You can try to change $dU
before calling next_gw and omit the append_branch() call.
regards
klaus
_______________________________________________
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
[View Less]
Did any one had any problem with this?
I have a test setup where I have the following directives for dns caching:
use_dns_cache=yes #enabling DNS caching
dns_cache_del_nonexp=yes # deletes entries if the memory is
becoming full
dns_cache_flags=0
dns_cache_gc_interval=120
dns_cache_init=on
dns_cache_max_ttl=3600
dns_try_ipv6=no # yes if you want the lookup to be
for IPv6 also
dns_try_naptr=yes
despite the fact that I have *dns_try_ipv6=no* …
[View More]kamailio sends a AAAA
request to the DNS server.
This is an extra request in a case where it seems not to be needed.
Also, it seems that a NAPTR request is not sent - I need to investigate
more, being just a hunch for now.
All the best
Radu Costin
[View Less]
Hi all,
we are running Kamailio 3.1.2 in a production environment, using the dialog
module, and it crashed two hours ago.
Here you have the logs we got (addtional log fragments with the acc records
involved in this call are appended at the end of the mail):
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: CRITICAL: dialog
[dlg_hash.c:599]: bogus ref -1 with cnt 1 for dlg 0x7f23f472db30
[2490:1070436595] with clid 'e0a20cb844d211e0acd8001422093865@<CLIENT IP>'
and tags '…
[View More]1577886432-3759264324-335599788-1698171170' ''
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: : <core>
[mem/q_malloc.c:446]: BUG: qm_free: freeing already freed pointer, first
free: dialog: dlg_cb.c: destroy_dlg_callbacks_list(80) - aborting
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT: <core>
[main.c:741]: child process 28927 exited by a signal 6
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT: <core>
[main.c:744]: core was not generated
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: INFO: <core>
[main.c:756]: INFO: terminating due to SIGCHLD
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28948]: INFO: <core>
[main.c:807]: INFO: signal 15 received
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28942]: INFO: <core>
[main.c:807]: INFO: signal 15 received
We get the kamailio code from git last week:
sercmd> core.info
{
version: kamailio 3.1.2
id: 4ace86
compiler: gcc 4.3.2
compiled: 09:12:36 Feb 23 2011
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
}
The problem looks like this other one already fixed:
http://lists.sip-router.org/pipermail/sr-users/2009-November/027351.html
We set the Kamailio to debug level in case it happens again.
On the other side, I need to know why the core is not been generated. I have
already checked the points mentioned in
http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:corefiles
1. disable_core_dump is not set in the config file.
2. From /etc/default/kamailio:
...
DUMP_CORE=yes
...
2. From /etc/init.d/kamailio:
...
if test "$DUMP_CORE" = "yes" ; then
# set proper ulimit
ulimit -c unlimited
# directory for the core dump files
COREDIR=/home/corefiles
[ -d $COREDIR ] || mkdir $COREDIR
chmod 777 $COREDIR
echo "$COREDIR/core.%e.sig%s.%p" > /proc/sys/kernel/core_pattern
fi
...
4. Writting permissions of $COREDIR
ls -hall /home
...
drwxrwxrwx 2 root root 4.0K 2010-12-21 09:15 corefiles
...
What else should I check?
Thanks in advance,
regards
Antón
*Acc records related to the dialog whose destruction causes the problem:*
Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28902]: NOTICE: acc
[acc.c:275]: ACC: transaction answered:
timestamp=1299073364;method=INVITE;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@<client
IP>;code=200;reason=OK;src_user=<caller number>;src_domain=<client
IP>;dst_ouser=<called
number>;dst_user=<called number>;dst_domain=10.90.1.251;src_ip=<client IP>
...
Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28920]: NOTICE: acc
[acc.c:275]: ACC: request acknowledged:
timestamp=1299073364;method=ACK;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@<client
IP>;code=200;reason=OK;src_user=<caller number>;src_domain=<client
IP>;dst_ouser=<called number>;dst_user=<called
number>;dst_domain=10.90.1.251;src_ip=<client IP>
...
Mar 2 14:43:00 kamailio2 /usr/local/sbin/kamailio[28903]: ERROR: <script>:
ACK WITHOUT MATCHING TRANSACTION in e0a20cb844d211e0acd8001422093865@<client
IP> call... ignore and discard.
...
Mar 2 14:43:00 kamailio2 /usr/local/sbin/kamailio[28904]: NOTICE: acc
[acc.c:275]: ACC: transaction answered:
timestamp=1299073380;method=BYE;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@<client
IP>;code=200;reason=OK;src_user=<caller number>;src_domain=<client
IP>;dst_ouser=<called number>;dst_user=<called
number>;dst_domain=10.90.1.251;src_ip=<client IP>
[View Less]
May be I miss some important details? No suggestions?
Thank you.
> Hello, all.
> Using nathelper + rtpproxy for subj. Kamailio has public and private
> network interfaces. Asterisk is only private. RTP Proxy is working in
> bridge mode and relaying traffic from UAC to Asterisks.
> Everything is working fine, except one configuration. When the client is
> behind router ( a specific one, I do not have an access there to
> check ), and this UAC is making a call to other …
[View More]public extension, which
> is behind router, then RTP Proxy is relaying traffic to the caller,
> using another UDP port, then the packets arrive.
> For instance:
> UAC 1 -> UAC 2
> PUBLIC_IP:10 > KAMAILIO_IP:5555
> KAMAILIO_IP:5678 > PUBLIC_IP:12
> While for the UAC 2 it looks like:
> PUBLIC_IP:20 > KAMAILIO_IP:6767
> KAMAILIO_IP:4564 > PUBLIC_IP:20
> The source and destination UDP ports are the same. As result, I can hear
> UAC 1 and he cannot hear me.
> In case of we have UAC 3, which is behind other router, call is working
> fine with same configuration.
> "It's routers fault" you can say, but in the same configuration ( I mean
> network, not kamailio ) it worked, but when RTPProxy was not in bridge
> mode and Kamailio and Asterisks were in public network. Reinvites are
> not allowed in both cases.
> The question is, why the source and destination UDP ports are different?
> Using STUN in first case, cause without it, private IP written in
> contacts and as result, traffic relayed from Kamailio is incorrect,
> cause heading to private network which is unreachable.
> Any ideas where to dig?
[View Less]
Hello,
I am just curious because I have seen a couple of references to the fr_timer
being in SECONDS and some look like they are in MILLISECONDS. In 1.5.X,
what is this value?
Also - will fr_timer control the retransmission of an INVITE if no 100
Trying is received? Right now it appears my configuration is waiting 500ms
to retransmit the INVITE when I don't get a 100 trying.
This is what my config looks like right now and this is the behavior I'm
seeing.
modparam("tm","fr_timer",15)
…
[View More]modparam("tm","fr_inv_timer",120)
modparam("tm","fr_inv_timer_avp", "$avp(i:704)")
INITIAL INVITE
[No response in 500ms]
RETRANS INVITE
[NO response in 1000ms]
RETRANS INVITE
I'm having a hard time correlating that what I have in my config.
Thanks,
Geoff
[View Less]