[OpenSIPS-Users] Fwd: Opensips + RtpProxy: media stream timed out while starting
Semyon Golubcov
thegolub4 at gmail.com
Tue Feb 17 22:13:53 CET 2015
Here is the clean UDP trace
https://gist.github.com/anonymous/399fc19e2b7465521cd3
2015-02-17 23:07 GMT+02:00 Semyon Golubcov <thegolub4 at gmail.com>:
>
>
> 2015-02-15 2:44 GMT+02:00 Semen Golubcov <thegolub4 at gmail.com>:
>
>> 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 <thegolub4 at gmail.com>:
>>
>>> 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 <eric at uphreak.com>:
>>>
>>>> Or you could uh... Use UDP 5060/till you get your signalling sorted. ;)
>>>> On Feb 13, 2015, at 7:23 PM, Semen Golubcov <thegolub4 at gmail.com>
>>>> 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 <eric at uphreak.com>
>>>>> 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 <users at lists.opensips.org>
>>>>>
>>>>>
>>>>> 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 <thegolub4 at gmail.com>
>>>>> 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:53049768 at 92.xx.xx.xx(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:53049768 at 92.xx.xx.xx(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
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150217/0ba84077/attachment-0001.htm>
More information about the Users
mailing list