Bug 5523 (int-143667)

Summary: High latency between UI and SIP events being sent
Product: [Maemo Official Applications] Chat & Call & SMS Reporter: Lucas Maneos <maemo>
Component: SIPAssignee: rtcomm <rtcomm>
Status: VERIFIED FIXED QA Contact: sip-bugs
Severity: normal    
Priority: Low CC: andre_klapper, in-maemo, mikhail.zabaluev, olivier.crete
Version: 5.0/(1.2009.42-11)   
Target Milestone: 5.0/(2.2009.51-1)   
Hardware: All   
OS: Maemo   

Description Lucas Maneos (reporter) 2009-10-16 21:18:15 UTC
SOFTWARE VERSION:
1.2009.41-10

STEPS TO REPRODUCE THE PROBLEM:
1. Start tcpdump.
2. Initiate a SIP call.
3. Wait to see the INVITE being sent.

(Or just call another local SIP UA and wait for it to ring).

EXPECTED OUTCOME:
Nearly immediate call initiation.

ACTUAL OUTCOME:
Approximately 10-12" lag.  A similar but slightly shorter (7-8") delay is also
observed between answering an incoming SIP call and the OK response being sent
back.  The CPU is mostly idle during this.

REPRODUCIBILITY:
Always.

OTHER COMMENTS:
This doesn't seem to affect XMPP or cellular calls.
Comment 1 Mikhail Zabaluev nokia 2009-10-19 14:57:17 UTC
The biggest culprit is waiting for a response from a STUN server which is
misconfigured or down. What do you have for STUN settings? If you have STUN
server auto-discovery enabled, what does a DNS lookup like "dig SRV
_stun._udp.<account_domain_name>" retrieve?

There may be other surprises. I'd like to see at a packet dump for call
establishment.
Comment 2 Lucas Maneos (reporter) 2009-10-20 05:40:14 UTC
(In reply to comment #1)
> The biggest culprit is waiting for a response from a STUN server which is
> misconfigured or down.

Sounds plausible, but:

> What do you have for STUN settings? If you have STUN
> server auto-discovery enabled, what does a DNS lookup like "dig SRV
> _stun._udp.<account_domain_name>" retrieve?

same behaviour with auto or an empty STUN server setting.  The domain doesn't
have any stun SRV records.

> There may be other surprises. I'd like to see at a packet dump for call
> establishment.

Emailed privately, hope that's ok.
Comment 3 Mikhail Zabaluev nokia 2009-10-20 19:00:09 UTC
Thanks for the observation and the logs. Looks like we have a problem to
address...
Comment 4 Olivier Crête 2009-10-20 19:10:33 UTC
From your log, I can see what the problem is. Since you dont have a stun
server, it does upnp discovery up to the maximum timeout which is now set to 10
seconds.. It should be a lot shorter..
Comment 5 Mikhail Zabaluev nokia 2009-10-20 19:12:46 UTC
I didn't see anything about UPnP in the captures, might it be that the
submitter
had filtered some interesting traffic out, e.g. broadcasts?
Comment 6 Lucas Maneos (reporter) 2009-10-20 20:10:14 UTC
(In reply to comment #5)
> I didn't see anything about UPnP in the captures, might it be that the
> submitter
> had filtered some interesting traffic out, e.g. broadcasts?

Ah, yes I did, sorry :-(  I guess this is new in Fremantle, and I thought the
UPnP traffic was media-related.  On closer inspection it's 6 "M-SEARCH *"
requests originating from "User-Agent: Maemo Telepathy Stream Engine", starting
roughly 10-11 seconds before the INVITE gets sent.
Comment 7 Lucas Maneos (reporter) 2009-10-20 20:17:31 UTC
(In reply to comment #4)
> Since you dont have a stun server, it does upnp discovery

Thanks for that info, using a manual STUN setting of "stun.ekiga.net" the
INVITE is sent out almost immediately.  The call is still not properly
established, but that's a separate problem.
Comment 8 Lucas Maneos (reporter) 2009-10-22 21:14:54 UTC
(In reply to comment #7)
> The call is still not properly established, but that's a separate problem.

That was timer-related, solved after applying the suggestion in bug 5614
comment 9.
Comment 9 Olivier Crête 2009-10-26 16:26:55 UTC
I changed the default upnp timeout to 2 seconds, it should be in the next
upgrade (or the following one).
Comment 10 Lucas Maneos (reporter) 2009-10-26 16:33:12 UTC
Thanks, looking forward to testing it :-)

Silly question: would it make sense to perform the STUN/UPnP discovery once per
connection instead of before every call?
Comment 11 Olivier Crête 2009-10-26 16:34:48 UTC
(In reply to comment #10)
> Thanks, looking forward to testing it :-)
> 
> Silly question: would it make sense to perform the STUN/UPnP discovery once per
> connection instead of before every call?

Every connection uses a local port, and stun/upnp also deals with ports.
Comment 12 Mikhail Zabaluev nokia 2009-10-26 16:39:15 UTC
Even the UPnP IGD service could be added into or removed from the network over
the lifetime of a device's network connection (it's plug and play tech,
innit?), so it's not enough to discover it just once.
Comment 13 Andre Klapper maemo.org 2009-11-12 16:08:09 UTC
This has been fixed in package
farsight2 0.0.16-0maemo3+0m5
which is part of the internal build version
2009.45-7
(Note that 2009 is the year and the number after is the week.)

Any public update released with or after this build version will include the
fix.
Please verify that the new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.
Comment 14 Lucas Maneos (reporter) 2009-12-31 01:19:07 UTC
With 2.2009.51-1 the delay is down to around 3" which is a definite improvement
but not quite ideal.  The "Discover public address" option makes no difference
on this.

With a STUN server set it's nearly instant.  Is there some other way to disable
the UPnP discovery?
Comment 15 Lucas Maneos (reporter) 2009-12-31 01:21:25 UTC
*** Bug 7339 has been marked as a duplicate of this bug. ***
Comment 16 Olivier Crête 2009-12-31 17:38:11 UTC
If the stun server answers, it ignore the upnp discovery.
Comment 17 Lucas Maneos (reporter) 2010-01-02 15:51:52 UTC
Perhaps I'm a corner case as I'm not behind NAT when I'm making SIP calls so
don't need STUN, UPnP etc.  Oh well, I'll mark this VERIFIED since there's a
workaround and there's no obvious way to improve it without breaking things for
NATed cases.
Comment 18 Andre Klapper maemo.org 2010-01-14 12:28:22 UTC
The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.