Hi,
>From RFC 3581
"When the client sends the request, if the request is sent using UDP,
the client MUST be prepared to receive the response on the same IP
address and port it used to populate the source IP address and source
port of the request. For backwards compatibility, the client MUST
still be prepared to receive a response on the port indicated in the
sent-by field of the topmost Via header field value, as specified in
Section 18.1.1 of SIP "
While creating a binding, NAT will use the source UDP port
It would not use the sent-by field.
So UA should listen to the source UDP port and the port specified
in the Sent-by field.
Regards,
Thangarajan.
IMPORTANT: HUGHES SOFTWARE SYSTEMS LTD. (HSS) IS NOW FLEXTRONICS SOFTWARE
SYSTEMS LTD. (FSS)
[EMAIL PROTECTED]
om
Sent by: To
sip-implementors- "SIP Implementors"
[EMAIL PROTECTED] <sip-implementors@cs.columbia.edu>,
ia.edu "SIP IETF" <sip@ietf.org>
cc
05/04/05 07:59 AM Subject
Fw: [Sip-implementors] Fw: Via
header
Can someone clarify my doubt regarding this..
----- Forwarded by Udit Goyal/C/US/3Com on 05/03/2005 10:21 PM -----
Udit Goyal/C/US/3Com
05/02/2005 03:00 PM
To
Venkatesh <[EMAIL PROTECTED]>
cc
SIP Implementors <sip-implementors@cs.columbia.edu>,
[EMAIL PROTECTED]
Subject
Re: [Sip-implementors] Fw: Via header
I got your point,
but just want to know,
is there any standard way for NAT to behave when i create bindings,
because when the INVITE request having different UDP source port than the
sent-by field port arrives at NAT, it change the IP address and port of
the request and send it to proxy. While creating that binding, which port
it uses, the one present in sent-by field or the source UDP port.. because
it had to send the response back to UA usign the same binding.
If it uses sent-by field port, it will work fine othwerwise it will not
work if UAC is not listening on ephemeral UDP port..
I feel it uses the sent-by field for this purpose, I am not sure if it is
implementation specific ?
Even in given example of RFC 3581,
....
A client sends an INVITE to a proxy server which looks like, in part:
INVITE sip:[EMAIL PROTECTED] SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
This INVITE is sent with a source port of 4540 and a source IP
address of 10.1.1.1. The proxy is at 192.0.2.2 (proxy.example.com),
listening on both port 5060 and 5070. The client sends the request
to port 5060. The request passes through a NAT on the way to the
proxy, so that the source IP address appears as 192.0.2.1 and the
source port as 9988. The proxy forwards the request, but not before
appending a value to the "rport" parameter in the proxied request:.
....
.....
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
This packet matches the binding created by the initial request.
Therefore, the NAT rewrites the destination address of this packet
back to 10.1.1.1, and the destination port back to 4540. It forwards
this response to the client, which is listening for the response on
that address and port. The client properly receives the response.
Thanks,
Udit
Venkatesh <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
05/02/2005 02:05 PM
Please respond to
Venkatesh <[EMAIL PROTECTED]>
To
Udit Goyal/C/US/[EMAIL PROTECTED]
cc
[EMAIL PROTECTED], SIP Implementors
<sip-implementors@cs.columbia.edu>
Subject
Re: [Sip-implementors] Fw: Via header
It is the clients responsibility to determine if it is behind a
NAT/Firewall
before sending out the INVITE (not the Proxy based on IP/port comparison).
If the client figures it is behind a NAT/Firewall that requires symmetic
response traversal (think STUN lets you figure this out), you include the
"rport" parameter in the Via header using the procedures outlined in RFC
3581. Should the proxy that receive this message 'understand' the rport
extension, it will add the port information from which request originated
against the 'rport' header. When responses are forwarded, it will send it
to
the IP in the Via (received/maddr et al) and the port in the "rport"
value.
Venkatesh
On 5/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> But from proxy side, how will it know if firewall is there, so that it
can
> add rport parameter to that,
> to know if firewall is there, it needs to compare the IP address and
port
> in sent-by field with the source UDP port and and address,
>
> adn if it does nto match, then this means firewall is there, and it can
> add rport paramter with the port address and received parameter.
>
> My query was to determine that firewall is there, do you need both IP
> address and port to be different ??
> because in case of ephemeral port, only ports are different, IP
addresses
> are same..
>
> I am not able figure it out in RFC, if anybody can point me to that...
>
> Thanks,
> Udit
>
>
>
> *Venkatesh <[EMAIL PROTECTED]>*
> Sent by: [EMAIL PROTECTED]
>
> 05/02/2005 12:50 PM Please respond to
> Venkatesh <[EMAIL PROTECTED]>
>
> To
> Udit Goyal/C/US/[EMAIL PROTECTED] cc
> SIP Implementors <sip-implementors@cs.columbia.edu>,
> [EMAIL PROTECTED]
> Subject
> Re: [Sip-implementors] Fw: Via header
>
>
>
>
>
> I dont believe that is true. You can use an ephermel port while sending
> messages on UDP and can expect responses to arrive on the default
> port/port
> on which you are listening. You only need to listen on the default
ports.
> The above holds true
> * as long as you dont include an "rport" parameter (that tells the proxy
> to
> record the port on which you sent the request for response routing).
> * specify a port number other than the default port where you want your
> response sent.
> Responses are sent to the IP address/port in the Via header to the
default
> port (so for UDP, responses will be sent to 5060).
>
> Venkatesh
>
> On 5/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Yaah even I perceive the same behaviour from the RFC pint of view.
> >
> > So basically it boils down to either use the same socket for sending
and
> > listening i.e. 5060 port
> >
> > becoz if you are using ephemeral UDP port, then you have to listen for
> > reponses on same port, which is not what an applciation desired for
the
> > usage of ephemeral port.. because you can use multiple socket for
> sendign
> > the request and hence creating multiple ephemeral port which server
> would
> > not like to listen to..
> >
> > Cant we have some paramter in Via header, may be "sender-port" which
> > application set it to ephemeral port,
> > so that if proxy receives this request, it checks if "sender-port" is
> > present, it matches it with the UDP source port for firewall related
> > checks,
> > otherwise it checks with the sent-by filed.
> >
> > For sending responses, behaviour can be same as it is now..
> >
> > Regards,
> > Udit
> >
> > [EMAIL PROTECTED]
> > Sent by: [EMAIL PROTECTED]
> > 05/02/2005 03:09 AM
> >
> > To
> > Udit Goyal/C/US/[EMAIL PROTECTED]
> > cc
> > [EMAIL PROTECTED], SIP Implementors
> > <sip-implementors@cs.columbia.edu>
> > Subject
> > Re: [Sip-implementors] Fw: Via header
> >
> >
> > Udit,
> > I was waiting for someone more savvy than me to answer this one but I
> > will just have to dissapoint. I had a read of relevant section in 3261
> and
> > 3263.
> >
> > If the UAC populated the sent-by field with IP address and not a port
> > that this will result in the UAS processing this to use the default
port
> > for the transport - so for your example over UDP = 5060. The UAC could
> > have
> > included the ephemeral port in the sent-by field and regardless - yes,
> it
> > needs to listen on it.
> >
> > I hope the above is accurate, Wayne.
> >
> > Query from Udit:
> > ****************************************
> >
> > Can anybody please comment on this query..
> > ----- Forwarded by Udit Goyal/C/US/3Com on 05/01/2005 10:05 PM -----
> >
> > Udit Goyal/C/US/3Com
> > 04/28/2005 12:15 PM
> >
> > To
> > SIP Implementors, SIP IETF
> > cc
> >
> > Subject
> > Via header
> >
> > Hi,
> >
> > Conside a case where UAC uses different UDP sockets for listening and
> > sending SIP requests,
> > i.e it is listening on port 5060, but when it sends request, it uses
> > ephemeral UDP port.
> >
> > When this UAC sends INVITE request, it will contain Via header
> containing
> > the IP address and port number 5060 in sent-by field
> > But the UDP source port number will be different (IP address will be
> same)
> > as it had used UDP ephemeral port for sending that request.
> >
> > Now when proxy receives this request, it will check for IP address,
> since
> > it is same it will not add "received" parameter. However, port numbers
> are
> > different, should it add "rport" parameter ?? but this is not case of
> > firewall..
> > or proxy only check for port when the IP addresses are different ??
> >
> > Also, it seems that is it necessary for UA to listen on the same
socket
> > from which requests sent ??
> >
> > Regards,
> > Udit
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> > **********************************************************************
> > Any personal or sensitive information contained in this email and
> > attachments must be handled in accordance with the Victorian
Information
> > Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
> > (Commonwealth), as applicable.
> >
> > This email, including all attachments, is confidential. If you are not
> > the
> > intended recipient, you must not disclose, distribute, copy or use the
> > information contained in this email or attachments. Any
confidentiality
> > or
> > privilege is not waived or lost because this email has been sent to
you
> in
> > error. If you have received it in error, please let us know by reply
> > email, delete it from your system and destroy any copies.
> > **********************************************************************
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > _______________________________________________
> > Sip-implementors mailing list
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@cs.columbia.edu
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
*********************** FSS-Private ***********************
"DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
(HSS) and is intended solely for the use of the individual to whom it is
addressed. It may contain privileged or confidential information and
should not be circulated or used for any purpose other than for what it is
intended. If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient, you are
notified that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. HSS accepts no responsibility for
loss or damage arising from the use of the information transmitted by this
email including damage from virus."
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
