maemo.org Bugzilla – Full Text Bug Listing
|Summary:||High latency between UI and SIP events being sent|
|Product:||[Maemo Official Applications] Chat & Call & SMS||Reporter:||Lucas Maneos <maemo>|
|Status:||VERIFIED FIXED||QA Contact:||sip-bugs|
|Priority:||Low||CC:||andre_klapper, in-maemo, mikhail.zabaluev, olivier.crete|
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.
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.
(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.
Thanks for the observation and the logs. Looks like we have a problem to address...
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..
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?
(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.
(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.
(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.
I changed the default upnp timeout to 2 seconds, it should be in the next upgrade (or the following one).
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?
(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.
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.
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.
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?
*** Bug 7339 has been marked as a duplicate of this bug. ***
If the stun server answers, it ignore the upnp discovery.
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.
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.