[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-developers] flickering/unusable UI when accepting calls an
From: |
Noel Kuntze |
Subject: |
Re: [Linphone-developers] flickering/unusable UI when accepting calls and "no via in response" |
Date: |
Mon, 25 Sep 2017 10:55:55 +0200 |
Hi,
You are completely right. My patch didn't do anything to this error/bug. It did
not occur due to some
behaviour of the rebuild of the belle-sip package and the hosts file.
I reported the bug to AVM (Manufacturer of the FritzBox).
Kind regards
Noel
On 22.09.2017 11:52, Jehan Monnier wrote:
> Have a look to the received param …
> received=*[*2a02:8071:9288:7d00:84c8:d3a1:9b8d:d79e*]*]
>
> Jehan
> www.linphone.org <http://www.linphone.org>
>
>
>
>> Le 22 sept. 2017 à 11:28, Noel Kuntze <address@hidden
>> <mailto:address@hidden>> a écrit :
>>
>> Hi,
>>
>> That's wrong. There are no brackets in the actual packets. The brackets are
>> just printed by the library. They're not actually there.
>>
>> I will check the code to find out if the function for getting the values
>> from the header is broken (or not).
>> The other calls to the function all use the camel case version of the header.
>>
>> Fixing the server side is not possible, because it's a locked down, ISP
>> provided FritzBox.
>>
>> Kind regards
>>
>> Noel
>>
>> On 22.09.2017 08:51, Jehan Monnier wrote:
>>> Hi,
>>>
>>> Below traces show me that error is from the received parameter:
>>>
>>> message: 2017-09-22 00:07:25:331
>>> [org.antlr.runtime.MismatchedTokenException] reason [1311:1: via_params :
>>> ( via_received[$header_via::current] |
>>> generic_param[BELLE_SIP_PARAMETERS($header_via::current)] );]
>>> error: 2017-09-22 00:07:25:331 header_via parser error for [Via:SIP/2.0/UDP
>>> [2a02:8071:9288:7d00:84c8:d3a1:9b8d:d79e]:5060;branch=z9hG4bK.F90ImGUMC;rport=5060;received=[2a02:8071:9288:7d00:84c8:d3a1:9b8d:d79e]]
>>>
>>> From rfc 3261:
>>>
>>> via-received = "received" EQUAL (IPv4address / IPv6address)
>>>
>>> It means the « [« are not allowed. As this message is malformed, belle-sip
>>> reject it.
>>>
>>> I suggest you to fix it server side.
>>>
>>> Best regards
>>>
>>> Jehan
>>> www.linphone.org <http://www.linphone.org> <http://www.linphone.org>
>>>
>>>
>>>
>>>> Le 22 sept. 2017 à 02:09, Nick Briggs <address@hidden
>>>> <mailto:address@hidden> <mailto:address@hidden>> a écrit :
>>>>
>>>> Hi --
>>>>
>>>> I don't think that's the best way to patch that -- Per RFC 4485 (where it
>>>> clarifies things mostly related to extensions):
>>>>
>>>> Case sensitivity of parameters and values is a constant source of
>>>> confusion, a difficulty that plagued RFC 2543 [17]. This has been
>>>> simplified through the usage of the BNF constructs of RFC 4234 [5],
>>>> which have clear rules of case sensitivity and insensitivity.
>>>> Therefore, the BNF for an extension completely defines the matching
>>>> rules.
>>>>
>>>> Extensions MUST be consistent with the SIP conventions for case
>>>> sensitivity. Methods MUST be case sensitive. Header field names
>>>> MUST be case insensitive. Header field parameter names MUST be case
>>>> insensitive. Header field values and parameter values are sometimes
>>>> case sensitive, and sometimes case insensitive. However, generally,
>>>> they SHOULD be case insensitive. Defining a case-sensitive component
>>>> requires explicitly listing each character through its ASCII code.
>>>>
>>>> So the fix should really be in the code in belle_sip_message_get_header()
>>>> to ensure that the header field name is found with a case-insensitive
>>>> match. Likewise any belle_sip_... routine that retrieves a header field
>>>> parameter by name should be doing a case-insensitive match.
>>>>
>>>> -- Nick Briggs
>>>>
>>>>> On Sep 21, 2017, at 4:27 PM, Noel Kuntze <address@hidden
>>>>> <mailto:address@hidden> <mailto:address@hidden>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I had to patch bellephone-sip, which I did with the attached patch. I'll
>>>>> make a PR to the GH mirror, if that's the way to proceed.
>>>>> The patch only made the error go away, which then first replaced with
>>>>> linphone being unable to find a matching session.
>>>>> Later, the SIP registrar stopped answering via UDP completely. The
>>>>> request packets were larger than the MTU, so I suspect
>>>>> I have a problem with IP fragments in my network. Switching to TCP made
>>>>> it work. I'll investigate further tomorrow.
>>>>>
>>>>> The patch also makes the searching for the "cseq" header more robust by
>>>>> trying to find the "Cseq" header, too, if "cseq" can not be found.
>>>>> I did that, because the code for "cseq" looked funny to me, like the one
>>>>> for "via" and working around the same problem for cseq was easy.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Noel
>>>>>
>>>>> PS: I now know that this is probably the wrong place to have reported
>>>>> this problem.
>>>>>
>>>>> On 22.09.2017 00:23, Noel Kuntze wrote:
>>>>>> Hello list,
>>>>>>
>>>>>> For some weeks already, I can't accept or make calls with linphone over
>>>>>> sip.
>>>>>> When I receive a call, the UI rapidly flashes between the accepted call
>>>>>> UI with the mute buttons and so on,
>>>>>> and the UI for accepting the call.
>>>>>> When trying to make a call, linphone never succeeds and eventually the
>>>>>> tries time out.
>>>>>> linphone logs the following:
>>>>>>
>>>>>> message: 2017-09-22 00:07:25:331
>>>>>> [org.antlr.runtime.MismatchedTokenException] reason [1311:1: via_params
>>>>>> : ( via_received[$header_via::current] |
>>>>>> generic_param[BELLE_SIP_PARAMETERS($header_via::current)] );]
>>>>>> error: 2017-09-22 00:07:25:331 header_via parser error for
>>>>>> [Via:SIP/2.0/UDP
>>>>>> [2a02:8071:9288:7d00:84c8:d3a1:9b8d:d79e]:5060;branch=z9hG4bK.F90ImGUMC;rport=5060;received=[2a02:8071:9288:7d00:84c8:d3a1:9b8d:d79e]]
>>>>>> message: 2017-09-22 00:07:25:331 channel [0x55f2939c7d80] [418] bytes
>>>>>> parsed
>>>>>> error: 2017-09-22 00:07:25:331 channel [0x55f2939c7d80]: no via in
>>>>>> response.
>>>>>> warning: 2017-09-22 00:07:25:331 Response has no via.
>>>>>> warning: 2017-09-22 00:07:25:331 Discarding stateless response [401]
>>>>>>
>>>>>> The messages have a Via header, though. It looks like this:
>>>>>> Via: SIP/2.0/UDP
>>>>>> [2a02:8071:9288:7d00:84c8:d3a1:9b8d:d79e]:5060;branch=z9hG4bK.F90ImGUMC;rport
>>>>>>
>>>>>>
>>>>>> linphone tries to retransmit the packets all the time. It never
>>>>>> succeeds, because the parsing of every response fails with the errors
>>>>>> above.
>>>>>>
>>>>>> OS: Arch Linux
>>>>>> Version: 3.11.1
>>>>>>
>>>>>> Kind regards
>>>>>>
>>>>>> Noel Kuntze
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Linphone-developers mailing list
>>>>>> address@hidden <mailto:address@hidden> <mailto:address@hidden>
>>>>>> https://lists.nongnu.org/mailman/listinfo/linphone-developers
>>>>>
>>>>> --
>>>>> Noel Kuntze
>>>>> IT security consultant
>>>>>
>>>>> GPG Key ID: 0x0739AD6C
>>>>> Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C
>>>>>
>>>>> <0001-Also-check-Via-header-not-just-via.patch>_______________________________________________
>>>>> Linphone-developers mailing list
>>>>> address@hidden <mailto:address@hidden> <mailto:address@hidden>
>>>>> https://lists.nongnu.org/mailman/listinfo/linphone-developers
>>>>
>>>> _______________________________________________
>>>> Linphone-developers mailing list
>>>> address@hidden <mailto:address@hidden> <mailto:address@hidden>
>>>> https://lists.nongnu.org/mailman/listinfo/linphone-developers
>>>
>>>
>>>
>>> _______________________________________________
>>> Linphone-developers mailing list
>>> address@hidden <mailto:address@hidden>
>>> https://lists.nongnu.org/mailman/listinfo/linphone-developers
>>
>> --
>> Noel Kuntze
>> IT security consultant
>>
>> GPG Key ID: 0x0739AD6C
>> Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C
>>
>>
>
>
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/linphone-developers
--
Noel Kuntze
IT security consultant
GPG Key ID: 0x0739AD6C
Fingerprint: 3524 93BE B5F7 8E63 1372 AF2D F54E E40B 0739 AD6C
signature.asc
Description: OpenPGP digital signature