Is the messages sent by the end UA directly, or via some proxy?
Cheers,
Daniel
On 07/08/16 07:59, Alex Balashov wrote:
> On 08/07/2016 01:57 AM, Alex Balashov wrote:
>
>> So, I'm guessing the answer to your question is no: the Content-Length
>> is not accurate, and doesn't reflect the full paylo
On 08/07/2016 01:57 AM, Alex Balashov wrote:
So, I'm guessing the answer to your question is no: the Content-Length
is not accurate, and doesn't reflect the full payload from the combined
length of the SDP stanzas (122 + 149 = 271).
I guess it should be 265, not 271.
--
Alex Balashov | Princi
On 08/07/2016 01:50 AM, Daniel-Constantin Mierla wrote:
tcp being a stream protocol, kamailio is reading the body of sip
messages based on content-lenght header -- can you check and see if the
values for content length are accurate?
The initial INVITE has a Content-Length value of 122, but 116
Hello,
tcp being a stream protocol, kamailio is reading the body of sip
messages based on content-lenght header -- can you check and see if the
values for content length are accurate?
Do you have the parameter tcp_accept_no_cl set?
Cheers,
Daniel
On 06/08/16 00:39, Alex Balashov wrote:
> I'll
I'll also add: the initial INVITE is split. Wireshark shows its >= Layer
3 payload size to be 1497. There is a "Continuation" message displayed
which contains the trailing SDP.
So, it sounds like the problem is that the trailing segment is getting
packed into the message buffer for the ACK.
I've also got a binary capture and would be happy to provide privately.
On 08/05/2016 06:24 PM, Alex Balashov wrote:
Hello,
I've got an odd issue where:
1. TCP client makes call out through Kamailio.
2. Call is answered, TCP client sends e2e ACK.
3. Parser chokes on ACK, closes TCP connecti
