maemo.org Bugzilla – Bug 7339
SIP call answer takes a long time to connect
Last modified: 2009-12-31 01:21:25 UTC
You need to
before you can comment on or make changes to this bug.
SOFTWARE VERSION: Maemo 5: 1.2009.42-11.002
EXACT STEPS LEADING TO PROBLEM:
1. Register & make available SIP account (my example from voip.ms)
2. Make call to VOIP number
3. Answer call
Call should be connected and two parties talking almost instantly
Call takes 8 seconds after hitting answer to connect. The N900 displays
"Connecting" Under the sip:address for the 8 seconds it took to connect.
EXTRA SOFTWARE INSTALLED:
Lots, including stuff from Extras-testing and extras-devel.
I have a tcpdump available if necessary (specify whether you want the media as
well, or just the SIP). It basically shows the INVITE at 21:41:03, a "100
Trying" response from the N900 at 21:41:03, a "180 Ringing" response from the
N900 at 21:41:03. I believe the phone started ringing around 21:41:04. The
N900 starts sending audio packets to the advertised media RTP port at 21:41:07
(approximately the time when I hit answer on the phone)--it sent approximately
130ish packets until 21:41:12 when it sent the username and hostname to the SIP
server and got a response back on one port higher than the RTP port it was
transmitting on. It then continued sending about 89 packets on the original
RTP port until 21:41:15. At that time it sent a "200 OK" to the SIP server and
got an "ACK" back. It started transmitting on the RTP port again at 21:41:16
and within four packets started getting responses back. It was approximately
this time when the call state changed to "Connected" on the N900 and the cell
phone dialing that number finally switched from Ringing (which it had been
doing that entire time) to hearing what the N900 was picking up on the mic.
The extra 8 seconds to pick up the call really makes incoming calls fairly
difficult to receive since voicemail intercepts or human timeouts are much more
likely to occur.
I believe I had a similar experience when attempting to use sipgate.com, but at
that point I assumed it was a problem with sipgate and did not further diagnose
the problem. With voip.ms I set up a secondary softphone which did not exhibit
the problem which caused me to look into the problem.
This is because the default timeout for upnp was 10 secs (ie, it waited 10 secs
before giving up on finding a upnp router). This has been significantly reduced
in the next release (PR1.1).
*** This bug has been marked as a duplicate of bug 5523 ***