Thank you very mucho, Iñaki. Now I 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 <[EMAIL PROTECTED]>: > > 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 > [email protected] > http://lists.openser.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
