[jitsi-users] ICE for Media

#1

Hi Emil,

with jitsi I am just a user reporting and looking for answers where jitsi
does not "just work", which usually helps developments significantly.

As nat/port/forwarding related questions came up here so often, I even compiled a draft FAQ
item from the info gathered in several threads,

Of course I have no dev knowlege here, but it gives you something to work
with and correct:
http://lists.jitsi.org/pipermail/users/2014-February/006542.html

You seem to be repeatedly asking the same questions and yet put very
little effort in understanding the answers.

I don't think that the statement "manual portforwading won't help" has been
completely explained, yet.

Concerning SIP, Ingo finaly helped to to draw some conclusions why
"portforwarding would not help" for the SIP protocoll with jitsi.

From what I gathered, it seems to send private IPs in packages to public IP

destinations and does not seem to fall back to the public sender IP when it receives a
a private IP address in the packet.
That is the best I got, please correct if that conclusion is not drawn correctly.

Concerning the XMPP/jingle protocoll, temporarily allowing automatic UPNP port
forwarding did help here,
and it has only been lately reported by another user that the manual port configuration options
had no effect.

So why should manual port forwarding not help for XMPP?

  Once ICE
is also implemented for SIP, this should work as it will include all
possible addresses in the SDP.

>
> Be carefull in selecting, never to send media to all possible addresses
> (the local IP may be valid on the remote side and point to somebody else)

Here, yes I forgot to mention that I thought of the bug that was reported on the
list (and that I had seen as well) where a call could not be properly ended
(media continued to be transmitted).

This doesn't prevent you
from making assertions based on false assumptions.

Yes, unforunately. Everybody does that, inevitably. That's why
discussions that explain things help so much more.

When what you are trying to say is that ICE is will be used to pick
out only a single pair of addresses that is then going to be used,
it is a gladly appreciated correction.

Thanks!
Chris

#2

You seem to be repeatedly asking the same questions and yet put very
little effort in understanding the answers.

I don't think that the statement "manual portforwading won't help" has been
completely explained, yet.

Hmmm ... how about Ingo's answer then:

You probably can establish a call if you forward the port 5060 on your NAT
box, but you won't have media. This is because SIP contains your local IP
address in the INVITE SDP (e.g. 192.168.1.10). The remote peer doesn't know
that this address should actually be the public IP of the NAT box.

http://lists.jitsi.org/pipermail/users/2014-March/006837.html

Concerning SIP, Ingo finaly helped to to draw some conclusions why
"portforwarding would not help" for the SIP protocoll with jitsi.
From what I gathered, it seems to send private IPs in packages to public IP
destinations and does not seem to fall back to the public sender IP when it receives a
a private IP address in the packet.

Fall back to what? What public IP are you referring to? How does one learn about it?

That is the best I got, please correct if that conclusion is not drawn correctly.

If your conclusion is that a user agent can automatically discover a working IP address for the remote party whenever it receives a private one, then yes, that conclusion is wrong. You only have what you get in SDP (well ... with some exceptions but that's besides the point here).

Concerning the XMPP/jingle protocoll, temporarily allowing automatic UPNP port
forwarding did help here,

Correct. We have ICE support for XMPP and we also explicitly support UPnP so *Jitsi* can automatically allocate public ports on a local NAT. Contrary to manual port forwarding, this way it would know what they actually are and would include them among the other ICE candidates.

and it has only been lately reported by another user that the manual port configuration options
had no effect.

Eeer ... no I had actually said this here quite a while ago and it is also part of our FAQ:

https://jitsi.org/Documentation/FAQ#ice-failed

So why should manual port forwarding not help for XMPP?

For exactly the same reason that Ingo has explained for SIP. Why do you expect it to be different?

I am going to insist on what I said in my last e-mail because maybe you disregarded it as sarcastic and decided to pay no mind:

I suggest you have a read at RFC5245

http://tools.ietf.org/html/rfc5245

Sections 1, 2 and 3 should help you understand how and why ICE works the way it does (with some useful background along the way).

The following might also be informative:

http://tools.ietf.org/html/rfc4787

   Once ICE
is also implemented for SIP, this should work as it will include all
possible addresses in the SDP.

Be carefull in selecting, never to send media to all possible addresses
(the local IP may be valid on the remote side and point to somebody else)

Here, yes I forgot to mention that I thought of the bug that was reported on the
list (and that I had seen as well) where a call could not be properly ended
(media continued to be transmitted).

Could you please remind me of this one? Can you reliably reproduce it? If so, could you please reopen the corresponding thread?

This doesn't prevent you
from making assertions based on false assumptions.

Yes, unforunately. Everybody does that, inevitably. That's why
discussions that explain things help so much more.

Yes. This does happen to everyone. Asking questions on the mailing lists is not the only way this could be straightened out though. There are various sources of information over the Internet, so let's spare everyone's time for things that Wikipedia and tools.ietf.org/html/rfc??? won't resolve for us.

Cheers,
Emil

···

On 24.03.14, 11:23, ca2013@arcor.de wrote:

When what you are trying to say is that ICE is will be used to pick
out only a single pair of addresses that is then going to be used,
it is a gladly appreciated correction.

Thanks!
Chris

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org

#3

Thanks Emil, I may have found the point where we were making different
assumptions (see below).

http://lists.jitsi.org/pipermail/users/2014-March/006837.html

Yes, that was the message I referred to concerning SIP.

> Concerning SIP, Ingo finaly helped to to draw some conclusions why
> "portforwarding would not help" for the SIP protocoll with jitsi.
> From what I gathered, it seems to send private IPs in packages to public
IP
> destinations and does not seem to fall back to the public sender IP when
it receives a
> a private IP address in the packet.

Fall back to what? What public IP are you referring to? How does one
learn about it?

Maybe the following is the source of confusion: All the time I am considering
the use case of jitsi configured to use only specific ports, and port forwarding
properly set up accordingly in the (bad NAT type) router.

The rationale is, to allow jitsi to work with some jitsi+router configuration by the user,
even in the cases where NAT hole punching won't work, and no relay is available.)

So, to answer above questions: In the case where jits ports and router port
forwarding areconfigured, I assume direct peer
packages get though, the receiver of a package sees the public IP
of the remote NAT router as the originating IP, and may choose to
send responses to that IP, instead of to the IP in the private
address ranges that the remote peer has put in the INVITE message.

If both sides do that, I assume direct RTP should be possible.

I found this "send stream to originating address instead of INVITE address"
may be called "Send Resp To Src Port" on some devices (see bottom of
SIP tab on http://spakonfig.de).

> That is the best I got, please correct if that conclusion is not drawn
correctly.

If your conclusion is that a user agent can automatically discover a
working IP address for the remote party whenever it receives a private
one

Not whenever (unconditionally), but when ICE has failed and the remote
side has configured port forwarding properly.

> Concerning the XMPP/jingle protocoll, temporarily allowing automatic UPNP
port
> forwarding did help here,

Correct. We have ICE support for XMPP and we also explicitly support
UPnP so *Jitsi* can automatically allocate public ports on a local NAT.
Contrary to manual port forwarding, this way it would know what they
actually are and would include them among the other ICE candidates.

> and it has only been lately reported by another user that the manual port
configuration options
> had no effect.

Eeer ... no I had actually said this here quite a while ago and it is
also part of our FAQ:

https://jitsi.org/Documentation/FAQ#ice-failed

Yes, I have read there: ...maping port numbers on your home router ...is going
to have no effect, and in emails that: ...it won't help.

And that leaves readers without an explanation why, which is
especially confusing for users that have successfully configured
the used ports and forwarded them on the router
to make other communication work for other applications.

Of course if some explicitly configured jitsi port settings have no effect,
port forwarding on the router won't help, but I thought that that would
be a bug that may get fixed eventually rather than a
technical impossibility.

> So why should manual port forwarding not help for XMPP?

For exactly the same reason that Ingo has explained for SIP. Why do you
expect it to be different?

Well the reason I believe it should work is, because the protocol
already works when Jitsi sets up port forwarding with UPNP for the
dynamically allocated ports (in cases where ICE hole punching fails),
I can't think of a reason why the same protocol should not work with fixed jitsi ports
and manual port forwarding configured in the router.

(With SIP I understand now it may require something like responding to the sender
IP if it is not the same as the IP in the INVITE message, if at all possible.)

I am going to insist on what I said in my last e-mail because maybe you
disregarded it as sarcastic and decided to pay no mind:

Not at all, I did actually read about ICE and NAT when you linked to it in your
very first reply. I may have not communicated well enough that for the
case that I am considering, where I think port forwarding makes sense,
I think ICE is already out of the equation because it fails and can't help further
...but manual port forwarding may allow using jitsi (without needing a relay).

Kind Regards, and my full appreciation
Chris

#4

Thanks Emil, I may have found the point where we were making
different assumptions (see below).

http://lists.jitsi.org/pipermail/users/2014-March/006837.html

Yes, that was the message I referred to concerning SIP.

Concerning SIP, Ingo finaly helped to to draw some conclusions
why "portforwarding would not help" for the SIP protocoll with
jitsi. From what I gathered, it seems to send private IPs in
packages to public

IP

destinations and does not seem to fall back to the public sender
IP when

it receives a

a private IP address in the packet.

Fall back to what? What public IP are you referring to? How does
one learn about it?

Maybe the following is the source of confusion: All the time I am
considering the use case of jitsi configured to use only specific
ports, and port forwarding properly set up accordingly in the (bad
NAT type) router.

The rationale is, to allow jitsi to work with some jitsi+router
configuration by the user, even in the cases where NAT hole punching
won't work, and no relay is available.)

So, to answer above questions: In the case where jits ports and
router port forwarding areconfigured, I assume direct peer packages
get though, the receiver of a package sees the public IP of the
remote NAT router as the originating IP, and may choose to send
responses to that IP, instead of to the IP in the private address
ranges that the remote peer has put in the INVITE message.

If both sides do that, I assume direct RTP should be possible.

I found this "send stream to originating address instead of INVITE
address" may be called "Send Resp To Src Port" on some devices (see
bottom of SIP tab on http://spakonfig.de).

What you are describing is a technique known as latching or Hosted NAT
Traversal:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

This is something that can be done if and *only* if one of the peers is
guaranteed to have a public IP address. Latching is therefore generally
only supported by servers (and we actually rely on that for SIP NAT
traversal).

Note that latching DOES NOT in any require port mapping.

That is the best I got, please correct if that conclusion is not
drawn

correctly.

If your conclusion is that a user agent can automatically discover
a working IP address for the remote party whenever it receives a
private one

Not whenever (unconditionally), but when ICE has failed and the
remote side has configured port forwarding properly.

If it were possible for one of the agents to send packets directly to
the other, ICE wouldn't have failed in the first place.

Note that an incoming INVITE comes from the IP address of the signalling
server. So a callee has no way of determining what IP address you are
using based on that alone.

Concerning the XMPP/jingle protocoll, temporarily allowing
automatic UPNP

port

forwarding did help here,

Correct. We have ICE support for XMPP and we also explicitly
support UPnP so *Jitsi* can automatically allocate public ports on
a local NAT. Contrary to manual port forwarding, this way it would
know what they actually are and would include them among the other
ICE candidates.

and it has only been lately reported by another user that the
manual port

configuration options

had no effect.

Eeer ... no I had actually said this here quite a while ago and it
is also part of our FAQ:

https://jitsi.org/Documentation/FAQ#ice-failed

Yes, I have read there: ...maping port numbers on your home router
...is going to have no effect, and in emails that: ...it won't help.

And that leaves readers without an explanation why, which is
especially confusing for users that have successfully configured the
used ports and forwarded them on the router to make other
communication work for other applications.

I am just ... totally lost :slight_smile: ... We make it clear that port forwarding
is not helping. You claim that some users would still do port forwarding
and then be confused because it does not work?

To me the fact that things don't work when someone told me they wouldn't
work actually sounds pretty consistent ...

Of course if some explicitly configured jitsi port settings have no
effect, port forwarding on the router won't help, but I thought that
that would be a bug that may get fixed eventually rather than a
technical impossibility.

Well I hope we've managed to clarify that now.

So why should manual port forwarding not help for XMPP?

For exactly the same reason that Ingo has explained for SIP. Why do
you expect it to be different?

Well the reason I believe it should work is, because the protocol
already works when Jitsi sets up port forwarding with UPNP for the
dynamically allocated ports (in cases where ICE hole punching
fails),

Please note that with Jitsi UPnP works as part of ICE. Not
independently. When UPnP succeeds then ICE succeeds.

I can't think of a reason why the same protocol should not work with
fixed jitsi ports and manual port forwarding configured in the
router.

I answered this exact question in my previous mail:

Correct. We have ICE support for XMPP and we also explicitly support
UPnP so *Jitsi* can automatically allocate public ports on a local
NAT. Contrary to manual port forwarding, this way it would know what
they actually are and would include them among the other ICE
candidates.

When you forward ports manually, Jitsi has no idea that you have done that.

(With SIP I understand now it may require something like responding
to the sender IP if it is not the same as the IP in the INVITE
message, if at all possible.)

The "sender IP" is that of the server.

I am going to insist on what I said in my last e-mail because maybe
you disregarded it as sarcastic and decided to pay no mind:

Not at all, I did actually read about ICE and NAT when you linked to
it in your very first reply. I may have not communicated well enough
that for the case that I am considering, where I think port
forwarding makes sense, I think ICE is already out of the equation
because it fails and can't help further ...but manual port forwarding
may allow using jitsi (without needing a relay).

No it won't. This is wrong. I have done my best to explain why. If you are still not happy with what I've said, fine. You are free to continue believing the opposite if you choose to do so. However, please don't say this again on this mailing list. It is misinformation.

Cheers,
Emil

···

On 24.03.14, 20:07, ca2013@arcor.de wrote:

--
https://jitsi.org

#5

I see, you emphasize that Jitsi does not support manual port forwarding.

I don't wan't to spread misinformation. Sorry, if my statements could be misunderstood:
Jitsi does not support manual port forwarding.

Yet, I am questioning if direct calls using manually configured port forwarding
is a something entirely impossible.

What you are describing is a technique known as latching or Hosted NAT
Traversal:

http://tools.ietf.org/html/draft-ietf-mmusic-latching

This is something that can be done if and *only* if one of the peers is
guaranteed to have a public IP address. Latching is therefore generally
only supported by servers (and we actually rely on that for SIP NAT
traversal).

Note that latching DOES NOT in any require port mapping.

Why should that be relevant? Does latching conflict with port mapping?
I see it as a tool to enable comunication with a peer behind
a NAT that invites public IPs to its private IP. (Announcing the private IP may be
required only to facilitate lan-only routes in case both clients happen to
sit behind the same router.)
Respect, if you are even the author of the latching document.

I would really like to understand a concrete restriction why it
should p2p communication can't be facilitated using port forwarding
instead of relays. Maybe throug a simple statement like x can not
determine the port of y because of z could be made.

Why would you say the requirement for a public IP can not be met this way?:

* the router has a public IP
* ports manually forwarded to the same ports on the
  client behind the NAT
* client determines its public (forwarded) router address with
  the help of a STUN server or UPNP (read only)
* the peer INVITES using the public router IP

Why should a latching peer set up like this then not be able to sucessfully
comunicate with a peer, even when that peer happens not to
INVITE to its public IP but a private IP?

>>> That is the best I got, please correct if that conclusion is not
>>> drawn
>> correctly.
>>
>> If your conclusion is that a user agent can automatically discover
>> a working IP address for the remote party whenever it receives a
>> private one
>
> Not whenever (unconditionally), but when ICE has failed and the
> remote side has configured port forwarding properly.

If it were possible for one of the agents to send packets directly to
the other, ICE wouldn't have failed in the first place.

Oh yes, that is a good question! Why would ICE fail when manual port forwarding
is configured?

* Jitsi not using configured ports?
* ICE not trying the configured local ports and STUN determined IP?
...?

Note that an incoming INVITE comes from the IP address of the signalling
server. So a callee has no way of determining what IP address you are
using based on that alone.

For direct calls it is needed to receive incoming RTP packages to get
the peers public address (thus the port forwarding to allow that).

STUN, VIA messages (sip server/peer dependent), or UPNP (read only) can
be used to let a peer know its own public address, and use it in INVITES.

I am just ... totally lost :slight_smile:

Yeah, me too :slight_smile:

... We make it clear that port forwarding
is not helping. You claim that some users would still do port forwarding
and then be confused because it does not work?

Hm, not exactly. I read port forwarding is not helping, and the responses to users
sound as if it is impossible at all (not just unsupported).

At the same time many SIP devices, e.g. the SPAs, work quite well behind
NAT routers with port forwarding. In fact port forwarding seems a pretty standard
measure in p2p comunication and SIP http://kb.smartvox.co.uk/voip-sip/sip-devices-nat/
That is probaly the reason for why so many ask about it for jitsi.

To me the fact that things don't work when someone told me they wouldn't
work actually sounds pretty consistent ...

It would sound consistent to me as well, if only there would be no successful port
forwarding practice elsewhere.

> I can't think of a reason why the same protocol should not work with
> fixed jitsi ports and manual port forwarding configured in the
> router.

I answered this exact question in my previous mail:

> Correct. We have ICE support for XMPP and we also explicitly support
> UPnP so *Jitsi* can automatically allocate public ports on a local
> NAT. Contrary to manual port forwarding, this way it would know what
> they actually are and would include them among the other ICE
> candidates.

What specifically do you consider as unknown when the user manually
configures explicit ports for jitsi to bind to and ports on the router to forward?

When you forward ports manually, Jitsi has no idea that you have done that.

Couldn't ICE just try the local port and the public IP, or a forwarded_ports configuration
option provide that information?

Cheers,
Chris

PS: I still could not reproduce the ongoing audio after the call ended.

#6

OK, cool. Let's put it that way if you wish.

In order for manual port forwarding to work with Jitsi we need to implement code that would only work for users that have been able to properly route ports. How many would that be? Less than 1%?.

Furthermore, if this was to be supported, I expect poor understanding of NAT traversal issues to quickly lead to advices like "you can use Jitsi but you just need to forward these ports" even in cases where this is absolutely not required. I expect this to discourage many more users from using Jitsi than it would actually help.

So again, when using Jitsi: do not bother forwarding ports.

Emil

···

On 25.03.14, 01:47, ca2013@arcor.de wrote:

I see, you emphasize that Jitsi does not support manual port forwarding.

--
https://jitsi.org