[SR-Users] SIP INVITE

[Alex Balashov]

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.

-- 
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/