A user A wants to send TCP request to user B over ICE/TURN/STUN mechanism. If user B generates a SDP with its ICE candidates and send it to user A. Is user A must answer directly to user B without to send its SDP and ICE candidates to user B?
We only want TCP connection (no UDP).
Indeed, when user A receives SDP of user B with ICE candidates of user B. It can to initiate checks in order to know which IP of user B it can use to create a TCP connection (so send stun request to user B for each IP).
When the TCP connection is opened. USER A send request to user B and B can response to this request over TCP, no?
User B no need to check which IP of A that it can to contact because it doesn't need to send request to user A, no?
Doing P2P NAT traversal over TCP is a bit harder than UDP. But yes, it requires exchanging candidate addresses, including the public address obtained from a STUN or TURN server. And the main trick is often that both endpoints need to try connecting to each other at the same time.
Read more here: https://en.wikipedia.org/wiki/TCP_hole_punching
Related
Given a SIP dialog (INVITE, 200 OK, ACK) has been established via UDP; And a large message gets sent that requires TCP as transport.
What is the applied transport protocol after the large message has been sent for all other following (and normal sized) messages?
Does the protocol switch to TCP for all further request/responses or does it keep using the initially negotiated transport - UDP - for standard sized (NOT large) messages?
What I found (based on RFC 3261):
All SIP elements MUST implement UDP and TCP. SIP elements MAY
implement other protocols.
- from rfc3261#18
The ACK MUST be sent to the same address,
port, and transport to which the original request was sent.
- from rfc3261#18
Okay that says NOT all requests (especially ACK) are able to choose the transport independently.
Making TCP mandatory for the UA is a substantial change from RFC
2543. It has arisen out of the need to handle larger messages,
which MUST use TCP, as discussed below. Thus, even if an element
never sends large messages, it may receive one and needs to be
able to handle them.
- from rfc3261#18
During an established dialog a UAS/UAC never knows if the need for a large message arises - switching from UDP to TCP is just fine (without any RE-INVITE that changes the transport in advance to the actual request).
A 301 (Moved Permanently) or 302 (Moved Temporarily) response may
also give the same location and username that was targeted by the
initial request but specify additional transport parameters such as
a different server or multicast address to try, or a change of SIP
transport from UDP to TCP or vice versa.
- from rfc3261#8.3
not really relevant - the UAS may want to change the transport suggested by the UAC; but that is based on the reaction onto some INVITE (or RE-INVITE) only
The destination address,
port, and transport for the CANCEL MUST be identical to those used to
send the original request.
- from rfc3261#9.1
Okay CANCEL (like ACK) also must NOT independently choose the transport.
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP. If this causes a change in the transport protocol from the one
indicated in the top Via, the value in the top Via MUST be changed.
That says if the SIP dialog was established via UDP, it has to be able to receive TCP requests also.
For any port and interface
that a server listens on for UDP, it MUST listen on that same port and
interface for TCP. This is because a message may need to be sent
using TCP, rather than UDP, if it is too large. As a result, the
converse is not true. A server need not listen for UDP on a
particular address and port just because it is listening on that same
address and port for TCP. There may, of course, be other reasons why
a server needs to listen for UDP on a particular address and port.
Okay that explains how switching from UDP to TCP works seamless. - And for the other direction it is just not required, but (I understand like: it still MAY work).
Both TCP and UDP are usable at that point and the transport layer is responsible for the choice.
SIP is transport independent, both are active at the same time.
Suppose that I have to write a UDP server which should receive authentication token for each client in the first message and then receive different data after some period of time. This UDP server should obviously check whether certain client authenticated previously or not. How should I do it? Should I store "authenticated" flag for each (IP addr, port) pair? Is it ok? If so, what will happen if several clients will have the same IP address (for example, they share it from the same internet provider)?
I think you can't. You'll need to have the token in each message. Multiple requests can come from the same IP, such as a client connecting from behind a NAT.
This a rare case where you might want to use multiple UDP sockets at the server and connect() each of them to one authenticated client, so that you can only receive further messages on each one from each authenticated client. You'll have to send the first reply via hat socket,a denture client will have to be written to adjust its destination accordingly after receiving the first reply.
While making a network app I met following problem.
In this scenario there are you and multiple servers in a local network to connect to, you can choose which one. Between you and the selected server there should be a TCP connection in the end.
I found UDP broadcast to be really convenient on one side but how do I answer the broadcast (I need to send some information back)? Basicly I see two possibilites.
to make a lot TCP connections
to add an UDP sender and listener.
How would you solve this?
Add a UDP listener to the server. When it receives a UDP request, send a reply back to the sender's IP/Port, and have that reply including the server's listening TCP IP/Port. The client can then send a broadcast, wait a few seconds to collect all of the replies, present them to the user, and then make a TCP connection to the selected server.
when client sends a request to server, one entry is inserted in nat table (in router). After client received response, this entry will be deleted. Server can't send message to client if client doesn't issue request (client is in private network)
However in case of bidirectional socket, how to accomplish this issue:
1. How does server actively sends message to client ?
[updated from comments]
I want to implement server-push architechture, so I need to know more about NAT.
in RFC6314, section 5.2.1.2, it mentions that after Client_L collected its candidate list, it sends INVITE to Client_R with the list, and then both ends can start connectivity check.
I have a question is that why Client_L can send INVITE to Client_R? or why Client_R can receive those data (candidate list)? I think in this time Client_L should have no address info of Client_R. Thanks your answer in advanced.
https://www.rfc-editor.org/rfc/rfc6314#section-5.2.1
In order for clients to establish a P2P ICE session, they have to rendezvous through a reliable signaling server. The signaling server exists for clients to exchange address candidates in order for ICE negotiation to actually begin. This is typically a SIP server. Although ICE allows for almost anything to be used for exchanging addresses.
When the INVITE is sent out, it gets sent to a server that knows how to forward that message to the other client. When the remote client gets the INVITE, it responds back with a series of SIP messages - one of which is the "180 RINGING" or "200 OK" message that contains the address candidates from the client that received the INVITE.