[Asterisk-Users] IAX2 (was: diax softphone )

[Grzegorz Nosek]

On Wed, 4 Feb 2004 11:13:52 +0200, Dan wrote
> Hi,
> 
> From: "Peer Oliver schmidt" <posde at theinternet.de>
> 
> > >>I have 4569 opened and forwarded/NATed to my *. I am on the same
network
> > >>as the * server, a friend is remote. After about a minute you
loose the
> > >>connection.
> >
> > > This is another problem and it happens for me too (known bug, which
> seems to
> > > be related with the re-registration which occurs at 60s).
> >
> > Maybe those two problems are related to each other, i.e. IAX2 tries to
> > bridge the call ... (I have no idea what I am talking about)
> >
> 
> I think that the call is allways passed through the * server 
> if IAX(2) is used.
> 
> BR,
> Dan
> 

Actually, IAX(2) calls are bridged whenever they can. The server sends
TXREQ to both legs of the call and the clients try to connect to each
other. What came to my mind is that it might break in NAT
environment... Let's see (Note: not tested in the wild, just
speculations):
 - UA1 10.0.0.10:4569 - inside NAT
 - UA2 1.1.1.1:4569 - outside NAT
 - server 10.0.0.1:4569/2.2.2.2:4569 - accessible from both UAs

UA1 and UA2 register on the server, which fills their apparent_address
info the way it can see them (UA1 has private IP, UA2 is public). When
a call is established and UA1 and UA2 send TXCNTs to each other, they
get the peer address from the * server, so
 - UA1 tries to connect to 1.1.1.1:4569 which should work (NATted by
the router)
 - UA2 tries to connect to 10.0.0.10:4569 - no go.
 - UA1's packet reaches UA2 (say, NATted to 2.2.2.2:50000), so UA2
sends TXACC, but (correct me if I'm wrong here) the peer address is
not updated.

Thus, the connection breaks as UA1 never receives the TXACC that UA2
sent. If libiax2 (and chan_iax2 - though I haven't actually looked
into it too much) set the peer's address upon receipt of TXCNT, it
might work (UA2 would talk to 2.2.2.2:50000 which the router would NAT
back to 10.0.0.10:4569). If that's not the problem, sorry for
confusing you. :) A packet dump should reveal all.

What do you think?
 Greg