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

[JCA <1 41421 gmail com>]

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