One thing that i did notice, comparing the UDP trace with working stream and TLS trace (https://gist.github.com/anonymous/a512beed5290317d1d08) is that, there is no ACK with the correct uri in the TLS trace like so:
INVITE sip:[email protected]:5061 SIP/2.0 ACK sip:[email protected] :50034;transport=tls SIP/2.0 ACK sip:[email protected] :50034;transport=tls SIP/2.0 Contrary to (in udp): INVITE sip:[email protected]:5060 SIP/2.0 ACK sip:[email protected]:5060 SIP/2.0 ACK sip:[email protected] :49804 SIP/2.0 ACK sip:[email protected] :49804 SIP/2.0 So using the udp, the ACK is actually getting sent to the correct server uri, but in tls scenario there is no ACK packet with the correct server uri of the contact is getting sent. Maybe that's where it's all starts!? 2015-02-17 23:16 GMT+02:00 Semyon Golubcov <[email protected]>: > *Misslink, https://gist.github.com/anonymous/d182c80070a14ef7c238 > > 2015-02-17 23:13 GMT+02:00 Semyon Golubcov <[email protected]>: > >> Here is the clean UDP trace >> https://gist.github.com/anonymous/399fc19e2b7465521cd3 >> >> >> >> 2015-02-17 23:07 GMT+02:00 Semyon Golubcov <[email protected]>: >> >>> >>> >>> 2015-02-15 2:44 GMT+02:00 Semen Golubcov <[email protected]>: >>> >>>> P.S. Here i was calling bob from alex on my own system, so both clients >>>> are using my own ip. >>>> >>>> >>>> 2015-02-15 2:42 GMT+02:00 Semen Golubcov <[email protected]>: >>>> >>>>> Hello Eric. I captured the trace with the siptrace module, since it's >>>>> easier to capture tls packets with it. I hope it will do as good as ngrep. >>>>> Here it is: >>>>> >>>>> https://gist.github.com/anonymous/a9046cddd1058cf9ea35 >>>>> >>>>> >>>>> >>>>> 2015-02-14 5:26 GMT+02:00 Eric Tamme <[email protected]>: >>>>> >>>>>> Or you could uh... Use UDP 5060/till you get your signalling sorted. >>>>>> ;) >>>>>> On Feb 13, 2015, at 7:23 PM, Semen Golubcov <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> You mean 5061? The packets are encrypted, i will try to capture them >>>>>>> with ngrep and decrypt with the private key using wireshark and post the >>>>>>> decrypted data to >>>>>>> gist. >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: Eric Tamme <[email protected]> >>>>>>> Date: 2015-02-14 3:47 GMT+02:00 >>>>>>> Subject: Re: [OpenSIPS-Users] Opensips + RtpProxy: media stream >>>>>>> timed out while starting >>>>>>> To: OpenSIPS users mailling list <[email protected]> >>>>>>> >>>>>>> >>>>>>> The message about late back means it is probably not routing. >>>>>>> >>>>>>> Install ngrep and run >>>>>>> >>>>>>> ngrep -qtd any -W byline port 5060 >>>>>>> >>>>>>> On OpenSIPS during the call. Paste the output to a gist on >>>>>>> gist.github.com and include the link in your next reply. >>>>>>> >>>>>>> -Eric >>>>>>> On Feb 13, 2015, at 6:19 PM, Semen Golubcov <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hello. Should i answer you here or send my replies to the user >>>>>>>> list? >>>>>>>> >>>>>>>> I looked up the sip trace and syslog, apparently there are no >>>>>>>> retransmissions i think and there is no messages about "no matching >>>>>>>> transaction exists". >>>>>>>> >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_msg: method: <ACK> >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_msg: uri: <sip:[email protected](my_Public_ip >>>>>>>> (client) ):49190;transport=tls> >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_msg: version: <SIP/2.0> >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_headers: flags=2 >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_via_param: found param type 235, <rport> = <n/a>; >>>>>>>> state=6 >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_via_param: found param type 232, <branch> = >>>>>>>> <z9hG4bKPjb29aaf78cf594541aeb97e0b801a4075>; state=6 >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_via_param: found param type 237, <alias> = <n/a>; >>>>>>>> state=16 >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_via: end of header reached, state=5 >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_headers: via found, flags=2 >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_headers: this is the first via >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:receive_msg: After parse_msg... >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:receive_msg: preparing to run routing scripts... >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:sl:sl_filter_ACK: to late to be a local ACK! >>>>>>>> >>>>>>>> In this example i was calling calling from one user to another on >>>>>>>> my machine (so the ip will always be the same for both clients). I >>>>>>>> guess >>>>>>>> here: >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_msg: method: <ACK> >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_msg: uri: <sip:[email protected](my_Public_ip >>>>>>>> (client) ):49190;transport=tls> >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_msg: version: <SIP/2.0> >>>>>>>> Feb 14 01:19:43 martin /usr/local/sbin/opensips[14061]: >>>>>>>> DBG:core:parse_headers: flags=2 >>>>>>>> >>>>>>>> The server get's the ack from my client, and than opensips says: >>>>>>>> >>>>>>>> "Apr 5 23:06:22 ser /usr/local/sbin/ser[6282]: DEBUG : >>>>>>>> sl_filter_ACK: to >>>>>>>> late to be a local ACK!" >>>>>>>> >>>>>>>> Does this mean that ACK is getting lost? I'll attach the syslog >>>>>>>> just in case. >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> [email protected] >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> Users mailing list >>>>>>> [email protected] >>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> [email protected] >>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
