[jitsi-dev] Ack request request-URI


#1

Hi all,

I am wondering if the setting of the request-URI is incorrect in the
ACK request generated by the Jitsi client. Below are 2 transactions
(one started by the INVITE and one by the ACK request). It is a normal
call setup scenario although it is through NAT onto some public facing
servers. I have removed SDP and 1xx responses for clarity.

What I see is that the INVITE has a request-URI of "
sip:shane@flowdevtest.paragon.co.nz" but the ACK uses
"sip:shane@192.168.2.226:50820". The 200 status has a Record-Route
that points to the proxy so the ACK is being sent to the Kamailio
Proxy. However the Proxy isn't able to match the request URI to an
open socket - I think this is because the request URI isn't the same as
the INVITE one.

My reading of RFC3261 is that Request-URI should be equal to the
original request ie. the INVITE request as per 17.1.1.3

"17.1.1.3 Construction of the ACK Request
    .....

   The ACK request constructed by the client transaction MUST contain
   values for the Call-ID, From, and Request-URI that are equal to the
   values of those header fields in the request passed to the transport
   by the client transaction (call this the "original request"). "

INVITE sip:shane@flowdevtest.paragon.co.nz SIP/2.0
Call-ID: fb69c56a09b2c24a9cdd4c072aa442cd@0:0:0:0:0:0:0:0
CSeq: 2 INVITE

From: "Kumar" <sip:kumar@flowdevtest.paragon.co.nz>;tag=b28b16e

Max-Forwards: 70
Contact: "Kumar"
<sip:kumar@192.168.2.220:1543;transport=tls;registering_acc=flowdevtest
_paragon_co_nz>
User-Agent: Jitsi1.0-build.3967Windows 7
Content-Type: application/sdp
Via: SIP/2.0/TLS
192.168.2.220:1543;branch=z9hG4bK-333839-01b75187c50dc4761921d101a53178
fc
Authorization: Digest
username="kumar",realm="flowdevtest.paragon.co.nz",nonce="UH9waVB/bz2y9
xJRcp9ZAiSTgADiSYCg",uri="sip:shane@flowdevtest.paragon.co.nz",response
="7c75c9e0706b0b44bb69a0ac3ccedc6b",qop=auth,cnonce="xyz",nc=00000001
Content-Length: 624

SIP/2.0 200 OK
Via: SIP/2.0/TLS
192.168.2.220:1543;received=192.168.252.254;branch=z9hG4bK-333839-01b75
187c50dc4761921d101a53178fc
Record-Route: <sip:203.171.39.53:5061;transport=tls;lr=on>
CSeq: 2 INVITE
Call-ID: fb69c56a09b2c24a9cdd4c072aa442cd@0:0:0:0:0:0:0:0

From: "Kumar" <sip:kumar@flowdevtest.paragon.co.nz>;tag=b28b16e

Contact: "Shane"
<sip:shane@192.168.2.226:50820;transport=tls;registering_acc=flowdevtes
t_paragon_co_nz>
User-Agent: Jitsi1.0-build.3967Windows 7
Content-Type: application/sdp
Content-Length: 626

ACK
sip:shane@192.168.2.226:50820;transport=tls;registering_acc=flowdevtest
_paragon_co_nz SIP/2.0
Call-ID: fb69c56a09b2c24a9cdd4c072aa442cd@0:0:0:0:0:0:0:0
CSeq: 2 ACK
Via: SIP/2.0/TLS
192.168.2.220:1543;branch=z9hG4bK-333839-26936abe5d1404be5644ebc75ac8b3
fd

From: "Kumar" <sip:kumar@flowdevtest.paragon.co.nz>;tag=b28b16e

Max-Forwards: 70
Authorization: Digest
username="kumar",realm="flowdevtest.paragon.co.nz",nonce="UH9waVB/bz2y9
xJRcp9ZAiSTgADiSYCg",uri="sip:shane@flowdevtest.paragon.co.nz",response
="7c75c9e0706b0b44bb69a0ac3ccedc6b",qop=auth,cnonce="xyz",nc=00000001
Route: <sip:203.171.39.53:5061;transport=tls;lr=on>
Contact: "Kumar"
<sip:kumar@192.168.2.220:1543;transport=tls;registering_acc=flowdevtest
_paragon_co_nz>
User-Agent: Jitsi1.0-build.3967Windows 7
Content-Length: 0

Cheers
Shane

···

To: <sip:shane@flowdevtest.paragon.co.nz>
To: <sip:shane@flowdevtest.paragon.co.nz>;tag=b2af9e99
To: "Shane" <sip:shane@flowdevtest.paragon.co.nz>;tag=b2af9e99


#2

Hey Shane,

Hi all,

I am wondering if the setting of the request-URI is incorrect in the
ACK request generated by the Jitsi client. Below are 2 transactions
(one started by the INVITE and one by the ACK request).

That's actually one transaction only. ACK requests do not start a
transaction.

It is a normal
call setup scenario although it is through NAT onto some public facing
servers. I have removed SDP and 1xx responses for clarity.

What I see is that the INVITE has a request-URI of "
sip:shane@flowdevtest.paragon.co.nz" but the ACK uses
"sip:shane@192.168.2.226:50820". The 200 status has a Record-Route
that points to the proxy so the ACK is being sent to the Kamailio
Proxy. However the Proxy isn't able to match the request URI to an
open socket - I think this is because the request URI isn't the same as
the INVITE one.

My reading of RFC3261 is that Request-URI should be equal to the
original request ie. the INVITE request as per 17.1.1.3

"17.1.1.3 Construction of the ACK Request
    .....

   The ACK request constructed by the client transaction MUST contain
   values for the Call-ID, From, and Request-URI that are equal to the
   values of those header fields in the request passed to the transport
   by the client transaction (call this the "original request"). "

The part you are quoting is about cases where you would send the ack
within the INVITE transaction which is not the case for 2xx responses.
Right that text there's a sentence saying:

  A UAC core that generates an ACK for 2xx
  MUST instead follow the rules described in Section 13.

And in Section 13.2.2.4 you have:

  The header fields of the ACK are constructed
  in the same way as for any request sent within a dialog (see Section
  12) with the exception of the CSeq and the header fields related to
  authentication.

http://tools.ietf.org/html/rfc3261#section-13.2.2.4

As an in-dialog request the ACK uses the URI from the contact header it
got in the first non-100 response from the remote party.

Hope this helps,
Emil

···

On 18.10.12, 23:42, shane.harrison@paragon.co.nz wrote:

INVITE sip:shane@flowdevtest.paragon.co.nz SIP/2.0
Call-ID: fb69c56a09b2c24a9cdd4c072aa442cd@0:0:0:0:0:0:0:0
CSeq: 2 INVITE
From: "Kumar" <sip:kumar@flowdevtest.paragon.co.nz>;tag=b28b16e
To: <sip:shane@flowdevtest.paragon.co.nz>
Max-Forwards: 70
Contact: "Kumar"
<sip:kumar@192.168.2.220:1543;transport=tls;registering_acc=flowdevtest
_paragon_co_nz>
User-Agent: Jitsi1.0-build.3967Windows 7
Content-Type: application/sdp
Via: SIP/2.0/TLS
192.168.2.220:1543;branch=z9hG4bK-333839-01b75187c50dc4761921d101a53178
fc
Authorization: Digest
username="kumar",realm="flowdevtest.paragon.co.nz",nonce="UH9waVB/bz2y9
xJRcp9ZAiSTgADiSYCg",uri="sip:shane@flowdevtest.paragon.co.nz",response
="7c75c9e0706b0b44bb69a0ac3ccedc6b",qop=auth,cnonce="xyz",nc=00000001
Content-Length: 624

SIP/2.0 200 OK
To: <sip:shane@flowdevtest.paragon.co.nz>;tag=b2af9e99
Via: SIP/2.0/TLS
192.168.2.220:1543;received=192.168.252.254;branch=z9hG4bK-333839-01b75
187c50dc4761921d101a53178fc
Record-Route: <sip:203.171.39.53:5061;transport=tls;lr=on>
CSeq: 2 INVITE
Call-ID: fb69c56a09b2c24a9cdd4c072aa442cd@0:0:0:0:0:0:0:0
From: "Kumar" <sip:kumar@flowdevtest.paragon.co.nz>;tag=b28b16e
Contact: "Shane"
<sip:shane@192.168.2.226:50820;transport=tls;registering_acc=flowdevtes
t_paragon_co_nz>
User-Agent: Jitsi1.0-build.3967Windows 7
Content-Type: application/sdp
Content-Length: 626

ACK
sip:shane@192.168.2.226:50820;transport=tls;registering_acc=flowdevtest
_paragon_co_nz SIP/2.0
Call-ID: fb69c56a09b2c24a9cdd4c072aa442cd@0:0:0:0:0:0:0:0
CSeq: 2 ACK
Via: SIP/2.0/TLS
192.168.2.220:1543;branch=z9hG4bK-333839-26936abe5d1404be5644ebc75ac8b3
fd
From: "Kumar" <sip:kumar@flowdevtest.paragon.co.nz>;tag=b28b16e
To: "Shane" <sip:shane@flowdevtest.paragon.co.nz>;tag=b2af9e99
Max-Forwards: 70
Authorization: Digest
username="kumar",realm="flowdevtest.paragon.co.nz",nonce="UH9waVB/bz2y9
xJRcp9ZAiSTgADiSYCg",uri="sip:shane@flowdevtest.paragon.co.nz",response
="7c75c9e0706b0b44bb69a0ac3ccedc6b",qop=auth,cnonce="xyz",nc=00000001
Route: <sip:203.171.39.53:5061;transport=tls;lr=on>
Contact: "Kumar"
<sip:kumar@192.168.2.220:1543;transport=tls;registering_acc=flowdevtest
_paragon_co_nz>
User-Agent: Jitsi1.0-build.3967Windows 7
Content-Length: 0

Cheers
Shane

--
https://jitsi.org