Hello Daniel,<br>
<br>
Thanks for your response, but I still think there's an error in openser. Let me explain it:<br>
<br>
This is the first INVITE that arrives at openser (Frame #3)<br>
<br>
Frame 3 (1257 bytes on wire, 1257 bytes captured)<br>
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)<br>
Internet Protocol, Src: <a href="http://10.161.14.59">10.161.14.59</a> (<a href="http://10.161.14.59">10.161.14.59</a>), Dst: <a href="http://10.161.14.110">10.161.14.110</a> (<a href="http://10.161.14.110">10.161.14.110
</a>)<br>
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 7000 (7000)<br>
Session Initiation Protocol<br>
Request-Line: INVITE <a href="mailto:sip:user4@home2.jagarvayo.dev">sip:user4@home2.jagarvayo.dev</a> SIP/2.0<br>
Message Header<br>
Via: SIP/2.0/UDP
<a href="http://10.161.14.59">10.161.14.59</a>;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002,SIP/2.0/UDP
<a href="http://10.161.14.59">10.161.14.59</a>;branch=z9hG4bKdbe6e7de6d54b4e9ab0b8e1dc4a09cb3;XXXIT_002,SIP/2.0/UDP
<a href="http://10.161.14.59">10.161.14.59</a>;branch=z9hG4bKbee4d2140af14727cd281a783633a8f<br>
From: <<a href="mailto:sip:user3@home2.jagarvayo.dev">sip:user3@home2.jagarvayo.dev</a>>;tag=6661<br>
To: <<a href="mailto:sip:user4@home2.jagarvayo.dev">sip:user4@home2.jagarvayo.dev</a>><br>
Supported: 100rel<br>
Call-ID: <a href="mailto:1-17070@10.161.14.105">1-17070@10.161.14.105</a><br>
CSeq: 1 INVITE<br>
<br>
<br>
This is the INVITE proxied by openser (Frame #5) <br>
<br>
Frame 5 (1397 bytes on wire, 1397 bytes captured)<br>
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)<br>
Internet Protocol, Src: <a href="http://10.161.14.110">10.161.14.110</a> (<a href="http://10.161.14.110">10.161.14.110</a>), Dst: <a href="http://10.161.14.59">10.161.14.59</a> (<a href="http://10.161.14.59">10.161.14.59
</a>)<br>
User Datagram Protocol, Src Port: 7000 (7000), Dst Port: 5060 (5060)<br>
Session Initiation Protocol<br>
Request-Line: INVITE <a href="mailto:sip:user4@home2.jagarvayo.dev">sip:user4@home2.jagarvayo.dev</a> SIP/2.0<br>
Message Header<br>
Record-Route: <sip:<a href="http://10.161.14.110:7000">10.161.14.110:7000</a>;ftag=6661;lr><br>
Via: SIP/2.0/UDP
<a href="http://10.161.14.110:7000">10.161.14.110:7000</a>;branch=z9hG4bK5ead.85b42d6fbdf28af51be1fd77461ef605.0<br>
Via: SIP/2.0/UDP
<a href="http://10.161.14.59">10.161.14.59</a>;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002,SIP/2.0/UDP
<a href="http://10.161.14.59">10.161.14.59</a>;branch=z9hG4bKdbe6e7de6d54b4e9ab0b8e1dc4a09cb3;XXXIT_002,SIP/2.0/UDP
<a href="http://10.161.14.59">10.161.14.59</a>;branch=z9hG4bKbee4d2140af14727cd281a783633a8f<br>
From: <<a href="mailto:sip:user3@home2.jagarvayo.dev">sip:user3@home2.jagarvayo.dev</a>>;tag=6661<br>
To: <<a href="mailto:sip:user4@home2.jagarvayo.dev">sip:user4@home2.jagarvayo.dev</a>><br>
Supported: 100rel<br>
Call-ID: <a href="mailto:1-17070@10.161.14.105">1-17070@10.161.14.105</a><br>
CSeq: 1 INVITE<br>
<br>
This the CANCEL message that arrives at openser (Frame #19)<br>
<br>
Frame 19 (349 bytes on wire, 349 bytes captured)<br>
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)<br>
Internet Protocol, Src: <a href="http://10.161.14.59">10.161.14.59</a> (<a href="http://10.161.14.59">10.161.14.59</a>), Dst: <a href="http://10.161.14.110">10.161.14.110</a> (<a href="http://10.161.14.110">10.161.14.110
</a>)<br>
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 7000 (7000)<br>
Session Initiation Protocol<br>
Request-Line: CANCEL sip:<a href="http://10.161.14.105:6030">10.161.14.105:6030</a> SIP/2.0<br>
Message Header<br>
Via: SIP/2.0/UDP
<a href="http://10.161.14.59">10.161.14.59</a>;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002<br>
Call-ID: <a href="mailto:1-17070@10.161.14.105">1-17070@10.161.14.105</a><br>
From: <<a href="mailto:sip:user3@home2.jagarvayo.dev">sip:user3@home2.jagarvayo.dev</a>>;tag=6661<br>
To: <<a href="mailto:sip:user4@home2.jagarvayo.dev">sip:user4@home2.jagarvayo.dev</a>><br>
CSeq: 1 CANCEL<br>
Max-Forwards: 70<br>
Content-Length: 0<br>
<br>
<br>
This is the CANCEL message sent by openser (Frame #20), to cancel the invite in frame #5<br>
<br>
Frame 20 (451 bytes on wire, 451 bytes captured)<br>
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)<br>
Internet Protocol, Src: <a href="http://10.161.14.110">10.161.14.110</a> (<a href="http://10.161.14.110">10.161.14.110</a>), Dst: <a href="http://10.161.14.59">10.161.14.59</a> (<a href="http://10.161.14.59">10.161.14.59
</a>)<br>
User Datagram Protocol, Src Port: 7000 (7000), Dst Port: 5060 (5060)<br>
Session Initiation Protocol<br>
Request-Line: CANCEL <a href="mailto:sip:user4@home2.jagarvayo.dev">sip:user4@home2.jagarvayo.dev</a> SIP/2.0<br>
Message Header<br>
Via: SIP/2.0/UDP
<a href="http://10.161.14.110:7000">10.161.14.110:7000</a>;branch=z9hG4bK5ead.24bd76c541a061667969156e698855df.0<br>
Via: SIP/2.0/UDP
<a href="http://10.161.14.59">10.161.14.59</a>;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002<br>
Call-ID: <a href="mailto:1-17070@10.161.14.105">1-17070@10.161.14.105</a><br>
From: <<a href="mailto:sip:user3@home2.jagarvayo.dev">sip:user3@home2.jagarvayo.dev</a>>;tag=6661<br>
To: <<a href="mailto:sip:user4@home2.jagarvayo.dev">sip:user4@home2.jagarvayo.dev</a>><br>
CSeq: 1 CANCEL<br>
Max-Forwards: 69<br>
Content-Length: 0<br>
<br>
Should not the CANCEL in frame #20 have the same branch as in the INVITE in frame #5? (As it is said in 3261)<br>
Via: SIP/2.0/UDP <a href="http://10.161.14.110:7000">10.161.14.110:7000</a>;branch=z9hG4bK5ead.85b42d6fbdf28af51be1fd77461ef605.0<br>
instead of <br>
Via: SIP/2.0/UDP <a href="http://10.161.14.110:7000">10.161.14.110:7000</a>;branch=z9hG4bK5ead.24bd76c541a061667969156e698855df.0<br>
<br>
<br>
The proxy in <a href="http://10.161.14.59">10.161.14.59</a> is answering "call leg transaction does not exists" because there is no transaction with that branch. <br>
<br>
I agree that the proxy at <a href="http://10.161.14.59">10.161.14.59</a> 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.<br>
<br>
Best Regards,<br>
Jose Antonio<br>
<br>