Hello Daniel,

Thanks for your response, but I still think there's an error in openser. Let me explain it:

This is the first INVITE that arrives at openser (Frame #3)

Frame 3 (1257 bytes on wire, 1257 bytes captured)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: Dell_aa:32:dd (00:11:43:aa:32:dd)
Internet Protocol, Src: 10.161.14.59 (10.161.14.59), Dst: 10.161.14.110 (10.161.14.110 )
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 7000 (7000)
Session Initiation Protocol
    Request-Line: INVITE sip:user4@home2.jagarvayo.dev SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 10.161.14.59;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002,SIP/2.0/UDP 10.161.14.59;branch=z9hG4bKdbe6e7de6d54b4e9ab0b8e1dc4a09cb3;XXXIT_002,SIP/2.0/UDP 10.161.14.59;branch=z9hG4bKbee4d2140af14727cd281a783633a8f
        From: <sip:user3@home2.jagarvayo.dev>;tag=6661
        To: <sip:user4@home2.jagarvayo.dev>
        Supported: 100rel
        Call-ID: 1-17070@10.161.14.105
        CSeq: 1 INVITE


This is the INVITE proxied by openser (Frame #5)

Frame 5 (1397 bytes on wire, 1397 bytes captured)
Ethernet II, Src: Dell_bb:14:43 (00:11:43:bb:14:43), Dst: 00:00:00_00:00:01 (00:00:00:00:00:01)
Internet Protocol, Src: 10.161.14.110 (10.161.14.110), Dst: 10.161.14.59 (10.161.14.59 )
User Datagram Protocol, Src Port: 7000 (7000), Dst Port: 5060 (5060)
Session Initiation Protocol
    Request-Line: INVITE sip:user4@home2.jagarvayo.dev SIP/2.0
    Message Header
        Record-Route: <sip:10.161.14.110:7000;ftag=6661;lr>
        Via: SIP/2.0/UDP 10.161.14.110:7000;branch=z9hG4bK5ead.85b42d6fbdf28af51be1fd77461ef605.0
        Via: SIP/2.0/UDP 10.161.14.59;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002,SIP/2.0/UDP 10.161.14.59;branch=z9hG4bKdbe6e7de6d54b4e9ab0b8e1dc4a09cb3;XXXIT_002,SIP/2.0/UDP 10.161.14.59;branch=z9hG4bKbee4d2140af14727cd281a783633a8f
        From: <sip:user3@home2.jagarvayo.dev>;tag=6661
        To: <sip:user4@home2.jagarvayo.dev>
        Supported: 100rel
        Call-ID: 1-17070@10.161.14.105
        CSeq: 1 INVITE

This the CANCEL message that arrives at openser (Frame #19)

Frame 19 (349 bytes on wire, 349 bytes captured)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: Dell_aa:32:dd (00:11:43:aa:32:dd)
Internet Protocol, Src: 10.161.14.59 (10.161.14.59), Dst: 10.161.14.110 (10.161.14.110 )
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 7000 (7000)
Session Initiation Protocol
    Request-Line: CANCEL sip:10.161.14.105:6030 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 10.161.14.59;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002
        Call-ID: 1-17070@10.161.14.105
        From: <sip:user3@home2.jagarvayo.dev>;tag=6661
        To: <sip:user4@home2.jagarvayo.dev>
        CSeq: 1 CANCEL
        Max-Forwards: 70
        Content-Length: 0


This is the CANCEL message sent by openser (Frame #20), to cancel the invite in frame #5

Frame 20 (451 bytes on wire, 451 bytes captured)
Ethernet II, Src: Dell_bb:14:43 (00:11:43:bb:14:43), Dst: 00:00:00_00:00:01 (00:00:00:00:00:01)
Internet Protocol, Src: 10.161.14.110 (10.161.14.110), Dst: 10.161.14.59 (10.161.14.59 )
User Datagram Protocol, Src Port: 7000 (7000), Dst Port: 5060 (5060)
Session Initiation Protocol
    Request-Line: CANCEL sip:user4@home2.jagarvayo.dev SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 10.161.14.110:7000;branch=z9hG4bK5ead.24bd76c541a061667969156e698855df.0
        Via: SIP/2.0/UDP 10.161.14.59;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002
        Call-ID: 1-17070@10.161.14.105
        From: <sip:user3@home2.jagarvayo.dev>;tag=6661
        To: <sip:user4@home2.jagarvayo.dev>
        CSeq: 1 CANCEL
        Max-Forwards: 69
        Content-Length: 0

Should not the CANCEL in frame #20 have the same branch as in the INVITE in frame #5? (As it is said in 3261)
Via: SIP/2.0/UDP 10.161.14.110:7000;branch=z9hG4bK5ead.85b42d6fbdf28af51be1fd77461ef605.0
instead of
Via: SIP/2.0/UDP 10.161.14.110:7000;branch=z9hG4bK5ead.24bd76c541a061667969156e698855df.0


The proxy in 10.161.14.59 is answering "call leg transaction does not exists" because there is no transaction with that branch.

I agree that the proxy at 10.161.14.59 has changed the request-uri, but openser seems to locate the transaction to be cancelled but still does not put a right branch in the CANCEL.

Best Regards,
Jose Antonio