Re: [Ekiga-list] Estreet SIP account and Ekiga



When creating an account in Linphone I have to supply a SIP identity
(sip:<my-phone-number>@as.estreet.com) and a SIP proxy
(sip:vgs3.estreet.com). Once this is done, Linphone prompts me for a
user ID (<my-phone-number> again) and my password. Supplying this data
correctly makes Linphone register to Estreet immediately.  Actually,
the exact diagnostic is 'Registration on <sip:vgs3.estreet.com>
successful.'

Ekiga, on the other hand, does not offer the possibility of entering a
proxy when editing a SIP account. It does allow to enter a global SIP
proxy in the Preferences tab. I am not sure if it is such a good idea
to have just a global SIP proxy but, at any rate, even entering the
Estreet proxy won't get Ekiga to register.

Now, as you suggested, I have captured SIP packets with Wireshark (TCP
and UDP at port 5060) when using three different softphones configured
to register to my Estreet account: Linphone, Zoiper and Ekiga. The
first two register all right. In the capture one can see that they
both exchange UDP packets with 66.227.111.13 - which is
vgs3.estreet.com. Ekiga, on the other hand, always tries to connect to
a host like 77.72.174.xxx (which I can't do a reverse resolution on)
and using a protocol that Wireshark calls CLASSIC. A quick look into
the capture seems to imply that this is to do with NAT and a STUN
server, but Ekiga gets stuck at that point. Without a SIP proxy in the
preferences that's as far as it goes. With the vgs3.estreet.com proxy
it does establish a SIP dialog with 66.227.111.13, but gives up
complaining that it has encountered a loop.




On Sat, Aug 2, 2014 at 3:33 PM, James Cloos <cloos jhcloos com> wrote:
"JCA" == JCA  <1 41421 gmail com> writes:

JCA> Thanks for your reply. You are right in that as.estreet.com does not
JCA> resolve. However, using estreet.com does not fix the problem; it just
JCA> changes the error diagnostic to 'Could not register (Not found)'.

When a specified sip name lacks a or aaaa records, there usually are
either naptr or srv records which the sip ua can use to find the remote
host.

Neither as.estreet.com naptr, nor _sip._udp.as.estreet.com exist.

I don't know how linphone was able to connect.

Next step, then, is to use something like ngrep or wireshark to watch
the packets and see what linphone sends and receives.  That would
explain how linphone gets from the name as.estreet.com to a working host.

-JimC
--
James Cloos <cloos jhcloos com>         OpenPGP: 0x997A9F17ED7DAEA6


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]