Hello to all,
About SIP/UDP: Is there any way to specify the IP address for SIP responses, in a similar fashion as port specified on top most Via HF?
Thanks in advance,
Víctor
Hi Victor,
Not sure I got your question correctly, but you mean like something like "received" via param used to route back the replies?
Regards, Bogdan
Victor Cartes wrote:
Hello to all,
About SIP/UDP: Is there any way to specify the IP address for SIP responses, in a similar fashion as port specified on top most Via HF?
Thanks in advance,
Víctor
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Monday 07 April 2008 14:03:39 Victor Cartes escribió:
Hello to all,
About SIP/UDP: Is there any way to specify the IP address for SIP responses, in a similar fashion as port specified on top most Via HF?
RFC 3261: http://tools.ietf.org/html/rfc3261#section-18.2.1
18.2.1 Receiving Requests
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
This means that ANY UAS or proxy (as OpenSer) must add "received" parameter to the top mos VIA header in case the source IP is not the same as the indicated in sent-by field fo top Via header. This is in UPD or TCP. And this is already done by OpenSer (automatically).
Regards.
Thanks, Iñaki. But It is not what I really need.
I need to send to an UAS a SIP Request, like OPTIONS, and tell it to send the reply to a different transport address (IP Addr + Port) than the source address of the request.
This is, basically, in order to perform NAT discovering and typing from the server.
Thanks in advance,
Víctor
2008/4/7, Iñaki Baz Castillo ibc@in.ilimit.es:
El Monday 07 April 2008 14:03:39 Victor Cartes escribió:
Hello to all,
About SIP/UDP: Is there any way to specify the IP address for SIP responses, in a similar fashion as port specified on top most Via HF?
RFC 3261: http://tools.ietf.org/html/rfc3261#section-18.2.1
18.2.1 Receiving Requests
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:5060The 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.4This means that ANY UAS or proxy (as OpenSer) must add "received" parameter to the top mos VIA header in case the source IP is not the same as the indicated in sent-by field fo top Via header. This is in UPD or TCP. And this is already done by OpenSer (automatically).
Regards.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Monday 07 April 2008 23:52:08 Victor Cartes escribió:
Thanks, Iñaki. But It is not what I really need.
I need to send to an UAS a SIP Request, like OPTIONS, and tell it to send the reply to a different transport address (IP Addr + Port) than the source address of the request.
That is not possible at all, a UAS decides where to send the reply based on the "received" and "rport" values (if UAC indicated it) that the UAS transport layer has set when receiving the request.
This is, basically, in order to perform NAT discovering and typing from the server.
Is not enought to analize NAT during clients REGISTER? why you need it?
Regards.
I can detect NAT during clients REGISTER, but not the type of nat (the mapping reutilization method it uses). That's why I tried to do that: to send a request from an transport address and receive it from another, so I can check the source transport address to figure out if NAT is re-using the same mapping.
Thanks, Iñaki.
2008/4/8, Iñaki Baz Castillo ibc@in.ilimit.es:
El Monday 07 April 2008 23:52:08 Victor Cartes escribió:
Thanks, Iñaki. But It is not what I really need.
I need to send to an UAS a SIP Request, like OPTIONS, and tell it to
send
the reply to a different transport address (IP Addr + Port) than the
source
address of the request.
That is not possible at all, a UAS decides where to send the reply based on the "received" and "rport" values (if UAC indicated it) that the UAS transport layer has set when receiving the request.
This is, basically, in order to perform NAT discovering and typing from
the
server.
Is not enought to analize NAT during clients REGISTER? why you need it?
Regards.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
I can detect NAT during clients REGISTER, but not the type of nat (the mapping reutilization method it uses). That's why I tried to do that: to send a request from an transport address and receive it from another, so I can check the source transport address to figure out if NAT is re-using the same mapping.
Thanks for your help, Iñaki.
2008/4/8, Iñaki Baz Castillo ibc@in.ilimit.es:
El Monday 07 April 2008 23:52:08 Victor Cartes escribió:
Thanks, Iñaki. But It is not what I really need.
I need to send to an UAS a SIP Request, like OPTIONS, and tell it to
send
the reply to a different transport address (IP Addr + Port) than the
source
address of the request.
That is not possible at all, a UAS decides where to send the reply based on the "received" and "rport" values (if UAC indicated it) that the UAS transport layer has set when receiving the request.
This is, basically, in order to perform NAT discovering and typing from
the
server.
Is not enought to analize NAT during clients REGISTER? why you need it?
Regards.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Tuesday 08 April 2008 14:14:08 Victor Cartes escribió:
I can detect NAT during clients REGISTER, but not the type of nat (the mapping reutilization method it uses). That's why I tried to do that: to send a request from an transport address and receive it from another, so I can check the source transport address to figure out if NAT is re-using the same mapping.
Ok, but as I said it's not possible in SIP to request that a reply goes to a different address:port than the indicated in received:rport of Via header. It's the UAS who decides it based on the request Via and source ip:port from where it has received the request.
You'll need to think in other way :(
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.
Greetings,
Víctor
2008/4/8, Iñaki Baz Castillo ibc@in.ilimit.es:
El Tuesday 08 April 2008 14:14:08 Victor Cartes escribió:
I can detect NAT during clients REGISTER, but not the type of nat (the mapping reutilization method it uses). That's why I tried to do that: to send a request from an transport address and receive it from another, so
I
can check the source transport address to figure out if NAT is re-using
the
same mapping.
Ok, but as I said it's not possible in SIP to request that a reply goes to a different address:port than the indicated in received:rport of Via header. It's the UAS who decides it based on the request Via and source ip:port from where it has received the request.
You'll need to think in other way :(
--
Iñaki Baz Castillo ibc@in.ilimit.es
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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 :)
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 ibc@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@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060The 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:
- A UAC adds "rport" (with no value) to Via of the request and sends it
to UAS.
- 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
- 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.
- 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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
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@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@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060The 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:
- A UAC adds "rport" (with no value) to Via of the request and sends it
to UAS.
- 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
- 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.
- 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@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Bogdan-Andrei Iancu -
Iñaki Baz Castillo -
Iñaki Baz Castillo -
Victor Cartes -
Victor Cartes