[OpenSER-Users] Specifying IP Address for SIP Responses

[Iñaki Baz Castillo]

El Martes, 8 de Abril de 2008, Victor Cartes escribió:
> It's just curious that RFC 3261 establishes that with no reliable transport
> protocols, if received param in via is specified, UAS should refer to that
> address to send the reply. But I try with some User Agents, and even when I
> set the received param pointing to an specific IP address, they're still
> sending the reply to the origin of the requests. With ports there is no
> such problems.

You are minunderstanding the behaviour of "received" and "rport".

"received" is not (and cannot be) set by the UAC, but just by the UAS. This 
is: 

http://tools.ietf.org/html/rfc3261#section-18.2.1
---------------------------------------------------
   When the server transport receives a request over any transport, it
   MUST examine the value of the "sent-by" parameter in the top Via
   header field value.  If the host portion of the "sent-by" parameter
   contains a domain name, or if it contains an IP address that differs
   from the packet source address, the server MUST add a "received"
   parameter to that Via header field value.  This parameter MUST
   contain the source address from which the packet was received.  This
   is to assist the server transport layer in sending the response,
   since it must be sent to the source IP address from which the request
   came.

   Consider a request received by the server transport which looks like,
   in part:

      INVITE sip:bob at Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060

   The request is received with a source IP address of 192.0.2.4.
   Before passing the request up, the transport adds a "received"
   parameter, so that the request would look like, in part:

      INVITE sip:bob at Biloxi.com SIP/2.0
      Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4
---------------------------------------------------

"rport" is the same as "reveiced" but for the IP and it's defined in 
http://tools.ietf.org/html/rfc3581. But there is a BIG difference:
The UAC MUST add "rport" (with no value) to its Via header to indicate the UAS 
that UAC supports RFC 3581. So:

1) A UAC adds "rport" (with no value) to Via of the request and sends it to 
UAS.

2) UAS recives the request and compares the IP in the sent-by field of Via 
header with the source IP of the received request. If both are different then 
UAS transport layer adds "received=SOURCE_IP" to the Via header 

3) Since the received Via includes "rport" it means that the UAC supports RFC 
3851. Then UAS transport layer compares port indicated in sent-by field with 
the real source port of the received request. If they are different then UAS 
transport layer adds the value of real source port as the value of "rport" 
parameter in Via header.

4) Now UAS can reply, passes the request to transaction layer or UAS core. 
When it generates a response this will go to "received:rport".

If "Via" didn't include "rport" (with no value) then UAS MUSN'T 
add "rport=source_port" to Via header and will send replies 
to "received":"sent-by-port" (obvisouly this will fail in NAT scenarios).


You said:
> It's just curious that RFC 3261 establishes that with no reliable transport
> protocols, if received param in via is specified, UAS should refer to that
> address to send the reply

but you are wrong, a UAC CAN NEVER add "received" to Via, it makes no sense at 
all since UAC cannot know which will be the real source IP the UAS will 
receive the request from (there can be SIP proxies, NAT routers...). A UAS 
receiving a request with "received" in Via MUST ignore it completely (or 
maybe reject the request as malformed).


Hope it helps you :)
 


-- 
Iñaki Baz Castillo