The obtained IP address is carried with the received parameter in the via header. In order to obtain port information, we also refer to this method, that is, to specify port information with the rport attribute in the via header.
When Nat is used between the client and the server, the request may create (or refresh) a binding in Nat. In order for the client to receive the response information, this binding must exist during transaction processing. Most Nat bindings have a timeout of more than 1 minute, which exceeds the duration of the non-invite transaction, therefore, the response to the non-invite transaction request only exists when the binding exists. This problem does not exist in invite transactions.
To maintain this binding, the client should resend the invite request every 20 s. This re-sending mechanism must occur after receiving a temporary response.
Of course, the time-out period of about one minute just mentioned is not definite. Sometimes it will be longer than this. At this time, the re-sending mechanism can be slower; otherwise, it can be faster. For more information about these problems, see rfc3489.
If it is a server that supports the rport mechanism, it needs to check whether the via header contains an rport parameter with no value in the received request. If yes, it needs to include the rport value in the response, which is similar to the processing of received.
To traverse symmetric Nat, the response must be sent to the same IP address and port. When a server listens for a request from multiple ports or interfaces, it must remember where the request was sent. For a stable proxy, there is no problem remembering these things during a transmission duration. However, for an unstable proxy, it does not store the status information in the request and response. To meet the requirements of this specification, it needs to encrypt the address and port information to the via header field, when the Response Information arrives, it can extract the encrypted information and put it in the response.
The rport mechanism requires the terminal to support this mechanism, so the application is limited. However, in the Application Scenario (Call Center) of the author, the main problem to be solved is that the agent can traverse in the NAT environment and send information to the server. Because the SIP Soft Phone used by the agent is developed by our company, it can be ensured that rport and received are supported.
3.2 instance
The following is an instance that sends the register information. The request's via header contains the rport parameter with no value, as shown below:
Register SIP: 124.40.120.188: 5060 Sip/2.0
The server that is sent supports the rport mechanism. After seeing the rport in the request, the NAT public IP address (124.42.4.203) and port information (15500) obtained by analyzing the UDP packet information) these attributes are sent to the client as sorted Ed and rport respectively:
Sip/2.0 200 OK
After the client obtains the response information, it knows the Internet address and port used. In the register information that is sent again regularly, the contact is changed to 124.42.4.203: 15500. For example, the new register information is changed:
Register SIP: 124.40.120.188: 5060 Sip/2.0Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
