According to the logs, the INVITE is sent out :
Jan 13 06:12:08 server1 opensips: Jan 13 06:12:08 [17457]
DBG:core:_shm_resize: resize(0) called
Jan 13 06:12:08 server1 opensips: Jan 13 06:12:08 [17457]
DBG:core:mk_proxy: doing DNS lookup...
Jan 13 06:12:08 server1 opensips: Jan 13 06:12:08 [17457]
DBG:tm:set_timer: relative timeout is 500000
Jan 13 06:12:08 server1 opensips: Jan 13 06:12:08 [17457]
DBG:tm:insert_timer_unsafe: [4]: 0x7f8518e24938 (7092500000)
Jan 13 06:12:08 server1 opensips: Jan 13 06:12:08 [17457]
DBG:tm:insert_timer_unsafe: [0]: 0x7f8518e24968 (7097)
Jan 13 06:12:08 server1 opensips: Jan 13 06:12:08 [17457]
DBG:tm:t_relay_to: new transaction fwd'ed
there, are several retransmissions:
Jan 13 06:12:09 server1 opensips: Jan 13 06:12:09 [17458]
DBG:tm:retransmission_handler: retransmission_handler : request
resending (t=0x7f8518e24718, INVITE si ... )
Jan 13 06:12:10 server1 opensips: Jan 13 06:12:10 [17467]
DBG:tm:retransmission_handler: retransmission_handler : request
resending (t=0x7f8518e24718, INVITE si ... )
Jan 13 06:12:12 server1 opensips: Jan 13 06:12:12 [17458]
DBG:tm:retransmission_handler: retransmission_handler : request
resending (t=0x7f8518e24718, INVITE si ... )
and finally, on timeout, it is canceled (toward UAS) and 408 reply
generated:
Jan 13 06:12:14 server1 opensips: Jan 13 06:12:14 [17457]
DBG:tm:final_response_handler: Cancel sent out, sending 408 (0x7f8518e24718)
Jan 13 06:12:14 server1 opensips: Jan 13 06:12:14 [17457]
DBG:tm:t_should_relay_response: T_code=100, new_code=408
Jan 13 06:12:14 server1 opensips: Jan 13 06:12:14 [17457]
DBG:tm:t_pick_branch: picked branch 0, code 408 (prio=800)
Jan 13 06:12:14 server1 opensips: Jan 13 06:12:14 [17457]
DBG:tm:relay_reply: sent buf=0x7f851f8e9518: SIP/2.0 4...,
shmem=0x7f8518e6f618: SIP/2.0 4
I see even a ACC log is created:
Jan 13 06:12:14 server1 opensips: ACC: call missed:
timestamp=1452665534;method=INVITE;from_tag=z9hG4bK17850112;to_tag=;[email protected];code=408;reason=Request
Timeout
So, everything looks good here.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 13.01.2016 08:19, Nabeel wrote:
Hi Bogdan,
I changed log_stderror=yes and log_facility=LOG_DAEMON. Now I see some
more in the log. Do you see anything obviously wrong?
http://pastebin.com/MzJW1P1S
On 12 January 2016 at 09:10, Bogdan-Andrei Iancu <[email protected]
<mailto:[email protected]>> wrote:
Hi Nabeel,
Be sure you are looking into the right log file - maybe the debug
level is redirected by your syslog to another log file... Debug
level 4 is the most verbose one in opensips.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 08.01.2016 21:04, Nabeel wrote:
Hi Bogdan,
I have the following near the top of my config file:
###### Global Parameters #########
debug=4
log_stderror=no
log_facility=LOG_LOCAL1
The log I posted earlier is from opensips running with these
configurations.
On 8 Jan 2016 3:49 pm, "Bogdan-Andrei Iancu" <[email protected]
<mailto:[email protected]>> wrote:
Hi Nabeel,
have you tried running opensips is debug mode (level 4) to
see what it is doing with the request ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 07.01.2016 11:37, Nabeel wrote:
Hi Bogdan,
I used the tshark command as explained here on page 14:
http://opensips.org/pub/events/2015-05-12_OpenSIPS-Summit_Amsterdam/Lorenzo_
<http://opensips.org/pub/events/2015-05-12_OpenSIPS-Summit_Amsterdam/Lorenzo_Mangani-OpenSIPS_Summit2015-SIPCapture.pdf>Mangani-OpenSIPS
<http://opensips.org/pub/events/2015-05-12_OpenSIPS-Summit_Amsterdam/Lorenzo_Mangani-OpenSIPS_Summit2015-SIPCapture.pdf>_
<http://opensips.org/pub/events/2015-05-12_OpenSIPS-Summit_Amsterdam/Lorenzo_Mangani-OpenSIPS_Summit2015-SIPCapture.pdf>Summit2015-SIPCapture.pdf
<http://opensips.org/pub/events/2015-05-12_OpenSIPS-Summit_Amsterdam/Lorenzo_Mangani-OpenSIPS_Summit2015-SIPCapture.pdf>
tshark -o "ssl.desegment_ssl_records: TRUE" -o
"ssl.desegment_ssl_application_data: TRUE" -o
"ssl.keys_list:
162.249.6.110,5061,sip,/install/tls/domain.com-key.pem" -i
eth0 -f "tcp port 5061"
I'm using a command line version of Linux without a graphic
UI, so I could not "configure Wireshark to decide TLS" as
mentioned in that document, however I did pass the private
key in the command as shown above.
Does tshark require configuring to decode TLS, other than
passing the private key in the command?
Hi Nabeel,
Indeed, the 408 seems generated by OpenSIPS (after 5
seconds). Such reply is generated only if the the request
was actually sent out (if no request sent, there is no
timeout). But the network capture does not show anything :(
... maybe wrong capturing ?
So you see anything in the logs ? have you tried to run with
debug level 4 ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 06.01.2016 23:07, Nabeel wrote:
I managed to capture the SIP traffic with Wireshark. It
seems that the party generating the 408 reply is OpenSIPS,
not the callee. OpenSIPS does not seem to forward the call
to the callee at all.
Below are traces showing a successful call and a call with
Request Timeout.
The server IP is 162.249.6.110, the caller IP is
92.40.249.9, and the callee IP is 188.29.165.24.
Trace for a successful call:
http://pastebin.com/2xn0bkEU
Trace for a call with Request Timeout:
http://pastebin.com/WR7BA6pj
Please advise what may be causing this.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
