linphone-developers
[Top][All Lists]
Advanced

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

[Linphone-developers] Separate registrar/outbound-proxy settings AND 1.0


From: Daniel Freedman
Subject: [Linphone-developers] Separate registrar/outbound-proxy settings AND 1.0.1 compile issues...
Date: Tue, 19 Apr 2005 15:20:57 -0400
User-agent: Mutt/1.3.28i

<Please cc: me on replies>

Hi Simon,

I sent this email to linphone-users a few days ago (following up on an
earlier thread), but now realize that it should probably belong on
linphone-devel.  I encountered the same issue to which you responded
last week (below), so maybe I can explain it further.  I'm using
LinPhone 0.12.2 as packaged for Debian Sarge. It's working perfectly
for me, but only because I'm lucky in the configuration that my VoIP
provider chose (in that they selected to have the same IP address
point to both SIP registrar and SIP outbound proxy).

Anyway, when I go to configure LinPhone via the 'Preferences' dialog
box, and the 'SIP' configuration tab, I'm presented with some choices
regarding the 'Remote services'.  I select to use a 'SIP Registrar'
and enter the server address for this registrar, as well as my
password and my address of record.  So far, so good.  The problem now
lies with the fact that Linphone only allows me the option of using
*THIS* 'SIP Registrar' as my outbound proxy.  It does not allow me to
utilize a different upstream server for outbound proxy.  I happened to
luck out, as my VoIP provider has their outbound proxy as simply a DNS
CNAME alias for their SIP registrar, so my packets went to the right
place.  However, other VoIP providers might use different setups, in
which case this would fail.  Just FYI, in contrast, you might want to
examine Kphone which allows independent configuration of SIP
registrars and Outbound proxies.  (However, I should compliment
LinPhone as it really worked with the Digest Authentication of my VoIP
provider, while KPhone could successfully register, but couldn't
properly authenticate its INVITEs, so it would just hang and I never
got it to complete a call...)

In other similar feature requests, I'm wondering if you're considering
adding STUN support, rather than the more basic 'NAT traversal
options' that are currently available (but require user to know
his/her NAT WAN address).

Finally, I compiled LinPhone 1.0.1 from source, and still had the
above issues.  In addition, I ran into a few other things you might
want to note: I thought you might want to include an 'autoconf'd test
in the 'configure' script to check for a recent-enough version of
libosip2.  When I tried to compile the eXosip library included with
LinPhone 1.0.1 against my Debian sarge libosip2 dev files (version
2.0.6), the compile balked. However, the upstream source libosip2
version 2.2.1-pre2 worked fine with the included eXosip. Further, the
'--with-osip=/path/to/source/osip" correctly finds the specified
libosip2 libraries for linking, but then the resulting binaries don't
find them for runtime linking, and instead invoke the older Debian
packaged libosip2.  I'm a little rusty with my link options, but I
believe this is the difference between passing the osip libraries as
'-L' options versus '-R'/'-rpath' options.  I'm not knowledgable about
'automake', but I imagine this behavior could be fixed through it, if
desired.  In the end, though I could compile and run linphone 1.0.1, I
could never get it to successfully complete a SIP call as I could with
0.12.2 (at least with my configuration).

Hope these comments help, and thank you, Simon, for a great linux SIP
softphone...

Take care,
Daniel



On 12 Apr 2005, Simon Morlat wrote:
> Hi,
> 
> I don't fully understand what you mean. Linphone normally
> allows to have proxy and realm different. What's going wrong
> exactly ? The server rejects your authentication ? Please
> clarify.
> 
> Simon


-- 
Daniel A. Freedman <address@hidden>, Graduate Fellow
  Electronic Structure Calculations, LASSP, Cornell University




reply via email to

[Prev in Thread] Current Thread [Next in Thread]