hello Daniel
:-[
....alright, trying to duplicate the issue of the complain, i guess i
changed that and since i finally got an error i missed the fact the Cseq
was not ok.
the strange thing is that they have timeout when they send an OPTIONS like
U 79.170.68.171:5084 -> 10.100.10.67:5060
OPTIONS sip:52.88.180.226:5060 SIP/2.0.
Via: SIP/2.0/UDP 79.170.68.171:5084;branch=z9hG4bKmfvstb108oednh05umi0.1.
From: <sip:79.170.68.171>;tag=5AEC0759-61E7D23-C613801C.
To: <sip:79.170.68.171>.
Call-ID: 1-10641(a)79.170.68.171.
CSeq: 0 OPTIONS.
Supported: timer.
Max-Forwards: 69.
Content-Length: 0.
Maybe they have some issue receiving the response, because it's true we
reply that
#
U 10.100.10.67:5060 -> 79.170.68.171:5084
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 79.170.68.171:5084;branch=z9hG4bKmfvstb108oednh05umi0.1.
From: <sip:79.170.68.171>;tag=5AEC0759-61E7D23-C613801C.
To: <sip:79.170.68.171>;tag=8925de184eefa723b9e77a8b63457539.c52c.
Call-ID: 1-10641(a)79.170.68.171.
CSeq: 0 OPTIONS.
Server: kamailio (5.1.1 (x86_64/linux)).
Content-Length: 0.
i will tell them
thanks and sorry
david
On 05/06/18 16:57, Daniel-Constantin Mierla wrote:
Hello,
well, obviously the method is missing in the CSeq -- it is:
CSeq: 0.
It should be:
CSeq: 0 OPTIONS.
Cheers,
Daniel
On 05.06.18 16:45, David Escartin wrote:
> hello Daniel
>
> here you have
>
> U 79.170.68.171:5084 -> 10.100.10.67:5060
> OPTIONS sip:bts.io:0;transport=udp SIP/2.0.
> Via: SIP/2.0/UDP 79.170.68.171:5084;branch=z9hG4bK-4458-1-1.
> From:
>
<sip:Kevrineg4nGCR5QE.VfWTHxAXcKat.ell>;tag=127.0.0.1alUtKGp-01023+1+5613000a+7a506358.
> To: <sip:bts.io>.
> Call-ID: 1-9191(a)79.170.68.171.
> CSeq: 0.
> Contact: <sip:Kevrineg4nGCR5QE.VfWTHxAXcKat.ell@79.170.68.171>.
> Supported: replaces, path, 100rel, timer.
> User-Agent: Alcatel-Lucent 5060 MGC-8 9.3.0.7.0.4.
> Accept: application/sdp.
> Content-Length: 0.
>
>
>
> On 04/06/18 12:38, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> can you paste here such a sip message?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 04.06.18 12:25, David Escartin wrote:
>>> hello all
>>>
>>> we have seen that when an OPTIONS is sent with CSep: 0 OPTIONS,
>>> message is not parsed.
>>> Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]:
>>> ERROR: <core> [core/parser/parse_cseq.c:61]: parse_cseq(): no method
>>> found
>>> Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]:
>>> ERROR: <core> [core/parser/parse_cseq.c:92]: parse_cseq(): bad cseq
>>> Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]:
>>> ERROR: <core> [core/parser/msg_parser.c:144]: get_hdr_field(): bad
cseq
>>> Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]:
>>> ERROR: <core> [core/parser/msg_parser.c:331]: parse_headers(): bad
>>> header field [CSeq: 0
>>> Jun 4 10:12:09 proxy-1-aws /usr/local/kamailio/sbin/kamailio[2205]:
>>> WARNING: <core> [core/receive.c:198]: receive_msg(): parsing relevant
>>> headers failed
>>> as far i see in rfc3261
>>> "The
>>> sequence number value MUST be expressible as a 32-bit unsigned
>>> integer and MUST be less than 2**31."
>>>
>>> i don't know if you already discussed about this, but do you think it
>>> would be something to fix?
>>>
>>> best regards and thanks a lot
>>> david escartin
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users(a)lists.kamailio.org
>>>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users