[sip-comm-dev] Bind the RTP sockets to the IP address published in SIP/SDP


#1

During some tests with a systems that had a active, fairly restrictive
firewall I noticed a problem with RTP communication.

Test environment:

My system has several NICs and therefore IP addresses. The registrar
uses the IP address 172.16.97.1:5070, SC runs on the same system (using
port 5060) and registers with this registrar.

The second system connects via a LAN whose net address is 192.168.200.0/24.
The SC on this system of course also registers with the registrar at
172.16.97.1.

Problem:

During session initiation the SC on the main system uses the address of
172.16.97.1 in SIP and SDP to send the INVITE via the registrar to the
second SC. All goes well. Now the SC on the other system at 192.168.200.129
sends RTP data. Of course it sends the RTP data to 172.16.97.1:5060.
The state-full FW of this other system is now prepared to receive data
from this address.

What happens:
- The main system receives the data via the NIC address 192.168.200.1,
- the main system recognizes it also has 172.16.97.1
- it forwards the data immediately to SC UDP port 5060 and binds this port
  to 192.168.200.1 (the address of the NIC where it received the data)
- Now SC on the main system sends RTP data but the UDP packets now
  have 192.168.200.1 as sender address.

The state-full firewall of the second system blocks these packets because
the firewall does not know the sender. It expects data from 172.16.97.1
because the SC behind this FW sent data to that address.

This happens because CallSessionImpl.java uses 0.0.0.0 (wildcard) to bind
the RTP ports. This then leads to the wrong bind address.

Solution:

CallSessionImpl.java knows the IP addresses, so just use them. I've added
the following code:

        audioSessionAddress.setControlHostAddress(audioPublicAddress.getAddress());
        audioSessionAddress.setDataHostAddress(audioPublicAddress.getAddress());
and
        videoSessionAddress.setControlHostAddress(videoPublicAddress.getAddress());
        videoSessionAddress.setDataHostAddress(videoPublicAddress.getAddress());

around the lines 1998 and 2013. This forces the ports to bind on the address that
is used in SIP and SDP. This solved the problem with the statefull firewall and it
works well during other tests.

I'll check it in now.

Because it may be a critical network patch I would ask you the check if it does any
harm in other network environments (It shouldn't :slight_smile: ).

Regards,
Werner

···

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


#2

Hey there Werner,

Sounds like an annoying problem indeed, and unfortunately I am afraid
that your patch is a solution that is a bit too specific to your
environment.

No worries though, I don't think it would be that difficult to have an
easily implementable solution. Could you please send wireshark dumps so
that we could be sure of what was going on?

In the mean time here's what I think happened:

In order to handle multiple interfaces (as well as pick between
IPv6/IPv4 addresses) we always try choose a source address based on the
the destination that we will be communicating with. The selection
algorithms are implemented in the NetworkAddressService and in order to
use them one simply has to pass an "intendedDestination" parameter when
trying to retrieve a local address. The NetAddress service will then use
it to pick a local address that would work with it.

This is why the createSDPOffer() method in CallSession, which needs to
advertise a media address, takes one such intendedDestination param.

Now, when we create the INVITE request we don't really know that much
about our interlocutor. The only thing we have is their SIP uri so we
use its host part to construct the intendedDestination param.

I imagine that in your case you must have dialed something like:

wernerd@172.16.97.1

The NetworkAddressService therefore should have determined that it
should also use the 172.16.97.1 local address for that conversation.
This is the address that should have left with the SDP offer in the
INVITE. Was this the case?

When the callee gets the offer it uses the exact same algorithm to
select an address for the SDP answer only this time the intended
destination is the IP address that came with the offer. If I understood
your environment correctly then it didn't really have a choice since
that host only had one address so it simply returned it.

Concerning your patch - audioPublicAddress is the address that the
NetworkAddressService has advised us to announce to our interlocutor.
The "public" part in the name is supposed to indicate (although it
obviously doesn't indicate it well enough :wink: ) that the
NetAddressService has done everything possible to select a globally
routable address. This means that in cases where STUN is enabled
audioPublicAddress does not even belong to the local host but to a STUN
server somewhere on the net.

This was obviously not the case for you which is why the call didn't
break for the callee.

What your patch really does is that it always forces the caller to send
media using the source address that matched the host part of the
destination SIP uri and not the one that would match the address in the
SDP answer.

Still with me?

The best way to fix this would of course be to implement ICE since then
we would select addresses based on the candidates that the remote party
had sent to us. Until then I believe the easiest way you have out would
be to somehow modify your environment. Using a media proxy together with
your registrar (e.g. asterisk) should do it.

Alternately we could implement some configuration options that would
force a local media address but I have to admit that I am a bit
reluctant to do this since it would only add to the complexity of the
whole selection procedure and it is quite high already.

Am I making sense?

Cheers
Emil

Werner Dittmann wrote:

···

During some tests with a systems that had a active, fairly restrictive
firewall I noticed a problem with RTP communication.

Test environment:

My system has several NICs and therefore IP addresses. The registrar
uses the IP address 172.16.97.1:5070, SC runs on the same system (using
port 5060) and registers with this registrar.

The second system connects via a LAN whose net address is 192.168.200.0/24.
The SC on this system of course also registers with the registrar at
172.16.97.1.

Problem:

During session initiation the SC on the main system uses the address of
172.16.97.1 in SIP and SDP to send the INVITE via the registrar to the
second SC. All goes well. Now the SC on the other system at 192.168.200.129
sends RTP data. Of course it sends the RTP data to 172.16.97.1:5060.
The state-full FW of this other system is now prepared to receive data
from this address.

What happens:
- The main system receives the data via the NIC address 192.168.200.1,
- the main system recognizes it also has 172.16.97.1
- it forwards the data immediately to SC UDP port 5060 and binds this port
  to 192.168.200.1 (the address of the NIC where it received the data)
- Now SC on the main system sends RTP data but the UDP packets now
  have 192.168.200.1 as sender address.

The state-full firewall of the second system blocks these packets because
the firewall does not know the sender. It expects data from 172.16.97.1
because the SC behind this FW sent data to that address.

This happens because CallSessionImpl.java uses 0.0.0.0 (wildcard) to bind
the RTP ports. This then leads to the wrong bind address.

Solution:

CallSessionImpl.java knows the IP addresses, so just use them. I've added
the following code:

        audioSessionAddress.setControlHostAddress(audioPublicAddress.getAddress());
        audioSessionAddress.setDataHostAddress(audioPublicAddress.getAddress());
and
        videoSessionAddress.setControlHostAddress(videoPublicAddress.getAddress());
        videoSessionAddress.setDataHostAddress(videoPublicAddress.getAddress());

around the lines 1998 and 2013. This forces the ports to bind on the address that
is used in SIP and SDP. This solved the problem with the statefull firewall and it
works well during other tests.

I'll check it in now.

Because it may be a critical network patch I would ask you the check if it does any
harm in other network environments (It shouldn't :slight_smile: ).

Regards,
Werner

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

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


#3

Emil Ivov wrote:

What your patch really does is that it always forces the caller to send
media using the source address that matched the host part of the
destination SIP uri and not the one that would match the address in the
SDP answer.

... which is actually quite logical. Do you think there's a scenario
where this would be wrong?

If not then we only need take care of the stun problem which would be
quite straightforward.

Cheers
Emil

···

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


#4

Emil,

when I did the tests and thought about how to solve the problem I didn't
care about STUN :wink: . See some comments below.

Regards,
Werner

Emil Ivov schrieb:

Emil Ivov wrote:

What your patch really does is that it always forces the caller to send
media using the source address that matched the host part of the
destination SIP uri and not the one that would match the address in the
SDP answer.

Werner:
But only if STUN is not used. Otherwise audioPublicAddress and
videoPublicAddress address contain the address detected by STUN. This is because
I use these two addresses after "netAddressManager.getPublicAddressFor(...)".

My goal was to use the same address as offered in the SDP. This however, as
you said in your first post, works only without STUN.

My proposal therefore, after checking netAddressManager.getPublicAddressFor(...),
is to use netAddressManager.getLocalHost(intendedDestination) to get the
source address for media (RTP binding address).

Something like this:

...
InetAddress localHost = netAddressManager.getLocalHost(intendedDestination);

audioSessionAddress.setControlHostAddress(localhost.getAddress());
audioSessionAddress.setDataHostAddress(localhost.getAddress());

...

videoSessionAddress.setControlHostAddress(localhost.getAddress());
videoSessionAddress.setDataHostAddress(localhost.getAddress());

The above uses just retrieves the localhost address of the NIC that the system
will use for the intended destination and uses this localhost address to bind
the media ports.

IMHO this works well with and without STUN as well as in local network:

- If the request is to the local network using local IP adresses it detects
  the address of the local NIC to use for the intended address. This will be
  the same that will be filled in into SDP.

- If the request is to public IP without NAT it would refer to the IP address
  of the NIC that connects to the public IP. This will be
  the same that will be filled in into SDP.

- if the request is to public IP with NAT it would also refer to the IP
  address of the NIC that connects to the router/NAT. This will be
  different to the address filled into SDP but would not do any harm IMHO.

What do you think?

···

... which is actually quite logical. Do you think there's a scenario
where this would be wrong?

If not then we only need take care of the stun problem which would be
quite straightforward.

Cheers
Emil

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

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


#5

Hey Werner,

Werner Dittmann wrote:

Emil,

when I did the tests and thought about how to solve the problem I didn't
care about STUN :wink: .

Sometimes I also wish we could simply forget about it :wink:

My proposal therefore, after checking netAddressManager.getPublicAddressFor(...),
is to use netAddressManager.getLocalHost(intendedDestination) to get the
source address for media (RTP binding address).

Yes that would be the way to go. We simply need to figure out what would
be the best place to use it.

Something like this:

...
InetAddress localHost = netAddressManager.getLocalHost(intendedDestination);

audioSessionAddress.setControlHostAddress(localhost.getAddress());
audioSessionAddress.setDataHostAddress(localhost.getAddress());

...

videoSessionAddress.setControlHostAddress(localhost.getAddress());
videoSessionAddress.setDataHostAddress(localhost.getAddress());

The above uses just retrieves the localhost address of the NIC that the system
will use for the intended destination and uses this localhost address to bind
the media ports.

IMHO this works well with and without STUN as well as in local network:

- If the request is to the local network using local IP adresses it detects
  the address of the local NIC to use for the intended address. This will be
  the same that will be filled in into SDP.

- If the request is to public IP without NAT it would refer to the IP address
  of the NIC that connects to the public IP. This will be
  the same that will be filled in into SDP.

- if the request is to public IP with NAT it would also refer to the IP
  address of the NIC that connects to the router/NAT. This will be
  different to the address filled into SDP but would not do any harm IMHO.

What do you think?

Fine by me. The only thing is that I don't really see any need to
initialize the SessionAddress object for the ANY address and then reinit
it to a specific IP. It would probably be better to create it directly
with the IP we'd like to use.

Alternately we could also create an empty address and to all the
initialization in allocatePort(). This way it would all be in one place
and we won't need to do it twice (once for video and once for audio).

Does this sound ok? If yes, then would you commit the modification or do
you prefer me to do it?

Cheers
Emil

···

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


#6

Emil,

good idea to initialize to the correct address and not using ANY
in the first place.

Let me look where to place this - I can do this during the week. Is
this ok with you?

Regards,
Werner

Emil Ivov schrieb:

···

Hey Werner,

Werner Dittmann wrote:

Emil,

when I did the tests and thought about how to solve the problem I didn't
care about STUN :wink: .

Sometimes I also wish we could simply forget about it :wink:

My proposal therefore, after checking netAddressManager.getPublicAddressFor(...),
is to use netAddressManager.getLocalHost(intendedDestination) to get the
source address for media (RTP binding address).

Yes that would be the way to go. We simply need to figure out what would
be the best place to use it.

Something like this:

...
InetAddress localHost = netAddressManager.getLocalHost(intendedDestination);

audioSessionAddress.setControlHostAddress(localhost.getAddress());
audioSessionAddress.setDataHostAddress(localhost.getAddress());

...

videoSessionAddress.setControlHostAddress(localhost.getAddress());
videoSessionAddress.setDataHostAddress(localhost.getAddress());

The above uses just retrieves the localhost address of the NIC that the system
will use for the intended destination and uses this localhost address to bind
the media ports.

IMHO this works well with and without STUN as well as in local network:

- If the request is to the local network using local IP adresses it detects
  the address of the local NIC to use for the intended address. This will be
  the same that will be filled in into SDP.

- If the request is to public IP without NAT it would refer to the IP address
  of the NIC that connects to the public IP. This will be
  the same that will be filled in into SDP.

- if the request is to public IP with NAT it would also refer to the IP
  address of the NIC that connects to the router/NAT. This will be
  different to the address filled into SDP but would not do any harm IMHO.

What do you think?

Fine by me. The only thing is that I don't really see any need to
initialize the SessionAddress object for the ANY address and then reinit
it to a specific IP. It would probably be better to create it directly
with the IP we'd like to use.

Alternately we could also create an empty address and to all the
initialization in allocatePort(). This way it would all be in one place
and we won't need to do it twice (once for video and once for audio).

Does this sound ok? If yes, then would you commit the modification or do
you prefer me to do it?

Cheers
Emil

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

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


#7

Emil,

just an additional remark / question: I looked at "allocatePort(...)" and
saw that this checks for the data port only. The control port is not checked
using "getPublicAddressFor(...)" . Is this intentional?

Regards,
Werner

Emil Ivov schrieb:

···

Hey Werner,

Werner Dittmann wrote:

Emil,

when I did the tests and thought about how to solve the problem I didn't
care about STUN :wink: .

Sometimes I also wish we could simply forget about it :wink:

My proposal therefore, after checking netAddressManager.getPublicAddressFor(...),
is to use netAddressManager.getLocalHost(intendedDestination) to get the
source address for media (RTP binding address).

Yes that would be the way to go. We simply need to figure out what would
be the best place to use it.

Something like this:

...
InetAddress localHost = netAddressManager.getLocalHost(intendedDestination);

audioSessionAddress.setControlHostAddress(localhost.getAddress());
audioSessionAddress.setDataHostAddress(localhost.getAddress());

...

videoSessionAddress.setControlHostAddress(localhost.getAddress());
videoSessionAddress.setDataHostAddress(localhost.getAddress());

The above uses just retrieves the localhost address of the NIC that the system
will use for the intended destination and uses this localhost address to bind
the media ports.

IMHO this works well with and without STUN as well as in local network:

- If the request is to the local network using local IP adresses it detects
  the address of the local NIC to use for the intended address. This will be
  the same that will be filled in into SDP.

- If the request is to public IP without NAT it would refer to the IP address
  of the NIC that connects to the public IP. This will be
  the same that will be filled in into SDP.

- if the request is to public IP with NAT it would also refer to the IP
  address of the NIC that connects to the router/NAT. This will be
  different to the address filled into SDP but would not do any harm IMHO.

What do you think?

Fine by me. The only thing is that I don't really see any need to
initialize the SessionAddress object for the ANY address and then reinit
it to a specific IP. It would probably be better to create it directly
with the IP we'd like to use.

Alternately we could also create an empty address and to all the
initialization in allocatePort(). This way it would all be in one place
and we won't need to do it twice (once for video and once for audio).

Does this sound ok? If yes, then would you commit the modification or do
you prefer me to do it?

Cheers
Emil

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

---------------------------------------------------------------------
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 Werner,

Werner Dittmann wrote:

Emil,

good idea to initialize to the correct address and not using ANY
in the first place.

Let me look where to place this - I can do this during the week. Is
this ok with you?

Yes perfect. Thanks!

Emil

···

Regards,
Werner

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

Emil,

when I did the tests and thought about how to solve the problem I didn't
care about STUN :wink: .

Sometimes I also wish we could simply forget about it :wink:

My proposal therefore, after checking netAddressManager.getPublicAddressFor(...),
is to use netAddressManager.getLocalHost(intendedDestination) to get the
source address for media (RTP binding address).

Yes that would be the way to go. We simply need to figure out what would
be the best place to use it.

Something like this:

...
InetAddress localHost = netAddressManager.getLocalHost(intendedDestination);

audioSessionAddress.setControlHostAddress(localhost.getAddress());
audioSessionAddress.setDataHostAddress(localhost.getAddress());

...

videoSessionAddress.setControlHostAddress(localhost.getAddress());
videoSessionAddress.setDataHostAddress(localhost.getAddress());

The above uses just retrieves the localhost address of the NIC that the system
will use for the intended destination and uses this localhost address to bind
the media ports.

IMHO this works well with and without STUN as well as in local network:

- If the request is to the local network using local IP adresses it detects
  the address of the local NIC to use for the intended address. This will be
  the same that will be filled in into SDP.

- If the request is to public IP without NAT it would refer to the IP address
  of the NIC that connects to the public IP. This will be
  the same that will be filled in into SDP.

- if the request is to public IP with NAT it would also refer to the IP
  address of the NIC that connects to the router/NAT. This will be
  different to the address filled into SDP but would not do any harm IMHO.

What do you think?

Fine by me. The only thing is that I don't really see any need to
initialize the SessionAddress object for the ANY address and then reinit
it to a specific IP. It would probably be better to create it directly
with the IP we'd like to use.

Alternately we could also create an empty address and to all the
initialization in allocatePort(). This way it would all be in one place
and we won't need to do it twice (once for video and once for audio).

Does this sound ok? If yes, then would you commit the modification or do
you prefer me to do it?

Cheers
Emil

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

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

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


#9

Werner,

Werner Dittmann wrote:

Emil,

just an additional remark / question: I looked at "allocatePort(...)" and
saw that this checks for the data port only. The control port is not checked
using "getPublicAddressFor(...)" . Is this intentional?

No it isn't. I actually thought that this was the way we were doing it
so I am a bit surprised it is not the case. There's absolutely no reason
why both ports shouldn't be allocated the same way.

Cheers
Emil

···

Regards,
Werner

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

Emil,

when I did the tests and thought about how to solve the problem I didn't
care about STUN :wink: .

Sometimes I also wish we could simply forget about it :wink:

My proposal therefore, after checking netAddressManager.getPublicAddressFor(...),
is to use netAddressManager.getLocalHost(intendedDestination) to get the
source address for media (RTP binding address).

Yes that would be the way to go. We simply need to figure out what would
be the best place to use it.

Something like this:

...
InetAddress localHost = netAddressManager.getLocalHost(intendedDestination);

audioSessionAddress.setControlHostAddress(localhost.getAddress());
audioSessionAddress.setDataHostAddress(localhost.getAddress());

...

videoSessionAddress.setControlHostAddress(localhost.getAddress());
videoSessionAddress.setDataHostAddress(localhost.getAddress());

The above uses just retrieves the localhost address of the NIC that the system
will use for the intended destination and uses this localhost address to bind
the media ports.

IMHO this works well with and without STUN as well as in local network:

- If the request is to the local network using local IP adresses it detects
  the address of the local NIC to use for the intended address. This will be
  the same that will be filled in into SDP.

- If the request is to public IP without NAT it would refer to the IP address
  of the NIC that connects to the public IP. This will be
  the same that will be filled in into SDP.

- if the request is to public IP with NAT it would also refer to the IP
  address of the NIC that connects to the router/NAT. This will be
  different to the address filled into SDP but would not do any harm IMHO.

What do you think?

Fine by me. The only thing is that I don't really see any need to
initialize the SessionAddress object for the ANY address and then reinit
it to a specific IP. It would probably be better to create it directly
with the IP we'd like to use.

Alternately we could also create an empty address and to all the
initialization in allocatePort(). This way it would all be in one place
and we won't need to do it twice (once for video and once for audio).

Does this sound ok? If yes, then would you commit the modification or do
you prefer me to do it?

Cheers
Emil

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

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

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


#10

Emil,

I've just checked in the modifications.

- Add a port check for the control port in allocatePort
- Modified the allocateMediaPorts to get the right local
  address and initialize the SessionAddress objects with it.

Basically the overall structure was not changed, only a bit simplified.
Putting too much in allocatePort would result in a more complex code.

This runs in my test environment even using the statefull firewall.
However, I have no real STUN testing envirnment at my site thus I ask
everybody to test the call setup in his/her environment, in particular
using STUN.

Thanks.

Regards,
Werner

Emil Ivov schrieb:

···

Werner,

Werner Dittmann wrote:

Emil,

just an additional remark / question: I looked at "allocatePort(...)" and
saw that this checks for the data port only. The control port is not checked
using "getPublicAddressFor(...)" . Is this intentional?

No it isn't. I actually thought that this was the way we were doing it
so I am a bit surprised it is not the case. There's absolutely no reason
why both ports shouldn't be allocated the same way.

Cheers
Emil

Regards,
Werner

Emil Ivov schrieb:

Hey Werner,

Werner Dittmann wrote:

Emil,

when I did the tests and thought about how to solve the problem I didn't
care about STUN :wink: .

Sometimes I also wish we could simply forget about it :wink:

My proposal therefore, after checking netAddressManager.getPublicAddressFor(...),
is to use netAddressManager.getLocalHost(intendedDestination) to get the
source address for media (RTP binding address).

Yes that would be the way to go. We simply need to figure out what would
be the best place to use it.

Something like this:

...
InetAddress localHost = netAddressManager.getLocalHost(intendedDestination);

audioSessionAddress.setControlHostAddress(localhost.getAddress());
audioSessionAddress.setDataHostAddress(localhost.getAddress());

...

videoSessionAddress.setControlHostAddress(localhost.getAddress());
videoSessionAddress.setDataHostAddress(localhost.getAddress());

The above uses just retrieves the localhost address of the NIC that the system
will use for the intended destination and uses this localhost address to bind
the media ports.

IMHO this works well with and without STUN as well as in local network:

- If the request is to the local network using local IP adresses it detects
  the address of the local NIC to use for the intended address. This will be
  the same that will be filled in into SDP.

- If the request is to public IP without NAT it would refer to the IP address
  of the NIC that connects to the public IP. This will be
  the same that will be filled in into SDP.

- if the request is to public IP with NAT it would also refer to the IP
  address of the NIC that connects to the router/NAT. This will be
  different to the address filled into SDP but would not do any harm IMHO.

What do you think?

Fine by me. The only thing is that I don't really see any need to
initialize the SessionAddress object for the ANY address and then reinit
it to a specific IP. It would probably be better to create it directly
with the IP we'd like to use.

Alternately we could also create an empty address and to all the
initialization in allocatePort(). This way it would all be in one place
and we won't need to do it twice (once for video and once for audio).

Does this sound ok? If yes, then would you commit the modification or do
you prefer me to do it?

Cheers
Emil

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

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

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

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