[SR-Users] Unable to parse the Cancel request

Daniel-Constantin Mierla miconda at gmail.com
Wed May 5 19:00:30 CEST 2021


Hello,

can you try the TOH header scenario with any of latest 5.4, 5.5 or
master branches? I just pushed a commit that should fix it.

Cheers,
Daniel

On 05.05.21 18:32, Ilie Soltanici wrote:
> Hello,
>
> Thank you Daniel for looking into this, I think I found the problem
> and it was in the header:
>
> *TOH: 123456789*
> *
> *
> For some reason kamailio parsed it as a "To" header, by removing this
> header the Cancel message was delivered successfully out.
>
> Thank you.
>
> On Wed, 5 May 2021 at 17:28, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     hmm, 5.4.5 should have been also good, being the last in 5.4.x
>     series, with the fix that I was thinking of. I will look at the code.
>
>     Cheers,
>     Daniel
>
>     On 05.05.21 17:56, Ilie Soltanici wrote:
>>     Hello,
>>
>>     Yes, initially I was trying with version 5.4.5, then I upgraded
>>     to the latest version from 5.5 branch - but this didn't fix the
>>     issue.
>>
>>     version: kamailio 5.5.0 (x86_64/linux) d4c1a1
>>     flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
>>     DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC,
>>     Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
>>     FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER,
>>     USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES,
>>     TLS_PTHREAD_MUTEX_SHARED
>>     ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144,
>>     MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>>     poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>     id: d4c1a1
>>     compiled on 16:08:42 May  5 2021 with gcc 8.3.0
>>
>>     OS: Description: Debian GNU/Linux 10 (buster)
>>
>>     Thank you.
>>
>>     On Wed, 5 May 2021 at 16:42, Daniel-Constantin Mierla
>>     <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>
>>         Hello,
>>
>>         are you running the latest version in the X.Y series? Likely
>>         you have a version with an issue that was fixed, iirc.
>>
>>         Cheers,
>>         Daniel
>>
>>         On 05.05.21 17:32, Ilie Soltanici wrote:
>>>         Hello,
>>>
>>>         No, that's not the case, see below the INVITE sent to the
>>>         branch:
>>>
>>>         INVITE sip:123456789 at 1.2.3.4:5060;transport=UDP SIP/2.0
>>>         Record-Route: <sip:1.2.3.4:5060;lr;ftag=244c2803;did=cb4.8cb>
>>>         Via: SIP/2.0/UDP
>>>         1.2.3.4:5060;branch=z9hG4bK0f41.5079ae8da835958ee58ca1e8a4eb057b.0
>>>         Via: SIP/2.0/UDP
>>>         192.168.1.10:40769;received=1.3.5.7;branch=z9hG4bK-524287-1---46a5782b47b6ec85;rport=40769
>>>         Max-Forwards: 69
>>>         Contact:
>>>         <sip:101 at 1.3.5.7:40769;transport=UDP;alias=1.3.5.7~40769~1>
>>>         To: <sip:123456789 at 1.2.3.4:5060
>>>         <http://sip:123456789@1.2.3.4:5060>>
>>>         From: <sip:101 at 1.2.3.4:5060;transport=UDP>;tag=244c2803
>>>         Call-ID: KfuC1GMvCvk1YCSKnHwDrw..
>>>         CSeq: 2 INVITE
>>>         Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE,
>>>         OPTIONS, INFO, SUBSCRIBE
>>>         Content-Type: application/sdp
>>>         User-Agent: Z 5.4.12 v2.10.13.2-mod
>>>         Allow-Events: presence, kpml, talk
>>>         Content-Length: 336
>>>         TOH: 123456789
>>>
>>>         v=0
>>>         o=Z 1620220570589 1 IN IP4 1.3.5.7
>>>         s=Z
>>>         c=IN IP4 1.3.5.7
>>>         t=0 0
>>>         m=audio 8000 RTP/AVP 106 9 98 101 0 8 3
>>>         a=rtpmap:106 opus/48000/2
>>>         a=fmtp:106 sprop-maxcapturerate=16000; minptime=20;
>>>         useinbandfec=1
>>>         a=rtpmap:98 telephone-event/48000
>>>         a=fmtp:98 0-16
>>>         a=rtpmap:101 telephone-event/8000
>>>         a=fmtp:101 0-16
>>>         a=sendrecv
>>>
>>>         thanks
>>>
>>>         On Wed, 5 May 2021 at 16:24, Daniel-Constantin Mierla
>>>         <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>>
>>>             Hello,
>>>
>>>             the CANCEL to be sent is generated locally by tm module
>>>             from the INVITE that was sent on the branch, so the
>>>             errors is actually about a duplicate To header in that
>>>             INVITE. Check it on the network to see if that's the case.
>>>
>>>             Cheers,
>>>             Daniel
>>>
>>>             On 05.05.21 16:25, Ilie Soltanici wrote:
>>>>             Hello,
>>>>
>>>>             We are having an issue here where Kamailio is
>>>>             complaining about duplicate To header, while in the SIP
>>>>             Packet there is just one. See below the log message:
>>>>
>>>>             DEBUG: tm [t_msgbuilder.c:391]: build_local_reparse():
>>>>             duplicate To header
>>>>             ERROR: tm [t_msgbuilder.c:531]: build_local_reparse():
>>>>             cannot build CANCEL request
>>>>             ERROR: tm [t_cancel.c:297]: cancel_branch(): attempt to
>>>>             build a CANCEL failed
>>>>             ERROR: tm [t_fwd.c:1434]: e2e_cancel(): cancel error
>>>>
>>>>             And this is the sip message:
>>>>
>>>>             CANCEL sip:123456789 at 1.2.3.4:5060
>>>>             <http://sip:123456789@1.2.3.4:5060> SIP/2.0
>>>>             Via: SIP/2.0/UDP
>>>>             192.168.1.1:19373;branch=z9hG4bK-524287-1---7774073fad1a3264;rport
>>>>             Max-Forwards: 70
>>>>             To: <sip:123456789 at 1.2.3.4:5060
>>>>             <http://sip:123456789@1.2.3.4:5060>>
>>>>             From: "101"<sip:101 at 1.2.3.4:5060
>>>>             <http://sip:101@1.2.3.4:5060>>;tag=6f373b66
>>>>             Call-ID: hC2O6zx8ZaUJ1di046
>>>>             CSeq: 2 CANCEL
>>>>             Proxy-Authorization: Digest
>>>>             username="101",realm="1.2.3.4",nonce="YJKbfWCSmlFTHxdJfKmySydF9L7FzfaqcgyOo4A=",uri="sip:123456789 at 1.2.3.4:5060
>>>>             <http://sip:123456789@1.2.3.4:5060>",response="2bf2ba8ef2374d6aa8c39d650613077d",algorithm=MD5
>>>>             User-Agent: TEST
>>>>             Content-Length: 0
>>>>
>>>>             version: kamailio 5.5.0 (x86_64/linux) d4c1a1
>>>>
>>>>             The route itself, is like in the standard documentation:
>>>>
>>>>             # CANCEL processing
>>>>                       if KSR.is_CANCEL() :
>>>>                           KSR.info(RANDOM_LOG + 'KSR.is_CANCEL')
>>>>                           if KSR.tm.t_check_trans()>0 :
>>>>                               self.ksr_route_relay(msg)
>>>>                           return 1
>>>>
>>>>
>>>>                def ksr_route_relay(self, msg):
>>>>                     if KSR.is_method_in("IBSU") :
>>>>                         if KSR.tm.t_is_set("branch_route")<0 :
>>>>                             KSR.tm.t_on_branch("ksr_branch_manage")
>>>>
>>>>                     if KSR.is_method_in("ISU") :
>>>>                         if KSR.tm.t_is_set("onreply_route")<0 :
>>>>                             KSR.tm.t_on_reply("ksr_onreply_manage")
>>>>
>>>>                     if KSR.is_INVITE() :
>>>>                         if KSR.tm.t_is_set("failure_route")<0 :
>>>>                             KSR.tm.t_on_failure("ksr_failure_manage")
>>>>
>>>>                     if KSR.tm.t_relay()<0 :
>>>>                         KSR.sl.sl_reply_error()
>>>>
>>>>                     return -255
>>>>
>>>>             Thanks
>>>>
>>>>             __________________________________________________________
>>>>             Kamailio - Users Mailing List - Non Commercial Discussions
>>>>               * sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>>>             Important: keep the mailing list in the recipients, do not reply only to the sender!
>>>>             Edit mailing list options or unsubscribe:
>>>>               * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>>>
>>>             -- 
>>>             Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>>             www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>>             Kamailio Advanced Training - Online
>>>             May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
>>>               * https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>
>>>
>>         -- 
>>         Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>         www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>         Kamailio Advanced Training - Online
>>         May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
>>           * https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>
>>
>     -- 
>     Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>     www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>     Kamailio Advanced Training - Online
>     May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
>       * https://www.asipto.com/sw/kamailio-advanced-training-online/ <https://www.asipto.com/sw/kamailio-advanced-training-online/>
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
  * https://www.asipto.com/sw/kamailio-advanced-training-online/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210505/d816e28c/attachment.htm>


More information about the sr-users mailing list