[OpenSER-Users] Specifying IP Address for SIP Responses
Victor Cartes
ietf.sip at tivatechnologies.com
Tue Apr 8 22:36:22 CEST 2008
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 at aliax.net>:
>
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20080408/82fb3532/attachment.htm>
More information about the sr-users
mailing list