and here is the more detailed SIP trace for UDP: http://pastebin.com/UfQJJz3Y
On 13 January 2016 at 06:19, Nabeel <[email protected]> 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]> > 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 Developerhttp://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]> 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 Developerhttp://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 Developerhttp://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
