y are the external transport address assigned to UA A by the NAT. Therefore, before adding its own Via header field, the proxy amends the one inserted by UA A by adding the "received" parameter, followed by the source network address observed by the proxy. The "rport" parameter is used to store the related external port: without the "rport" parameter, it would have been impossible to record the port assigned by the NAT. When the 200 OK response is sent by UA B, all the Via header fields of the request are inserted. When the proxy receives the message, the topmost Via header is removed: the proxy forwards the 200 OK response to the network address stored in the "received" parameter, using the port stored in the "rport" parameter as the target port. Without the "rport" parameter, the response would have been forwarded to the port originally placed by UA A in the Via header field. Since the NAT changed the port from 5060 to 5080, it would have been impossible to deliver the request. 12.5.2 Signaling Layer: Ensuring UA Reachability and Supporting Mid-Dialog Requests As mentioned when discussing NAT traversal-related issues, UAs must be always reachable by their SIP proxy, which is not necessarily the case when the UA is behind a NAT as the NAT binding might expire between the REG- ISTER message from the client and the first message from the proxy. The IETF Network Working Group has released an Internet draft [12] providing a solution based on a modification of the registration procedure to create a sort of "flow" between the UA and the proxy when the UA sends the REG- ISTER message. The term flow is used to indicate a bidirectional stream of UDP datagrams or a TCP connection, depending on the transport protocol adopted. The proxy later reuses this flow to send incoming SIP messages to the UA, which is in turn responsible to periodically verify that the flow is active and to re-establish it in case of failure; multiple flows might be estab- lished to ensure reachability. The Contact field of the REGISTER message exten