Thank you very mucho, Iñaki. Now I see it clearer.<br><br>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.<br>
<br>Thanks again,<br><br>Víctor<br><br><br><div><span class="gmail_quote">2008/4/8, Iñaki Baz Castillo <<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
El Martes, 8 de Abril de 2008, Victor Cartes escribió:<br> <br>> It's just curious that RFC 3261 establishes that with no reliable transport<br> > protocols, if received param in via is specified, UAS should refer to that<br>
> address to send the reply. But I try with some User Agents, and even when I<br> > set the received param pointing to an specific IP address, they're still<br> > sending the reply to the origin of the requests. With ports there is no<br>
> such problems.<br> <br> <br>You are minunderstanding the behaviour of "received" and "rport".<br> <br> "received" is not (and cannot be) set by the UAC, but just by the UAS. This<br> is:<br>
<br><br> <a href="http://tools.ietf.org/html/rfc3261#section-18.2.1">http://tools.ietf.org/html/rfc3261#section-18.2.1</a><br> <br>---------------------------------------------------<br> <br> When the server transport receives a request over any transport, it<br>
MUST examine the value of the "sent-by" parameter in the top Via<br> header field value. If the host portion of the "sent-by" parameter<br> contains a domain name, or if it contains an IP address that differs<br>
from the packet source address, the server MUST add a "received"<br> parameter to that Via header field value. This parameter MUST<br> contain the source address from which the packet was received. This<br>
is to assist the server transport layer in sending the response,<br> since it must be sent to the source IP address from which the request<br> came.<br> <br> Consider a request received by the server transport which looks like,<br>
in part:<br> <br> INVITE sip:bob@Biloxi.com SIP/2.0<br> Via: SIP/2.0/UDP <a href="http://bobspc.biloxi.com:5060">bobspc.biloxi.com:5060</a><br> <br> The request is received with a source IP address of <a href="http://192.0.2.4">192.0.2.4</a>.<br>
Before passing the request up, the transport adds a "received"<br> parameter, so that the request would look like, in part:<br> <br> INVITE sip:bob@Biloxi.com SIP/2.0<br> Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=<a href="http://192.0.2.4">192.0.2.4</a><br>
<br>---------------------------------------------------<br> <br> "rport" is the same as "reveiced" but for the IP and it's defined in<br> <a href="http://tools.ietf.org/html/rfc3581">http://tools.ietf.org/html/rfc3581</a>. But there is a BIG difference:<br>
The UAC MUST add "rport" (with no value) to its Via header to indicate the UAS<br> that UAC supports RFC 3581. So:<br> <br> 1) A UAC adds "rport" (with no value) to Via of the request and sends it to<br>
UAS.<br> <br> 2) UAS recives the request and compares the IP in the sent-by field of Via<br> header with the source IP of the received request. If both are different then<br> UAS transport layer adds "received=SOURCE_IP" to the Via header<br>
<br> 3) Since the received Via includes "rport" it means that the UAC supports RFC<br> 3851. Then UAS transport layer compares port indicated in sent-by field with<br> the real source port of the received request. If they are different then UAS<br>
transport layer adds the value of real source port as the value of "rport"<br> parameter in Via header.<br> <br> 4) Now UAS can reply, passes the request to transaction layer or UAS core.<br> When it generates a response this will go to "received:rport".<br>
<br> If "Via" didn't include "rport" (with no value) then UAS MUSN'T<br> add "rport=source_port" to Via header and will send replies<br> to "received":"sent-by-port" (obvisouly this will fail in NAT scenarios).<br>
<br><br> <br> You said:<br> > It's just curious that RFC 3261 establishes that with no reliable transport<br> > protocols, if received param in via is specified, UAS should refer to that<br> > address to send the reply<br>
<br> <br>but you are wrong, a UAC CAN NEVER add "received" to Via, it makes no sense at<br> all since UAC cannot know which will be the real source IP the UAS will<br> receive the request from (there can be SIP proxies, NAT routers...). A UAS<br>
receiving a request with "received" in Via MUST ignore it completely (or<br> maybe reject the request as malformed).<br> <br> <br> Hope it helps you :)<br> <br> <br> <br> --<br> <br>Iñaki Baz Castillo<br> <br><br>
_______________________________________________<br> Users mailing list<br> <a href="mailto:Users@lists.openser.org">Users@lists.openser.org</a><br> <a href="http://lists.openser.org/cgi-bin/mailman/listinfo/users">http://lists.openser.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br>