On 24.03.20 18:11, Ben Kaufman wrote: > I may be misinterpreting this, but RFC3261 section 18.2.2 ( Sending Responses > ): > > - The server transport uses the value of the top Via header field in > - order to determine where to send a response. It MUST follow the > - following process: > - > - o If the "sent-protocol" is a reliable transport protocol such as > - TCP or SCTP, or TLS over those, the response MUST be sent using > - the existing connection to the source of the original request > - that created the transaction, if that connection is still open. > - This requires the server transport to maintain an association > - between server transactions and transport connections. If that > - connection is no longer open, the server SHOULD open a > - connection to the IP address in the "received" parameter, if > - present, using the port in the "sent-by" value, or the default > - port for that transport, if no port is specified. If that > - connection attempt fails, the server SHOULD use the procedures > - in [4] for servers in order to determine the IP address and > - port to open the connection and send the response to. > > > The message is constructed by the application, and the TCP source port is > determined afterwards, so there's no way that the application can know what > that port will be ahead of time.
I do not get why the local port on client system (or the source port of the tcp connection from server point of view) cannot be figured out before constructing the SIP message. As I said in the previous email, the app can connect, learn the local port then construct the message and then send it over the connection. The port is allocated at connect time, not when sending first data over the connection. The telephone app on macos does it, here is the relevant part of a register generated by it: 2020/03/24 22:10:46.857098 192.168.188.20:61851 -> asipto.lab:5060 REGISTER sip:asipto.lab SIP/2.0 Via: SIP/2.0/TCP 192.168.188.20:61851;rport;branch=z9hG4bKPjZO5u8nv3.APD7kvptujo-1wMF0KCFfxw;alias Route: <sip:asipto.lab;transport=tcp;lr> Max-Forwards: 70 From: "dcmtest00" <sip:[email protected]>;tag=Lsnew1BlAcXdVJ9C9JZK57hKAvS6X11s To: "dcmtest00" <sip:[email protected]> Call-ID: 8HyZKCb1xJvY8Mh9wI21-w8TXBQbBKsX CSeq: 40327 REGISTER User-Agent: Telephone 1.4 Supported: outbound, path Contact: "dcmtest00" <sip:[email protected]:61851;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000871a7549>" Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 The port in the SIP message is the source port of the IP packet. > When using TCP, it should be expected that message source port will be > different than the port indicated in the Via. From my experience, in most of the cases it is the same, unless it is a natted device using or not stun. If port would be impossible to be known, then it would be no sense to just have a value there. In WebRTC/websocket, when the JS app cannot know the local IP, the specs say it can be a random string. > > With that said, there's nothing wrong here. nat_uac_test(flags) bit value > 16 is : > > * 16 - Test if the source port is different from the port in the "Via" > header > > This tests exactly what it states, so it's not a false positive. It's > probably a bad idea to use bit value 16 to check for NAT if using TCP. Kamailio has options to create aliases for tcp connections, as well as don't connect for forwarding, if the connection is expected to be open (or is known it cannot be created by the server when device is behind nat). Otherwise, from my point of view, I don't see it a bad idea to use this test to detect that a device is behind nat even for tcp/tls. Cheers, Daniel > > > > Ben Kaufman > [email protected] > > > > -----Original Message----- > From: Daniel-Constantin Mierla <[email protected]> > Sent: Tuesday, March 24, 2020 10:47 AM > To: Ben Kaufman <[email protected]>; Kamailio (SER) - Users Mailing > List <[email protected]>; Juha Heinanen <[email protected]> > Subject: Re: [SR-Users] about kamailio.cfg NAT test > > Yes, tcp is typically using ephemeral source port, in the way that is > allocated by the tcp stack/kernel, not easy to be specified by the client > app. But the client app can get the local (ephemeral) port after > connect() using getsockname() and use it to build the SIP message that is > going to be sent through the connection. I expect this is the way how (most > of the) sip phone apps do it when the port in SIP headers is matching the > source port of the connection. > > Cheers, > Daniel > > On 24.03.20 15:15, Ben Kaufman wrote: >> Shouldn't *TCP* use an ephemeral source port, and expect replies to be to >> the source port? >> >> Ben Kaufman >> >> >> -----Original Message----- >> From: sr-users <[email protected]> On Behalf Of >> Daniel-Constantin Mierla >> Sent: Tuesday, March 24, 2020 9:01 AM >> To: Kamailio (SER) - Users Mailing List <[email protected]>; >> Juha Heinanen <[email protected]> >> Subject: Re: [SR-Users] about kamailio.cfg NAT test >> >> Hello, >> >> this is the test to detect devices behind NAT that use STUN, so they >> discover properly the public IP of the NAT router, but the port allocation >> is different for STUN and SIP traffic. >> >> If you have an asymmetric signalling client, then this test is not useful -- >> actually nat traversal cannot be done for asymmetric signalling (when client >> sends from one address (ip+port) and expects traffic back to another >> address). You haven't included the contact address, but anyhow probably the >> reply is not expected on port 44717 as it is indicated in Via. The phone >> expects some natted environment, as it requested "rport" handling (send back >> the reply to the port from where the request was received). If it wanted >> asymmetric signalling, then rport is not needed. If it knew it sends and >> receives to the same port, also rport would not be needed. >> >> Maybe this is just baresip approach not to detect local port of the tcp >> connection, putting a random value in Via and setting rport parameter. >> >> You can tune the test for your specific environment/client apps, but for the >> vast majority of the cases I encountered over the years, this test is the >> best one to detect clients behind nat that are using stun. >> >> Cheers, >> Daniel >> >> On 24.03.20 13:01, Juha Heinanen wrote: >>> In kamailio/etc/kamailio.cfg NAT test is based on nat_uac_test("19"). >>> 19 includes test 16: >>> >>> 16 - Test if the source port is different from the port in the “Via” >>> header. If the “Via” header contains no port, it uses the default SIP >>> port 5060 >>> >>> Based on a couple of tests using baresip, looks like that results in >>> false positive when UA connects to SIP proxy via TCP. >>> >>> An example: >>> >>> T 2020/03/24 13:57:12.685441 192.26.134.10:38940 -> 192.26.134.1:5060 >>> [AP] #127 REGISTER sip:test.tutpro.com SIP/2.0. >>> Via: SIP/2.0/TCP 192.26.134.10:44717;branch=z9hG4bK5b6aa423104ef942;rport. >>> >>> Does someone know why test 16 is included? >>> >>> -- Juha >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> [email protected] >>> 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 (SER) - Users Mailing List >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> STATEMENT OF CONFIDENTIALITY: >> The information contained in this electronic message and any >> attachments to this message are intended for the exclusive use of the >> addressee(s) and may contain confidential or privileged information. >> If you are not the intended recipient, or the person responsible for >> delivering the e-mail to the intended recipient, be advised you have >> received this message in error and that any use, dissemination, >> forwarding, printing, or copying is strictly prohibited. Please notify >> AltiGen Communications immediately at either (888)258-4436 or via >> email to [email protected], and destroy all copies of this >> message and any attachments. > -- > Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- > www.linkedin.com/in/miconda > > STATEMENT OF CONFIDENTIALITY: > The information contained in this electronic message and any attachments > to this message are intended for the exclusive use of the addressee(s) > and may contain confidential or privileged information. If you are not > the intended recipient, or the person responsible for delivering the > e-mail to the intended recipient, be advised you have received this > message in error and that any use, dissemination, forwarding, printing, > or copying is strictly prohibited. Please notify AltiGen Communications > immediately at either (888)258-4436 or via email to > [email protected], and destroy all copies of this message and any > attachments. -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
