Yup, you guess it right, I’m talking about “received” and “rport” parameter in the Via header.
As we’ve already known, callee send responses back to caller by determining the information in the Via header, which is created by the caller, when composing the initial requests, e.g: INVITE.
This manner is standard, and defined in rfc3261, also works in the lab architechture. But in real life, when most of the endpoints lie behind a NAT, they would usually identify themselve with their private adresses, which are not usable in above standard compliment.
For example, my linphone advertises itself in the Via header it creates, which contains its private identifies in my local network,
Via: SIP/2.0/UDP 192.168.X.X:5060;branch=z9hG4bK992054588
by requesting a call to a public server outside of my network, that URI is absolutely not reachable by the server. Hence, responses never traverse back to the caller properly.
You see the problem? Great, then we go to the solutions.
“received” parameter
“received” is a standard parameter in the Via header, which contains the actual source address from which the packet was received.
“received” parameter is generated if the IP in Via header differs from the packet source address.
“rport” parameter
“rport” aka response-port is actually an analogous to the “received” parameter, except “rport” contains a port, not an IP address, defined in rfc3581.
When a UAC generates a request, it may contain an empty “rport” parameter in the Via header.
When a UAS receives a request, it examines the topmost Via header for checking the existence of the “rport” parameter with no value, if there is one, it MUST set the value of the parameter to the source port of the request.
Presence of “rport” parameter also overwrite the rule for generating “received” parameter: UAS must insert a “received” parameter containing the source IP address that the request came from, even if it is identical to the value specified in Via header.
The theory is long enough? huh? No it’s not, but taking a real example is always the better way.
Now my linphone is smarter, support rfc3581, adding an empty “rport” parameter to its Via header before sending
INVITE sip:callee@100.0.0.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.X.X:5060;branch=z9hG4bK992054588;rport;
assume my public source ip is 100.0.0.1, the server which also support rfc3581 adds “rport” and “received” parameter to the response, 12345 is the source port my NAT device use to create connection to the server
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.X.X:5060;branch=z9hG4bK992054588;rport=12345;received=100.0.0.1
The server in this case does not send responses back to URI in Via header (192.168.X.X:5060), but to what presences in “rport” and “received” parameter, my external address and external port (100.0.0.1:12345). My NAT device, which handling NAT binding, would transmit responses back to my linphone properly. It is “sent back to where it came from!”.
So far so good? Greate, to the next part!
.
.
.
.
.
Nope, there’s no next part, that’s all for today! Roll out!
Reference:
thanhloi2603 