Re: [SR-Users] The plan for releasing Kamailio v5.5.0

[Daniel-Constantin Mierla]

Hello,

this is the day for v5.5.0 -- as usual when a release is prepared, any
commit to branch 5.5 should be announced to sr-dev mainling list or
irc/matrix channels and wait for ack, in order to avoid packaging
conflicts. Once the announcement is out, commits can go in branch 5.5 as
usual.

Cheers,
Daniel

On 27.04.21 12:32, Daniel-Constantin Mierla wrote:
> Hello,
>
> after almost 4 weeks since development was frozen, it is time to plan
> releasing the next major stable version, respectively 5.5.0, therefore I
> propose to do it on Wednesday, May 5, 2021.
>
> The branch 5.5 was already created about one week ago, several doc
> resources were published (core/variables/transformations/rpcs/stats
> cookbooks, alphabetic indexes, ...).
>
> If anyone is testing an upgrade from branch 5.4 to 5.5 and encounters
> changes that should be done in Kamailio config, add notes about at:
>
>   * https://www.kamailio.org/wiki/install/upgrade/5.4.x-to-5.5.0
>
> Cheers,
> Daniel
>
> -- 
> 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/
>
-- 
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/


__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] dialog OPTIONS

[Daniel-Constantin Mierla]

Hello,

do you track both legs of the call in kamailio? From freeswitch comes
back a completely new call.

Cheers,
Daniel

On 04.05.21 16:59, David Villasmil wrote:
> Hello guys,
>
> I'm using the dialog module, params are:
>
> # - dialog params -
> modparam("dialog", "db_mode", 0)
> modparam("dialog", "dlg_flag", 20)
> modparam("dialog", "ka_timer", 10)
> modparam("dialog", "ka_interval", 30)
> modparam("dialog", "ka_failed_limit", 2)
> modparam("dialog", "send_bye", 1)
> modparam("dialog", "timer_procs", 1)
>
> When receiving an INVITE, i'm doing
>
> dlg_set_property("ka-src");
> dlg_set_property("ka-dst");
> dlg_set_property("timeout-noreset");
>
> I have a couple questions:
>
> The flow is the following:
>
> clientA>-\
>           kamailio<->freeswitch
> clientB<-/
>
> Kamailio receives an INVITE from ClientA, which I forward to
> freeswitch, which in turn forwards it back to Kamailio.
>
> In reality I would like to monitor only the client legs, but I'm
> having problems, so I'm enabling OPTIONS on all legs.
>
> On the ClientA legs, I see OPTIONS going from kamailio to both
> freeswitch and the client.
> But on the ClientB legs i don't see any OPTIONS at all.
>
> Can someone point me in the right direction to enable it on all legs?
>
> Something else i'm seeing is even though i set "ka_failed_limit" to 2,
> kamailio is sending several OPTIONS before sending BYEs to both legs
> (clientA, since there are no OPTIONS on clientB)
>
>
> Thanks all,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> 
> phone: +34669448337
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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

-- 
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/

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] start_recording and stop_recording inside event_route[xhttp:request]

[Daniel-Constantin Mierla]

Hello,

do you pass "from-tag=xyz" to the start_recording() function?

Cheers,
Daniel

On 05.05.21 13:51, Володимир Іванець wrote:
> Hello Daniel,
>
> Sorry, I was out of the office and could make a test only now. As you
> told, the HTTP request is now processed differently. Unfortunately, I
> can no longer start call recording. I tried the following options and
> got the "rtpp_function_call(): can't get From tag" error message each
> time.
>
>  1. /usr/bin/curl -H "Content-Type: text"
> 
> "http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0
> 
> "
>  2. /usr/bin/curl -H "Content-Type: text"
> 
> "http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0
> 
> "
> -H "From:  >;tag=1"
>  3. /usr/bin/curl -H "Content-Type: text"
> 
> "http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0
> 
> "
> -H "Call-Id: 249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0" -H
> "To: sip:456@127.0.0.1:5060 " -H
> "From: http://sip:123@127.0.0.1:5080>>;tag=1"
>
>
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/parse_fline.c:250]: parse_first_line(): first line
> type 1 (request) flags 2/
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request:/
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:679]: parse_msg():  method:  /
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:681]: parse_msg():  uri:    
> /
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:683]: parse_msg():  version: /
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/parse_hname2.c:294]: parse_sip_header_name(): parsed
> header name [Via] type 1/
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/parse_via.c:2639]: parse_via(): end of header
> reached, state=5/
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2/
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:557]: parse_headers(): this is the first
> via/
> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 

Re: [SR-Users] start_recording and stop_recording inside event_route[xhttp:request]

[Володимир Іванець]

Hello Daniel,

Sorry, I was out of the office and could make a test only now. As you told,
the HTTP request is now processed differently. Unfortunately, I can no
longer start call recording. I tried the following options and got the
"rtpp_function_call(): can't get From tag" error message each time.


   1. /usr/bin/curl -H "Content-Type: text" "
   
http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0
   "
   2. /usr/bin/curl -H "Content-Type: text" "
   
http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0;
   -H "From: ;tag=1"
   3. /usr/bin/curl -H "Content-Type: text" "
   
http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0;
   -H "Call-Id: 249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0" -H "To:
   sip:456@127.0.0.1:5060" -H "From: ;tag=1"


*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
[core/parser/parse_fline.c:250]: parse_first_line(): first line type 1
(request) flags 2*
*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
[core/parser/msg_parser.c:677]: parse_msg(): SIP Request:*
*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
[core/parser/msg_parser.c:679]: parse_msg():  method:  *
*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
[core/parser/msg_parser.c:681]: parse_msg():  uri:
*
*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
[core/parser/msg_parser.c:683]: parse_msg():  version: *
*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
[core/parser/parse_hname2.c:294]: parse_sip_header_name(): parsed header
name [Via] type 1*
*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
[core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5*
*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
[core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2*
*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
[core/parser/msg_parser.c:557]: parse_headers(): this is the first via*
*May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 

Re: [SR-Users] Unable to parse the Cancel request

[Daniel-Constantin Mierla]

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@1.2.3.4:5060;transport=UDP SIP/2.0
> Record-Route: 
> 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: 
> To: http://sip:123456789@1.2.3.4:5060>>
> From: ;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
> mailto:mico...@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@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: http://sip:123456789@1.2.3.4:5060>>
>> From: "101"> >;tag=6f373b66
>> Call-ID: hC2O6zx8ZaUJ1di046
>> CSeq: 2 CANCEL
>> Proxy-Authorization: Digest
>> 
>> username="101",realm="1.2.3.4",nonce="YJKbfWCSmlFTHxdJfKmySydF9L7FzfaqcgyOo4A=",uri="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@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 
>> 
>
> -- 
> 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/ 
> 

Re: [SR-Users] Unable to parse the Cancel request

[Daniel-Constantin Mierla]

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@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: http://sip:123456789@1.2.3.4:5060>>
> From: "101" >;tag=6f373b66
> Call-ID: hC2O6zx8ZaUJ1di046
> CSeq: 2 CANCEL
> Proxy-Authorization: Digest
> username="101",realm="1.2.3.4",nonce="YJKbfWCSmlFTHxdJfKmySydF9L7FzfaqcgyOo4A=",uri="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@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

-- 
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/

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Unable to parse the Cancel request

[Ilie Soltanici]

Hello,

No, that's not the case, see below the INVITE sent to the branch:

INVITE sip:123456789@1.2.3.4:5060;transport=UDP SIP/2.0
Record-Route: 
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: 
To: 
From: ;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 
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@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: 
> From: "101";tag=6f373b66
> Call-ID: hC2O6zx8ZaUJ1di046
> CSeq: 2 CANCEL
> Proxy-Authorization: Digest
> username="101",realm="1.2.3.4",nonce="YJKbfWCSmlFTHxdJfKmySydF9L7FzfaqcgyOo4A=",uri="
> 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@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
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.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/
>
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

[SR-Users] Unable to parse the Cancel request

[Ilie Soltanici]

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@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: 
From: "101";tag=6f373b66
Call-ID: hC2O6zx8ZaUJ1di046
CSeq: 2 CANCEL
Proxy-Authorization: Digest
username="101",realm="1.2.3.4",nonce="YJKbfWCSmlFTHxdJfKmySydF9L7FzfaqcgyOo4A=",uri="
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@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

[SR-Users] Kamailio v5.5.0 Released - new major version is out

[Daniel-Constantin Mierla]

Kamailio v5.5.0 is out – it comes with 6 new modules and a considerable
set of improvements touching again more than 80 existing modules.

You can read detailed release notes at:

   * https://www.kamailio.org/w/kamailio-v5-5-0-release-notes/

Many thanks to all developers and community members that made possible
this release.

v5.5.0 brings more flexibility and optimizations across many components,
enhancements to distributed message queue (dmq module), load balancer,
http client, STIR/SHAKEN support, IMS/VoLTE, rtpengine and tls as well
as to make available more functions to KEMI interface ... just to list
only a few here. Enjoy Kamailio v5.5.0!

Thank you for flying Kamailio!

Stay safe and healthy!
Daniel

-- 
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/


__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Unable to parse the Cancel request

[Ilie Soltanici]

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 
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@1.2.3.4:5060;transport=UDP SIP/2.0
> Record-Route: 
> 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: 
> To: 
> From: ;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 
> 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@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: 
>> From: "101";tag=6f373b66
>> Call-ID: hC2O6zx8ZaUJ1di046
>> CSeq: 2 CANCEL
>> Proxy-Authorization: Digest
>> username="101",realm="1.2.3.4",nonce="YJKbfWCSmlFTHxdJfKmySydF9L7FzfaqcgyOo4A=",uri="
>> 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@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
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
>> www.linkedin.com/in/miconda
>> Kamailio Advanced Training - 

Re: [SR-Users] start_recording and stop_recording inside event_route[xhttp:request]

[Володимир Іванець]

Hello,

I did not. I misunderstood your previous message. Now I called
start_recording() and stop_recording() with *call-id* and *from-tag* flags
and everything worked fine.

Thank you very much!

ср, 5 трав. 2021 о 16:46 Daniel-Constantin Mierla  пише:

> Hello,
>
> do you pass "from-tag=xyz" to the start_recording() function?
>
> Cheers,
> Daniel
> On 05.05.21 13:51, Володимир Іванець wrote:
>
> Hello Daniel,
>
> Sorry, I was out of the office and could make a test only now. As you
> told, the HTTP request is now processed differently. Unfortunately, I can
> no longer start call recording. I tried the following options and got the
> "rtpp_function_call(): can't get From tag" error message each time.
>
>
>1. /usr/bin/curl -H "Content-Type: text" "
>
> http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0
>"
>2. /usr/bin/curl -H "Content-Type: text" "
>
> http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0;
>-H "From: ;tag=1"
>3. /usr/bin/curl -H "Content-Type: text" "
>
> http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0;
>-H "Call-Id: 249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0" -H
>"To: sip:456@127.0.0.1:5060" -H "From: ;tag=1"
>
>
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/parse_fline.c:250]: parse_first_line(): first line type 1
> (request) flags 2*
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request:*
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:679]: parse_msg():  method:  *
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:681]: parse_msg():  uri:
> 
> *
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:683]: parse_msg():  version: *
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/parse_hname2.c:294]: parse_sip_header_name(): parsed header
> name [Via] type 1*
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5*
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2*
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 
> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via*
> *May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG: 

Re: [SR-Users] start_recording and stop_recording inside event_route[xhttp:request]

[Daniel-Constantin Mierla]

Hello,

ok, good that it works now. You should still be able to take them from
headers with $ci and $ft, but they have to be provided in the parameter
of start_recording()/stop_recording() if used with a non-SIP message.

Cheers,
Daniel

On 05.05.21 18:20, Володимир Іванець wrote:
> Hello,
>
> I did not. I misunderstood your previous message. Now I called
> start_recording() and stop_recording() with /call-id/ and
> /from-tag/ flags and everything worked fine.
>
> Thank you very much!
>
> ср, 5 трав. 2021 о 16:46 Daniel-Constantin Mierla  > пише:
>
> Hello,
>
> do you pass "from-tag=xyz" to the start_recording() function?
>
> Cheers,
> Daniel
>
> On 05.05.21 13:51, Володимир Іванець wrote:
>> Hello Daniel,
>>
>> Sorry, I was out of the office and could make a test only now. As
>> you told, the HTTP request is now processed differently.
>> Unfortunately, I can no longer start call recording. I tried the
>> following options and got the "rtpp_function_call(): can't get
>> From tag" error message each time.
>>
>>  1. /usr/bin/curl -H "Content-Type: text"
>> 
>> "http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0
>> 
>> "
>>  2. /usr/bin/curl -H "Content-Type: text"
>> 
>> "http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0
>> 
>> "
>> -H "From: > >;tag=1"
>>  3. /usr/bin/curl -H "Content-Type: text"
>> 
>> "http://localhost:8088/CALL_RECORD_START/249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0
>> 
>> "
>> -H "Call-Id:
>> 249ae6300da4b1393be203e21068f6a2@127.0.0.1:5080.0
>> "
>> -H "To: sip:456@127.0.0.1:5060
>> " -H "From:
>> http://sip:123@127.0.0.1:5080>>;tag=1"
>>
>>
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>>  [core/parser/parse_fline.c:250]: parse_first_line():
>> first line type 1 (request) flags 2/
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>>  [core/parser/msg_parser.c:677]: parse_msg(): SIP Request:/
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>>  [core/parser/msg_parser.c:679]: parse_msg():  method:
>>  /
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>>  [core/parser/msg_parser.c:681]: parse_msg():  uri:    
>> 
>> 
>> 
>> /
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>>  [core/parser/msg_parser.c:683]: parse_msg():  version:
>> /
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>>  [core/parser/parse_hname2.c:294]:
>> parse_sip_header_name(): parsed header name [Via] type 1/
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>>  [core/parser/parse_via.c:2639]: parse_via(): end of
>> header reached, state=5/
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>>  [core/parser/msg_parser.c:555]: parse_headers(): Via
>> found, flags=2/
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>>  [core/parser/msg_parser.c:557]: parse_headers(): this
>> is the first via/
>> /May  5 14:40:43 test /usr/sbin/kamailio[19603]: DEBUG:
>> 

Re: [SR-Users] Unable to parse the Cancel request

[Daniel-Constantin Mierla]

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
> mailto:mico...@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
>> mailto:mico...@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@1.2.3.4:5060;transport=UDP SIP/2.0
>>> Record-Route: 
>>> 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:
>>> 
>>> To: >> >
>>> From: ;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
>>> mailto:mico...@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@1.2.3.4:5060
  SIP/2.0
 Via: SIP/2.0/UDP
  

Re: [SR-Users] Unable to parse the Cancel request

[Daniel-Constantin Mierla]

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
> mailto:mico...@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@1.2.3.4:5060;transport=UDP SIP/2.0
>> Record-Route: 
>> 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: 
>> To: http://sip:123456789@1.2.3.4:5060>>
>> From: ;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
>> mailto:mico...@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@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: >> >
>>> From: "101">> >;tag=6f373b66
>>> Call-ID: hC2O6zx8ZaUJ1di046
>>> CSeq: 2 CANCEL
>>> Proxy-Authorization: Digest
>>> 
>>> username="101",realm="1.2.3.4",nonce="YJKbfWCSmlFTHxdJfKmySydF9L7FzfaqcgyOo4A=",uri="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 

Re: [SR-Users] Unable to parse the Cancel request

[Ilie Soltanici]

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 
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 
> 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@1.2.3.4:5060;transport=UDP SIP/2.0
>> Record-Route: 
>> 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: 
>> To: 
>> From: ;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 
>> 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@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: 
>>> From: "101";tag=6f373b66
>>> Call-ID: hC2O6zx8ZaUJ1di046
>>> CSeq: 2 CANCEL
>>> Proxy-Authorization: Digest
>>> username="101",realm="1.2.3.4",nonce="YJKbfWCSmlFTHxdJfKmySydF9L7FzfaqcgyOo4A=",uri="
>>> 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