[sip-comm-dev] Question about NAT and STUN (sorry, again)


#1

Hi Eric,

I think SIP Servlets containers could (and should) support this.
This API allows you to get the remote address on which a message has been
received :
http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()
I guess this method could give you the public IP adress from which the
message was received.

Then the application would have to populate the received and rport params of
the topmost Via Header so that for the response routing, the response goes
to the public IP Address.

For subsequent requests sent by the application hosted on the Sip Servlet
container, however this might prove a bit more complicated but ultimately
the application should have a way to tell the container where it wants it to
route the request really - I guess this could be achieved through some
vendor params on the Request URI or some extra API on SipServletRequest
interface that would be integrated in a next rev of the spec to specify the
outbound destination ip address and port. wdyt ?

Feedback from anybody is welcome here. NAT is a PITA, I second the IPv6 move
as well Ranga :slight_smile:

Jean

Hi Emil

Thanks for the clarification. So STUN is only used (if enabled) to set the

IP address in the SDP then.

I think it is a problem with all SIP servers implemented on SIP servlet

containers because the SIP servlet API does not really support this
non-standard behavior.

When you say 'most servers would forward requests to the address:port pair

that a client is registered on anyway' are you referring to specific SIP
server software (e.g. asterisk, SERS), or public SIP services?

Can you provide an example that works with SIP communicator? I am thinking

I can front my server with one of these and work around the problem.

···

Thanks Eric


#2

Hi Eric,

I think SIP Servlets containers could (and should) support this.
This API allows you to get the remote address on which a message has been
received :

http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()<http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()>
I guess this method could give you the public IP adress from which the
message was received.

Jean,

I don't think that was the issue at hand though. The issue is whether or not
using public addressing for call setup is the right thing to do.

I think the answer is - not in this case. Phones should ALWAYS be configured
with private addressing. IMHO even ICE should not be implemented on the
phone.

Also, much as we hate them NATs are not going away even in IPV6. They are
viewed as a form of "security".

Regards

Ranga

···

On Thu, Sep 17, 2009 at 5:13 AM, Jean Deruelle <jean.deruelle@gmail.com>wrote:

Then the application would have to populate the received and rport params
of the topmost Via Header so that for the response routing, the response
goes to the public IP Address.

For subsequent requests sent by the application hosted on the Sip Servlet
container, however this might prove a bit more complicated but ultimately
the application should have a way to tell the container where it wants it to
route the request really - I guess this could be achieved through some
vendor params on the Request URI or some extra API on SipServletRequest
interface that would be integrated in a next rev of the spec to specify the
outbound destination ip address and port. wdyt ?

Feedback from anybody is welcome here. NAT is a PITA, I second the IPv6
move as well Ranga :slight_smile:

Jean

> Hi Emil
>
>
> Thanks for the clarification. So STUN is only used (if enabled) to set
the IP address in the SDP then.
> I think it is a problem with all SIP servers implemented on SIP servlet
containers because the SIP servlet API does not really support this
non-standard behavior.
> When you say 'most servers would forward requests to the address:port
pair that a client is registered on anyway' are you referring to specific
SIP server software (e.g. asterisk, SERS), or public SIP services?
> Can you provide an example that works with SIP communicator? I am
thinking I can front my server with one of these and work around the
problem.
> Thanks Eric

--
M. Ranganathan


#3

Hi Jean

SIP servlet containers should already be sending responses to whence
the requests came, without any application involvement. This is
behavior specified in RFC3261.

The problem is as you said, if UA sends INVITE with private address in
Contact header, and an dialog is established. Then when container
sends a mid-dialog request it will send it to the private address in
Contact header. There is no way for the app to specify a different
behavior.

I sure hope more 'homely' servers will be built using SIP servlet
standard instead of proprietary asterisk. To that end I think all SIP
servlet container developers should think about how to enhance the
spec in this regard - subject for a different mailing list(s) I guess.

Thanks
Eric

···

On 9/17/09, Jean Deruelle <jean.deruelle@gmail.com> wrote:

Hi Eric,

I think SIP Servlets containers could (and should) support this.
This API allows you to get the remote address on which a message has been
received :
http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()
I guess this method could give you the public IP adress from which the
message was received.

Then the application would have to populate the received and rport params of
the topmost Via Header so that for the response routing, the response goes
to the public IP Address.

For subsequent requests sent by the application hosted on the Sip Servlet
container, however this might prove a bit more complicated but ultimately
the application should have a way to tell the container where it wants it to
route the request really - I guess this could be achieved through some
vendor params on the Request URI or some extra API on SipServletRequest
interface that would be integrated in a next rev of the spec to specify the
outbound destination ip address and port. wdyt ?

Feedback from anybody is welcome here. NAT is a PITA, I second the IPv6 move
as well Ranga :slight_smile:

Jean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Indeed that was just note to Eric that for Phones that only private
addressing for call setup, it would good that Sip Servlets container still
has the means to contact the public IP Address

···

On Thu, Sep 17, 2009 at 5:45 PM, M. Ranganathan <mranga@gmail.com> wrote:

On Thu, Sep 17, 2009 at 5:13 AM, Jean Deruelle <jean.deruelle@gmail.com>wrote:

Hi Eric,

I think SIP Servlets containers could (and should) support this.
This API allows you to get the remote address on which a message has been
received :

http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()<http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()>
I guess this method could give you the public IP adress from which the
message was received.

Jean,

I don't think that was the issue at hand though. The issue is whether or
not using public addressing for call setup is the right thing to do.

I think the answer is - not in this case. Phones should ALWAYS be
configured with private addressing. IMHO even ICE should not be implemented
on the phone.

Also, much as we hate them NATs are not going away even in IPV6. They are
viewed as a form of "security".

Regards

Ranga

Then the application would have to populate the received and rport params
of the topmost Via Header so that for the response routing, the response
goes to the public IP Address.

For subsequent requests sent by the application hosted on the Sip Servlet
container, however this might prove a bit more complicated but ultimately
the application should have a way to tell the container where it wants it to
route the request really - I guess this could be achieved through some
vendor params on the Request URI or some extra API on SipServletRequest
interface that would be integrated in a next rev of the spec to specify the
outbound destination ip address and port. wdyt ?

Feedback from anybody is welcome here. NAT is a PITA, I second the IPv6
move as well Ranga :slight_smile:

Jean

> Hi Emil
>
>
> Thanks for the clarification. So STUN is only used (if enabled) to set
the IP address in the SDP then.
> I think it is a problem with all SIP servers implemented on SIP servlet
containers because the SIP servlet API does not really support this
non-standard behavior.
> When you say 'most servers would forward requests to the address:port
pair that a client is registered on anyway' are you referring to specific
SIP server software (e.g. asterisk, SERS), or public SIP services?
> Can you provide an example that works with SIP communicator? I am
thinking I can front my server with one of these and work around the
problem.
> Thanks Eric

--
M. Ranganathan


#5

Hi Eric,
See inline

Hi Jean

SIP servlet containers should already be sending responses to whence
the requests came, without any application involvement. This is
behavior specified in RFC3261.

This is true only for TCP, STCP or TLS not for UDP, for this one it has to
use the received param of the Via Header if present.
See the last 2 bullet points in 18.2.2 Sending Responses of RFC 3261.

The problem is as you said, if UA sends INVITE with private address in
Contact header, and an dialog is established. Then when container
sends a mid-dialog request it will send it to the private address in
Contact header. There is no way for the app to specify a different
behavior.

I sure hope more 'homely' servers will be built using SIP servlet
standard instead of proprietary asterisk. To that end I think all SIP
servlet container developers should think about how to enhance the
spec in this regard - subject for a different mailing list(s) I guess.

Let's move this to Sip Servlets google group then ? but not sure it is very
active still.
Thanks
Jean

···

On Fri, Sep 18, 2009 at 1:09 PM, Eric Cheung <eric.sh.cheung@gmail.com>wrote:

Thanks
Eric

On 9/17/09, Jean Deruelle <jean.deruelle@gmail.com> wrote:
> Hi Eric,
>
> I think SIP Servlets containers could (and should) support this.
> This API allows you to get the remote address on which a message has been
> received :
>
http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()
> I guess this method could give you the public IP adress from which the
> message was received.
>
> Then the application would have to populate the received and rport params
of
> the topmost Via Header so that for the response routing, the response
goes
> to the public IP Address.
>
> For subsequent requests sent by the application hosted on the Sip Servlet
> container, however this might prove a bit more complicated but ultimately
> the application should have a way to tell the container where it wants it
to
> route the request really - I guess this could be achieved through some
> vendor params on the Request URI or some extra API on SipServletRequest
> interface that would be integrated in a next rev of the spec to specify
the
> outbound destination ip address and port. wdyt ?
>
> Feedback from anybody is welcome here. NAT is a PITA, I second the IPv6
move
> as well Ranga :slight_smile:
>
> Jean
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hi Emil, Ranga and Jean

Thanks for the detailed discussion. It seems your consensus is that
softphones like sip-communicator should use private addresses in SIP
headers (I think the only header of importance here is the Contact
header, to where the server will send subsequent new or mid-dialog
requests).

Emil, you also said that this is the direction the IETF is going. Is
there an ID or RFC that describe the correct behavior of the UAs and
proxies? I wonder if the correct behavior is completely described, or
is it more like a de facto standard set by asterisk or someone.

Thanks
Eric

···

On 9/17/09, Jean Deruelle <jean.deruelle@gmail.com> wrote:

Indeed that was just note to Eric that for Phones that only private
addressing for call setup, it would good that Sip Servlets container still
has the means to contact the public IP Address
On Thu, Sep 17, 2009 at 5:45 PM, M. Ranganathan <mranga@gmail.com> wrote:

On Thu, Sep 17, 2009 at 5:13 AM, Jean Deruelle >> <jean.deruelle@gmail.com>wrote:

Hi Eric,

I think SIP Servlets containers could (and should) support this.
This API allows you to get the remote address on which a message has been
received :

http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()<http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()>
I guess this method could give you the public IP adress from which the
message was received.

Jean,

I don't think that was the issue at hand though. The issue is whether or
not using public addressing for call setup is the right thing to do.

I think the answer is - not in this case. Phones should ALWAYS be
configured with private addressing. IMHO even ICE should not be
implemented
on the phone.

Also, much as we hate them NATs are not going away even in IPV6. They are
viewed as a form of "security".

Regards

Ranga

Then the application would have to populate the received and rport params
of the topmost Via Header so that for the response routing, the response
goes to the public IP Address.

For subsequent requests sent by the application hosted on the Sip Servlet
container, however this might prove a bit more complicated but ultimately
the application should have a way to tell the container where it wants it
to
route the request really - I guess this could be achieved through some
vendor params on the Request URI or some extra API on SipServletRequest
interface that would be integrated in a next rev of the spec to specify
the
outbound destination ip address and port. wdyt ?

Feedback from anybody is welcome here. NAT is a PITA, I second the IPv6
move as well Ranga :slight_smile:

Jean

> Hi Emil
>
>
> Thanks for the clarification. So STUN is only used (if enabled) to set
the IP address in the SDP then.
> I think it is a problem with all SIP servers implemented on SIP servlet
containers because the SIP servlet API does not really support this
non-standard behavior.
> When you say 'most servers would forward requests to the address:port
pair that a client is registered on anyway' are you referring to specific
SIP server software (e.g. asterisk, SERS), or public SIP services?
> Can you provide an example that works with SIP communicator? I am
thinking I can front my server with one of these and work around the
problem.
> Thanks Eric

--
M. Ranganathan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi Ranga

Regardless of this discussion, as JAIN-SIP is used for servers too,
how about integrating STUN/ICE functionality in JAIN-SIP? This would
avoid the issue of the STUN library not able to use the same port?

Thanks
Eric

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hey Eric,

Eric Cheung wrote:

Emil, you also said that this is the direction the IETF is going. Is
there an ID or RFC that describe the correct behavior of the UAs and
proxies? I wonder if the correct behavior is completely described, or
is it more like a de facto standard set by asterisk or someone.

Both. First of all it's one of the most reliable and simplest ways of
addressing NAT traversal (a lot more so than STUN).

The specific issue is addressed by the SIP OUTBOUND specification

http://tools.ietf.org/html/draft-ietf-sip-outbound

Note that SIP OUTBOUND is not limited to simply keeping your private
address in the contact header and a defines a number of new semantics.

Hope this helps,
Emil

···

Thanks
Eric

On 9/17/09, Jean Deruelle <jean.deruelle@gmail.com> wrote:

Indeed that was just note to Eric that for Phones that only private
addressing for call setup, it would good that Sip Servlets container still
has the means to contact the public IP Address
On Thu, Sep 17, 2009 at 5:45 PM, M. Ranganathan <mranga@gmail.com> wrote:

On Thu, Sep 17, 2009 at 5:13 AM, Jean Deruelle >>> <jean.deruelle@gmail.com>wrote:

Hi Eric,

I think SIP Servlets containers could (and should) support this.
This API allows you to get the remote address on which a message has been
received :

http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()<http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/jsr289/javax/servlet/sip/SipServletMessage.html#getInitialRemoteAddr()>
I guess this method could give you the public IP adress from which the
message was received.

Jean,

I don't think that was the issue at hand though. The issue is whether or
not using public addressing for call setup is the right thing to do.

I think the answer is - not in this case. Phones should ALWAYS be
configured with private addressing. IMHO even ICE should not be
implemented
on the phone.

Also, much as we hate them NATs are not going away even in IPV6. They are
viewed as a form of "security".

Regards

Ranga

Then the application would have to populate the received and rport params
of the topmost Via Header so that for the response routing, the response
goes to the public IP Address.

For subsequent requests sent by the application hosted on the Sip Servlet
container, however this might prove a bit more complicated but ultimately
the application should have a way to tell the container where it wants it
to
route the request really - I guess this could be achieved through some
vendor params on the Request URI or some extra API on SipServletRequest
interface that would be integrated in a next rev of the spec to specify
the
outbound destination ip address and port. wdyt ?

Feedback from anybody is welcome here. NAT is a PITA, I second the IPv6
move as well Ranga :slight_smile:

Jean

Hi Emil

Thanks for the clarification. So STUN is only used (if enabled) to set

the IP address in the SDP then.

I think it is a problem with all SIP servers implemented on SIP servlet

containers because the SIP servlet API does not really support this
non-standard behavior.

When you say 'most servers would forward requests to the address:port

pair that a client is registered on anyway' are you referring to specific
SIP server software (e.g. asterisk, SERS), or public SIP services?

Can you provide an example that works with SIP communicator? I am

thinking I can front my server with one of these and work around the
problem.

Thanks Eric

--
M. Ranganathan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net