maemo.org Bugzilla – Bug 5614
SIP call from n900 to n810 doesn't detect ringing/answering, n810->n900 works fine
Last modified: 2009-10-27 21:02:04 UTC
You need to
before you can comment on or make changes to this bug.
(Control Panel > General > About product)
STEPS TO REPRODUCE THE PROBLEM:
Both devices have a sip account on an asterisk pbx. Everything is on my local
When I call from n900 to n810, it should produce the dial tone and recognize
the other end has answered the phone
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: 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.
EXTRA SOFTWARE INSTALLED:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.2
(KHTML, like Gecko) Chrome/22.214.171.124 Safari/532.2
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
Created an attachment (id=1468) [details]
tcpdump on asterisk box n900->n810 (not working call)
Created an attachment (id=1469) [details]
tcpdump on asterisk box n810->n900 (working call)
Created an attachment (id=1470) [details]
raw packets tcpdump on asterisk box n900->n810 (not working call)
raw packets file this time
Created an attachment (id=1471) [details]
raw packets file tcpdump on asterisk box n810->n900 (working call)
Created an attachment (id=1472) [details]
raw packets file tcpdump on the n900 doing the n900->n810 call
I wonder if bug 5218 might be the same technical issue.
(In reply to comment #6)
> Created an attachment (id=1472) [details] [details]
> raw packets file tcpdump on the n900 doing the n900->n810 call
I see that proxy responses have a rather peculiar session timeout
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.
Thanks for this information. With some experimenting, I added
(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.
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.
A first test shows that I don't need the session-timers=refuse anymore. So feel
free to just close the issue.
(In reply to comment #9)
> Thanks for this information. With some experimenting, I added
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 126.96.36.199 (as packaged on Fedora 11) which is
supposed to contain that patch.
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
(In reply to comment #11)
> Hm, I needed that on asterisk 188.8.131.52 (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.
(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 184.108.40.206 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.