Subject: [Sip] Fw: [Sip-implementors] Fw: Via header

From: [email-masked]
Date: Tue, 3 May 2005 22:29:49 -0400

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-masked]>
cc
SIP Implementors <[email-masked]>, 
[email-masked]
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-masked] 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-masked]> 
Sent by: [email-masked]
05/02/2005 02:05 PM
Please respond to
Venkatesh <[email-masked]>

To
Udit Goyal/C/US/3Com@3Com
cc
[email-masked], SIP Implementors 
<[email-masked]>
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-masked] <[email-masked]> 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-masked]>*
> Sent by: [email-masked]
>
> 05/02/2005 12:50 PM   Please respond to
> Venkatesh <[email-masked]>
>
>    To
> Udit Goyal/C/US/3Com@3Com  cc
> SIP Implementors <[email-masked]>,
> [email-masked]
>  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-masked] <[email-masked]> 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-masked]
> > Sent by: [email-masked]
> > 05/02/2005 03:09 AM
> >
> > To
> > Udit Goyal/C/US/3Com@3Com
> > cc
> > [email-masked], SIP Implementors
> > <[email-masked]>
> > 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
> > [email-masked]
> > 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
> > [email-masked]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> > _______________________________________________
> > Sip-implementors mailing list
> > [email-masked]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email-masked]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip