On 10/11/2011 02:45 AM, Amar Tuladhar wrote:
Hope you will help us with this issue.
In the INVITE message there is a field name CONTACT.
1.Is it possible that the ‘port’ in the CONTACT field is different from the UDP port?
What's "the UDP port"? The source port from which the INVITE request originated? If so, then yes.
2.What shall be the action in case the ports are different?
The action according to what? According to RFC 3261, the network and transport-level reachability information in the Contact URI should be used to reach that UA.
3.Is it true that the UDP port in BYE message shall be same as that of INVITE-CONTACT port?
Again, what's "the UDP port"? The destination port?
Assuming yes, your question is really a specific instantiation of a generality. A BYE is a type of request known as a sequential request. Sequential requests take place within a dialog. A dialog is created by the initial INVITE request, and torn down by either a CANCEL (if not yet established) or a BYE (if established). While the dialog is up, one or more sequential requests pertaining to it may occur, such as a reinvite or a BYE.
The request URI of sequential/in-dialog requests is set to the Contact URI of either the initial INVITE request or the final response of the UAS in the transaction that initially set up the dialog.
So in short, yes, the request URI of the BYE going toward UA A would be equal to the Contact of UA A.
4.Is there any clear reference in the RFC for treatment in this kind of situation?
Which RFC? There are many RFCs. There is no reference in 3261 to this situation, but there are other RFCs that deal with far-end NAT traversal strategies. Ignoring the network and transport-layer reachability information in SIP messages--and using the actual received source IP address and port instead--is the basis of the most common far-end (that is, server-side) NAT traversal strategy.
So yes, using received source address and port instead of what the Contact says is actually quite common when dealing with NAT'd endpoints, but it is not 3261-compliant behaviour.