8 Apr
2008
8 Apr
'08
11:36 p.m.
Thank you very much, Iñaki. Now I can see it clearer.
So, if anybody has any idea of how I can do what I want to do (To send a SIP
message from a transport address A:b and expect the reply from another one:
X:y), please let me know.
Thanks again,
Víctor
2008/4/8, Iñaki Baz Castillo <ibc(a)aliax.net>et>:
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@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@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
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users