2 Feb
2006
2 Feb
'06
5:44 p.m.
You are right, I missed the branch value. I will investigate further, at
least the initial INVITE transaction is matched, since the R-URI is
restored. The problem should be in branch id generation.
Cheers,
Daniel
On 02/02/06 15:54, Jose Antonio Garvayo wrote:
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 <http://10.161.14.59>
(10.161.14.59 <http://10.161.14.59>), Dst: 10.161.14.110
<http://10.161.14.110> (10.161.14.110 <http://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
<mailto:sip:user4@home2.jagarvayo.dev> SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.161.14.59
<http://10.161.14.59>;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002,SIP/2.0/UDP
10.161.14.59
<http://10.161.14.59>;branch=z9hG4bKdbe6e7de6d54b4e9ab0b8e1dc4a09cb3;XXXIT_002,SIP/2.0/UDP
10.161.14.59
<http://10.161.14.59>;branch=z9hG4bKbee4d2140af14727cd281a783633a8f
From: <sip:user3@home2.jagarvayo.dev
<mailto:sip:user3@home2.jagarvayo.dev>>;tag=6661
To: <sip:user4@home2.jagarvayo.dev
<mailto:sip:user4@home2.jagarvayo.dev>>
Supported: 100rel
Call-ID: 1-17070(a)10.161.14.105 <mailto: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 <http://10.161.14.110>
(10.161.14.110 <http://10.161.14.110>), Dst: 10.161.14.59
<http://10.161.14.59> (10.161.14.59 <http://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
<mailto:sip:user4@home2.jagarvayo.dev> SIP/2.0
Message Header
Record-Route: <sip:10.161.14.110:7000
<http://10.161.14.110:7000>;ftag=6661;lr>
Via: SIP/2.0/UDP 10.161.14.110:7000
<http://10.161.14.110:7000>;branch=z9hG4bK5ead.85b42d6fbdf28af51be1fd77461ef605.0
Via: SIP/2.0/UDP 10.161.14.59
<http://10.161.14.59>;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002,SIP/2.0/UDP
10.161.14.59
<http://10.161.14.59>;branch=z9hG4bKdbe6e7de6d54b4e9ab0b8e1dc4a09cb3;XXXIT_002,SIP/2.0/UDP
10.161.14.59
<http://10.161.14.59>;branch=z9hG4bKbee4d2140af14727cd281a783633a8f
From: <sip:user3@home2.jagarvayo.dev
<mailto:sip:user3@home2.jagarvayo.dev>>;tag=6661
To: <sip:user4@home2.jagarvayo.dev
<mailto:sip:user4@home2.jagarvayo.dev>>
Supported: 100rel
Call-ID: 1-17070(a)10.161.14.105 <mailto: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 <http://10.161.14.59>
(10.161.14.59 <http://10.161.14.59>), Dst: 10.161.14.110
<http://10.161.14.110> (10.161.14.110 <http://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
<http://10.161.14.105:6030> SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.161.14.59
<http://10.161.14.59>;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002
Call-ID: 1-17070(a)10.161.14.105 <mailto:1-17070@10.161.14.105>
From: <sip:user3@home2.jagarvayo.dev
<mailto:sip:user3@home2.jagarvayo.dev>>;tag=6661
To: <sip:user4@home2.jagarvayo.dev
<mailto: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 <http://10.161.14.110>
(10.161.14.110 <http://10.161.14.110>), Dst: 10.161.14.59
<http://10.161.14.59> (10.161.14.59 <http://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
<mailto:sip:user4@home2.jagarvayo.dev> SIP/2.0
Message Header
Via: SIP/2.0/UDP 10.161.14.110:7000
<http://10.161.14.110:7000>;branch=z9hG4bK5ead.24bd76c541a061667969156e698855df.0
Via: SIP/2.0/UDP 10.161.14.59
<http://10.161.14.59>;branch=z9hG4bK2c42bc6a078c550314f3b9c31ddcf05d;XXXST_002
Call-ID: 1-17070(a)10.161.14.105 <mailto:1-17070@10.161.14.105>
From: <sip:user3@home2.jagarvayo.dev
<mailto:sip:user3@home2.jagarvayo.dev>>;tag=6661
To: <sip:user4@home2.jagarvayo.dev
<mailto: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
<http://10.161.14.110:7000>;branch=z9hG4bK5ead.85b42d6fbdf28af51be1fd77461ef605.0
instead of
Via: SIP/2.0/UDP 10.161.14.110:7000
<http://10.161.14.110:7000>;branch=z9hG4bK5ead.24bd76c541a061667969156e698855df.0
The proxy in 10.161.14.59 <http://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 <http://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