Open GoogleCodeExporter opened 8 years ago
GoogleCodeExporter
commented
8 years ago FWIW everything works fine if I shut down vmware and use the airport (en1) as my
primary connection.Original comment by evarsa...@gmail.com on 4 Jan 2010 at 2:58
GoogleCodeExporter
commented
8 years ago While the next release of Telephone should use better IP detection algorithm
(from pjsip), it’s usually not a
problem. If your provider’s doing NAT traversal at the server side, it should
work with any proper internal IP
address (192..., 172..., 10...). If it doesn’t, you’d better use STUN. In
your case I would try to change VMware’s IP
range to exclude the possible conflict with the provider’s internal address
space, or try to configure Telephone
with a STUN server.
Does your provider tell anything about STUN (NAT traversal from the client
side)?Original comment by eofs...@gmail.com on 4 Jan 2010 at 10:06
GoogleCodeExporter
commented
8 years ago I was trying with and without NAT traversal at the provider side (voip.ms) just
in
case, but that didn't make a difference.
There's no NAT in this configuration, the Mac has several interfaces and PPP0
(the
default route) is going out to the internet unnatted. The problem is the Contact
field in the SIP header pjsip creates and sends to the voip provider is from
another
interface (which is not the default route -- the vmware interface which is
internal
only). The private address on the vmware internal NAT setup should have no
bearing on
the call, Telephone is running on the outer operating system and the default
route is
via a direct unnatted path.
I looked at the code in pjsip for a while but couldn't find where it determines
'the
local IP' to fill in the contact field immediately. Presumably it gets a list
of the
interfaces with the usual ioctl then goes through them and tries to figure out
which
one serves the default route or the route to the end we're trying to call if its
fancy. I suspect that algorithm is flawed or too simplistic to work correctly
on a
multi-homed host.Original comment by evarsa...@gmail.com on 11 Jan 2010 at 4:58
GoogleCodeExporter
commented
8 years ago I understand what you’re saying, but in real life, almost always when using
softphones, it doesn’t matter what
address is announced in the Contact field. In the beginning, of course, that
was exactly the place for the address
where user agents were expecting packets. But nowadays SIP providers pay
attention to the real address your
requests came from, not the address from the Contact field. They send replies
to that real IP address, which
allows them to solve a NAT problem, and, coincidentally, our problem.
pjsip selects the IP address at it’s initialization, which often occurs when
application launches. At that time PPP
interfaces may be down and not configured yet. STUN and NAT fix at provider’s
side—these are two ways to solve
that.
I’ve noticed that voip.ms has an option ‘Device type’ with the default
value ‘IP PBX Server, Asterisk or Softswitch’.
Could you please try setting it to ‘ATA device, IP Phone or Softphone’ if
you haven’t done that already.Original comment by eofs...@gmail.com on 11 Jan 2010 at 8:02
GoogleCodeExporter
commented
8 years ago And please make sure you have ‘NAT’ set to ‘yes’.Original comment by eofs...@gmail.com on 11 Jan 2010 at 8:41
GoogleCodeExporter
commented
8 years ago I am using a sub account on voip.ms with it set to IP phone. I tried
it with NAT turned on and off and tcpdump shows responses coming
back when the Contact field is correct and nothing coming back (for
the register request) when the contact field has the bogus internal
address on it. I tried several of their pops as well (Dallas, LA,
and one other).
I captured working and non-working register requests when I ran
into this in late December and compared the packets and I *thought*
the only difference was the Contact field (when I saw it was one
of my vmware interfaces I shut down vmware and everything worked
fine). I might have missed some other difference, I'll set up another
test and try to reproduce it all again with NAT on and off.
Thanks,
-Eric
Description Hotdog
Secret xxxxxxxx
Protocol SIP
Authentication type Register
Allowed Codecs ulaw;g729
Device Type ATA, IP Phone or Soft phone
CallerID Number xxxxxxxxxx
NAT no (tried yes too)
DTMF Mode auto
International Route Value
Internal Extension none
Internal Extension Voicemail none
Internal Dial Time n/a
External SIP URI none
Edit this Sub Account - Delete this Sub Account
Original comment by evarsa...@gmail.com on 20 Jan 2010 at 5:20
Original issue reported on code.google.com by
evarsa...@gmail.comon 3 Jan 2010 at 10:58