Re: [Linphone-developers] odd behaviours with linphone 3.1.2

[Jim Diamond]

On Fri, Jul 31, 2009 at 22:14 (+0200), Simon Morlat wrote:

Hi Simon

> Le vendredi 31 juillet 2009 20:45:03, Jim Diamond a écrit :
>> If anyone can shed some light on these issues, I would appreciate it.

>> (0) Initially I could not convince Linphone to properly connect with
>> another connection which is behind a Linksys WRT54G router, even
>> though that system's router is set (with port triggering) to open
>> ports 5060 to 9079.  (The trigger is based on another program I had
>> running at the time, and, as far as I can tell, it seems to open all
>> the requested ports.)  Linphone would, however, connect to a linphone
>> on a system which is directly connected to the internet.

>> I tried connecting both with "Behind NAT / Firewall" (and giving the
>> external IP address) and "Behind NAT / Fireway (use STUN to resolve)".
>> I tried connecting from both ends.

>> In the cases where it would not connect properly, it knew the call was
>> connected, but I could not receive video or audio.

>> But when I configured the local router for port triggering, things
>> started to work.  Shouldn't STUN be able to deal with punching holes
>> through the firewall/router?
> STUN can only make good job if one of the firewalls is full-cone, ie if a 
> packet opens an outgoing connection to X, then Y can send back a packet 
> through the opened hole.  For security reasons, many firewals are symmetric, 
> meaning that the packet coming from Y will be discarded.
Hmmm... thanks for that info.  I was under the impression that with
the help of a STUN server most routers could be used (as is).

Is there documentation explaining what linphone does in the case where
you choose the "Behind NAT / Firewall (specify gateway IP below)" ?
That is, what does linphone do in that case to help itself out?

> I don't know what port triggering means,
What I mean is this... my router (like many) has the ability to open
some incoming ports if an outgoing connection is made on a certain
port.  For example, I have my router set up so that if one of my LAN
machines connects to an external system using port 3456, then my
router will automagically direct all inbound packets on ports
5060-9079 to that internal system.

While this works very well for me, trying to explain to the average
computerphobe how to enable port triggering on their router is a task
I'd prefer to avoid.

> but perhaps it activated some intelligent functionnality of your
> router so that it masquerade the ports indicated in the outgoing SDP
> messages.  Which would do a SIP proxy.

> I discourage the use of SIP for direct calls between machines being
> behind a firewall (machines being on different networks).  The
> router attempt to do things to make it work, the UA with STUN try to
> do also things to make it work, but the result of the two is that in
> most case it does not work.
It is a bit of a pain, that's for sure.  But yet, when ekiga worked
for me (in the ekiga 2.0 days), it seems that ekiga managed to get
through routers reasonably well.  Thus my assumption about linphone
doing it also.

> The only good solution is (to me): 1- configure your firewall to be
> as dumb as possible (such as linux basic iptables configuration
> would do) 2- be helped by a SIP proxy running on the public
> internet.  It will make sure all SIP messages are transfered
> correctly, and will possibly make RTP relaying for audio video.  You
> have a free to use proxy running at http://sip.antisip.com
Thanks, I will look into seeing whether I can use this in my
application.  The problem is that people who will be using this system
are computerphobes and getting them all to register sip accounts might
be a nuisance.  (But that may be better than not being able to connect
at all.)



>> (1) Once I got things running, Linphone kept dropping the connection
>> today, it rarely stayed connected more than 1 minute.  I didn't notice
>> any other problems with anything else I was doing at the time, but
>> perhaps nothing else was as sensitive to network conditions.  I am
>> wildly speculating that very short momentary packet losses causes
>> Linphone to disconnect.  Is that speculation correct?

>> If my speculation is correct, is there some way to tell Linphone to be
>> a bit more patient, should the packets not get through for some
>> relatively small time?
> Normally: linphone terminates the call if it does not receive any
> packet for more than 30 seconds.
Hmmm... I didn't think the network dropouts were anywhere near that
long.  I'll watch more closely.



>> (2) In some situation(s) which I can't pin down, linphone-3 gets
>> confused about what it should be showing the video window.  Earlier
>> today I was trying to use linphone and it somehow got confused about
>> what it is doing.  The other end disconnected from the internet hours
>> ago, but at my end
>> - the control window has a button saying "start call", not :terminate
>> call", but
>> - the video window has the small "picture-in-picture" window as well as
>> the larger webcam image
>>   - the picture-in-picture image is showing my webcam image about 95% of
>> the time, but keeps flicking to and from the "No webcam" picture
>>   - the main picture shows a frame from the video hours ago about 95%
>> of the time, and the rest of the time it quickly flashes up
>> another image, which I believe is another frame from the video call.

> I did have this bug some time ago. I could not explain it nor
> reproduce it.  It's like if the call was terminated, but the audio
> and video outgoing streams continue working.  If you have a use-case
> where it produces easily, then please send me a log (linphone-3
> --verbose &>log.txt).  I'll be interested in fixing it of course.
Thanks.  I will attempt to find a reproducible case.

Cheers.
                                Jim