View Single Post
Unread 02-17-2009, 06:45 PM   #14
green
Senior Member
 
Join Date: Jul 2007
Posts: 143
Thanks: 13
Thanked 20 Times in 19 Posts
green will become famous soon enough
Default

Quote:
Originally Posted by boatman View Post
In my case I have forwarded port 5060, so my SIP port is 5060 on both sides of my NAT router.
Not exactly. You have no control on the WAN side of your NAT router.
External port will be selected by the router on it's own, basing on it's internal algorithm. It will be either the same as the private source port (port is preserved) or it will be randomly chosen (port is random).
Port forwarding simply gives you some freedom. You may use any port number in your Contact field for example; as soon as this port is forwarded the incoming request will come through, regardless of the router's dynamic NAT mapping.
You may have 5060 locally, and your router will randomize it and map to something like 12345 then proxy will see your requests coming from 12345 and not 5060 and your NAT router will allow incoming traffic on WANaddr:12345 only and not on WANaddr:5060 .
If your SIP UA is not aware of the router's behavior it may put port 5060 instead of 12345 into the Contact header for example. If this will happen you will be able to receive incoming calls only if you will configure port forwarding for 5060.

Quote:
I can think of two possible reasons why MarkosJal's SIP UA would return rport=1024. Either the device has faulty software/firmware, or there is an intervening router changing the source port number before it reaches the GF210.
There is no problem with either SIP UA or router.
SIP UA is not returning rport=1024, provider's proxy is doing that! SIP UA is only indicating it's capabilities using rport with no value.

"A client, compliant to this specification (clients include UACs and
proxies), MAY include an "rport" parameter in the top Via header
field value of requests it generates. This parameter MUST have no
value; it serves as a flag to indicate to the server that this
extension is supported and requested for the transaction."

rport= is always returned by the proxy, indicating the port number the packet really came from:

"When a server compliant to this specification (which can be a proxy
or UAS) receives a request, it examines the topmost Via header field
value. If this Via header field value contains an "rport" parameter
with no value, it MUST set the value of the parameter to the source
port of the request."

Please refer to RFC 3581 - An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

Last edited by green; 02-17-2009 at 06:56 PM.
green is offline   Reply With Quote