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.
Related
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
I am trying to build pjsip VoIP app for android.This is the following description given for property used in account configuration.
/**
* This option is used to update the transport address and the Contact
* header of REGISTER request. When this option is enabled, the library
* will keep track of the public IP address from the response of REGISTER
* request. Once it detects that the address has changed, it will
* unregister current Contact, update the Contact with transport address
* learned from Via header, and register a new Contact to the registrar.
* This will also update the public name of UDP transport if STUN is
* configured.
*
* See also contact_rewrite_method field.
*
* Default: 1 (yes)
*/
pj_bool_t allow_contact_rewrite;
Until now via address is only changed by pjsip.how exactly does this property work??i can see no differences??
This option only kick in once the pjsip client is behind some sort of NAT.
i.e.
[pjsip client / e.g. 10.0.100] -> [NAT / e.g. 1.2.3.4] -> [SIP Server / e.g. 2.3.4.5]
When PJSIP registers with the sip server with the "contact" address of 10.0.100:5060 the SIP Server will send back a response saying that it came from 1.2.3.4: (because of the NAT).
This is when the allow_contact_rewrite kicks in and unregisters the registration and re-registers it with the 1.2.3.4: contact address.
Why it does this is so that if the sip proxy server needs to contact/send request to the SIP UAS it uses the contact header address.
This feature is "assuming" many that the NAT support hole punching to keep the contact address valid over a range of time.
Another option is to setup STUN so that PJSIP can figure out this information ahead of time so that it "knows" the external ip address before it registers (although there is symmetric NAT which can make STUN useless).
All of these options are to try get a setup so that the client can be contacted through the internet from the SIP Proxy server to the pjsip client when a "event" happens (e.g. phone call).
Personally I've found none of these setups to get a contact address that is connectable by the SIP Porxy server to work at all.
The best setup when coming from the internet client that I use is to always use TCP only (no UDP). Enable rport and TCP keep-alive in pjsip. As long as the sip server respects rport and the tcp/ip connection stays alive then everything works fine (i.e. the sip proxy can send requests down the existing open TCP socket).
That just leaves the problem of media connections between the two endpoints, which you have to rely of ICE/STUN/TURN/NAT hole punching to get that going.
As i wrote in another post ("Symmetry Procedure" in NFC P2P LLCP) i'm currently trying to implement the LLCP & SNEP protocol on a PN532 chip.
The question i had in the other post was about the Symmetry Procedure as defined in LLCP which allows
to actually bypass the original Initiator / Target roles (command / response) i.e. gives each peer device
the change to send a message at any time.
If i got it right, the SNEP-protocol defines a Client / Server approach. The role is actually defined at
the LLCP-level when one device (client) sends a CONN-PDU to the peer device (server).
Afterwards the client can send NDEF-messages to the server by using a "PUT Request" as defined in SNEP.
Let's assume now, the client has sent it's NDEF message to the server and - depending on the application -
the peer device which currently acts as a server wants to send a new (not a response) NDEF message back to the
current client.
My assumption is that the current server would send a new CONN-PDU to the current client and in case this succeeds,
both both devices change their initial roles i.e. the initial client becomes now the server etc.
What happens to the initially established connection ? Will it be closed or can still exist in parallel to the new one ?
In addition (if my assumption from above is correct), is it also necessary on the NFC MAC level that the Client / Server change
mandates also a change of the Initiator / Target roles or can both devices stay in their initial (MAC) modes ?
Thanks a lot !
If i got it right, the SNEP-protocol defines a Client / Server
approach. The role is actually defined at the LLCP-level when one
device (client) sends a CONN-PDU to the peer device (server).
No, that's not how it works. The role is not defined that way. It is not obvious from the specification, but each peer usually is a client and a server at the same time.
Note that the spec section 6.1 "Functional Description" defines the following default behavior:
The default server SHALL NOT accept Get requests.
That means, that a client is in general not allowed to request NDEF messages. The client is supposed to push it's own message if available.
The usual message flow in SNEP looks like this:
Initial state: LLCP link is down. Each peer has a SNEP server registered and waiting for connections.
On LLCP connect: Each peer that wants to send a message tries to connect to the opposing SNEP server using it's own SNEP client.
On SNEP connect the SNEP server will: wait for a SNEP PUT command. It can then either accept the message or reject it:
On SNEP connect the SNEP client will: send out a PUT command along with it's NDEF data.
Once each side has transmitted it's message (if they wanted to) they just leave the SNEP connections open. There is no proper way to close this connection anyway and there is also no cost associated with it. Each client can - at any time - always send an additional PUT request if they want to. This can be useful to esablish an bidirectional data-flow over SNEP.
Android won't allow this bidirectinal data-flow because they somewhat dumbed down SNEP a bit and don't allow a second message to be sent, but they will happily accept additional messages passed to it.
I am facing a situation when my sip client sends a deregister with call ID without IP address.
Call-ID: ZbTZ3VwsZoknVtlvROGGsOO8pt0hpFi.
This message is causing looping of the 200 OK responses as the via header of the next register message from same client is changed.
The situation is as follows
Request
deregister :LanClient--->Proxy-->Server
Response
Repeat:
100 trying :Server-->Proxy--xx->LanClient
200 Ok :Server-->Proxy--xx->Lanclient
goto Repeat
When one deregister message(i.e register message with expires=0) goes to the server the Via header contains the WAN IP of our proxy rather than LAN Client IP.This causes the respones from the server to go the WAN IP than the LAN IP.
What I am curious about is about that out of multiple clients registered with the server only the problem client messages have Call-ID field without an IP address.
I know that we can have call-ID without IP address. How would having an IP or not Having an IP in call ID make a difference in my scenario...
The value of the Call-Id header is just a string, at least from the perspective of the receiver of the request.
When a client deregisters, it should use the same Call-Id that was used for registration.
I don't understand the Via header part. Obviously, consequtive REGISTER requests (and other messages as well) has different Via headers since the branch parameter is new for every transaction.
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.