Bug 5614 - SIP call from n900 to n810 doesn't detect ringing/answering, n810->n900 works fine
: SIP call from n900 to n810 doesn't detect ringing/answering, n810->n900 works...
Status: RESOLVED WORKSFORME
Product: Chat & Call & SMS
SIP
: 5.0/(1.2009.41-10)
: All Linux
: Low normal with 1 vote (vote)
: ---
Assigned To: rtcomm@maemo.org
: sip-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-10-20 00:31 UTC by Koos Vriezen
Modified: 2009-10-27 21:02 UTC (History)
4 users (show)

See Also:


Attachments
tcpdump on the n900 doing the n900->n810 call (19.55 KB, text/plain)
2009-10-20 00:34 UTC, Koos Vriezen
Details
tcpdump on asterisk box n900->n810 (not working call) (263.25 KB, text/plain)
2009-10-20 00:35 UTC, Koos Vriezen
Details
tcpdump on asterisk box n810->n900 (working call) (139.93 KB, text/plain)
2009-10-20 00:36 UTC, Koos Vriezen
Details
raw packets tcpdump on asterisk box n900->n810 (not working call) (37.46 KB, application/octet-stream)
2009-10-20 10:07 UTC, Koos Vriezen
Details
raw packets file tcpdump on asterisk box n810->n900 (working call) (19.77 KB, application/octet-stream)
2009-10-20 10:08 UTC, Koos Vriezen
Details
raw packets file tcpdump on the n900 doing the n900->n810 call (28.51 KB, application/octet-stream)
2009-10-20 10:09 UTC, Koos Vriezen
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Koos Vriezen (reporter) 2009-10-20 00:31:51 UTC
SOFTWARE VERSION:
(Control Panel > General > About product)
1.2009.41.10

STEPS TO REPRODUCE THE PROBLEM:
Both devices have a sip account on an asterisk pbx. Everything is on my local
net.

EXPECTED OUTCOME:
When I call from n900 to n810, it should produce the dial tone and recognize
the other end has answered the phone

ACTUAL OUTCOME:
I don't hear ring tones (only if I set dtmfmode to inbounds) and when the other
end answers I hear the audio but the n900 keeps on reporting that it's dialing.

Also, asterisk reports this error:
WARNING[30831]: chan_sip.c:3508 retrans_pkt: Maximum retries exceeded on
transmission 9399ec2d-3796-122d-3f83-0026cc770000 for seqno 121874959 (Critical
Response) -- See doc/sip-retransmit.txt.
Indeed when I look at the tcpdump, I see that there is no ACK response after
100 Trying. The suggestions in sip-retransmit.txt all talk about lost packages,
but a tcpdump on the n900 shows that Trying/Ringing is received.

REPRODUCIBILITY:
(always/sometimes/once)
always

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.2
(KHTML, like Gecko) Chrome/4.0.222.5 Safari/532.2
Comment 1 Koos Vriezen (reporter) 2009-10-20 00:34:06 UTC
Created an attachment (id=1467) [details]
tcpdump on the n900 doing the n900->n810 call

n900 is 192.168.1.101
n810 is 192.168.1.102
asterisk is 192.168.1.50
Comment 2 Koos Vriezen (reporter) 2009-10-20 00:35:24 UTC
Created an attachment (id=1468) [details]
tcpdump on asterisk box n900->n810 (not working call)
Comment 3 Koos Vriezen (reporter) 2009-10-20 00:36:07 UTC
Created an attachment (id=1469) [details]
tcpdump on asterisk box n810->n900 (working call)
Comment 4 Koos Vriezen (reporter) 2009-10-20 10:07:40 UTC
Created an attachment (id=1470) [details]
raw packets tcpdump on asterisk box n900->n810 (not working call)

raw packets file this time
Comment 5 Koos Vriezen (reporter) 2009-10-20 10:08:29 UTC
Created an attachment (id=1471) [details]
raw packets file tcpdump on asterisk box n810->n900 (working call)
Comment 6 Koos Vriezen (reporter) 2009-10-20 10:09:16 UTC
Created an attachment (id=1472) [details]
raw packets file tcpdump on the n900 doing the n900->n810 call
Comment 7 Andre Klapper maemo.org 2009-10-20 12:39:09 UTC
I wonder if bug 5218 might be the same technical issue.
Comment 8 Mikhail Zabaluev nokia 2009-10-20 14:01:27 UTC
(In reply to comment #6)
> Created an attachment (id=1472) [details] [details]
> raw packets file tcpdump on the n900 doing the n900->n810 call

Thanks.
I see that proxy responses have a rather peculiar session timeout
specification:

Require: timer
Session-Expires: -1;refresher=uas

The "already expired" timeout may get our Sofia-SIP stack into confusion about
session state. The stack could detect this case and ignore the timeout, so
leaving the bug open as a low-priority exercise.
Comment 9 Koos Vriezen (reporter) 2009-10-20 22:36:30 UTC
Thanks for this information. With some experimenting, I added

session-timers=refuse

(originate didn't make a difference) in sip.conf for this phone and see now no
"Session-Expires" in the wireshark full text export.
Calls from n900 to n810 works fine now.

Thanks again!
Comment 10 Koos Vriezen (reporter) 2009-10-26 20:36:09 UTC
Looks like issue is related to https://issues.asterisk.org/view.php?id=15403
Since I run debian/testing, I opened a BR@debian and they promptly updated
asterisk to 1.6.0-rc3 in sid.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552336

A first test shows that I don't need the session-timers=refuse anymore. So feel
free to just close the issue.
Comment 11 Lucas Maneos 2009-10-27 02:59:15 UTC
(In reply to comment #9)
> Thanks for this information. With some experimenting, I added
> 
> session-timers=refuse

Thanks for the tip btw :-)

(In reply to comment #10)
> Looks like issue is related to https://issues.asterisk.org/view.php?id=15403
> [...]
> A first test shows that I don't need the session-timers=refuse anymore.

Hm, I needed that on asterisk 1.6.1.6 (as packaged on Fedora 11) which is
supposed to contain that patch.
Comment 12 Mikhail Zabaluev nokia 2009-10-27 14:25:14 UTC
If it works with an up-to-date Asterisk version, we have no immediate problem
anymore. Thanks for your timely cooperation in investigating the issue.

I should file a Sofia-SIP bug about ignoring bogus timer headers, in my copious
free time...
Comment 13 Mikhail Zabaluev nokia 2009-10-27 14:27:09 UTC
(In reply to comment #11)
> Hm, I needed that on asterisk 1.6.1.6 (as packaged on Fedora 11) which is
> supposed to contain that patch.

Interesting. If you still see the problem and you can see the Session-Expires
header is no longer malformed by Asterisk, go ahead and reopen the bug, or
better, file a new one.
Comment 14 Lucas Maneos 2009-10-27 21:02:04 UTC
(In reply to comment #13)
> If you still see the problem and you can see the Session-Expires
> header is no longer malformed by Asterisk

It still specifies -1 delta-seconds, but that's actually a different asterisk
bug (<https://issues.asterisk.org/view.php?id=15621>), patch committed 4 days
after the 1.6.1.6 release which explains why I haven't got it.  Perhaps the
Debian package already includes it, but I'm too lazy to check right now.