[asterisk-bugs] [Asterisk 0016107]: Kapanga softphone exposes bug in SIP channel driver
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri Oct 23 16:22:22 CDT 2009
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16107
======================================================================
Reported By: darkbasic
Assigned To: kpfleming
======================================================================
Project: Asterisk
Issue ID: 16107
Category: Channels/chan_sip/Interoperability
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Asterisk Version: SVN
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.2
SVN Revision (number only!): 224859
Request Review:
======================================================================
Date Submitted: 2009-10-20 18:12 CDT
Last Modified: 2009-10-23 16:22 CDT
======================================================================
Summary: Kapanga softphone exposes bug in SIP channel driver
Description:
If kapanga has direct access to the provider (no asterisk) I can send faxes
flawlessly, otherwise I get errors:
-- Registered SIP '159' at 192.168.1.44 port 5060
> Saved useragent "Kapanga Softphone Desktop Windows
1.00/2178d+1256057634_0022FA19F312_001377B41BFA" for peer 159
[Oct 21 00:53:58] NOTICE[12729]: chan_sip.c:17790
handle_response_peerpoke: Peer '159' is now Reachable. (147ms / 2000ms)
== Using SIP RTP CoS mark 5
== Using UDPTL CoS mark 5
-- Executing [<exten>@phones-sip:1] Dial("SIP/159-09614f80",
"SIP/eutelia/<exten>,60") in new stack
== Using SIP RTP CoS mark 5
== Using UDPTL CoS mark 5
-- Called eutelia/<exten>
<< [ TYPE: Control (4) SUBCLASS: Unknown control '14' (14) ]
[SIP/eutelia-09610a90]
-- SIP/eutelia-09610a90 is making progress passing it to
SIP/159-09614f80
[Oct 21 00:54:04] NOTICE[12753]: rtp.c:1130 process_rfc3389: Comfort noise
support incomplete in Asterisk (RFC 3389). Please turn off on client if
possible. Client IP: 192.168.1.44
<< [ TYPE: Unknown Frametype '10' (10) SUBCLASS: Unknown Subclass (114) ]
[SIP/159-09614f80]
<< [ TYPE: Unknown Frametype '10' (10) SUBCLASS: Unknown Subclass (114) ]
[SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/eutelia-09610a90]
<< [ TYPE: Unknown Frametype '10' (10) SUBCLASS: Unknown Subclass (114) ]
[SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/159-09614f80]
<< [ TYPE: Unknown Frametype '10' (10) SUBCLASS: Unknown Subclass (114) ]
[SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/eutelia-09610a90]
<< [ TYPE: Control (4) SUBCLASS: Answer (4) ] [SIP/eutelia-09610a90]
-- SIP/eutelia-09610a90 answered SIP/159-09614f80
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/eutelia-09610a90]
<< [ TYPE: Unknown Frametype '10' (10) SUBCLASS: Unknown Subclass (114) ]
[SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/159-09614f80]
<< [ TYPE: Unknown Frametype '10' (10) SUBCLASS: Unknown Subclass (114) ]
[SIP/159-09614f80]
<< [ TYPE: Control (4) SUBCLASS: T38_Parameters/Negotiation Requested (24)
] [SIP/eutelia-09610a90]
<< [ TYPE: Control (4) SUBCLASS: Unknown control '20' (20) ]
[SIP/eutelia-09610a90]
<< [ TYPE: Control (4) SUBCLASS: T38_Parameters/Negotiated (24) ]
[SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/159-09614f80]
<< [ TYPE: Control (4) SUBCLASS: T38_Parameters/Negotiated (24) ]
[SIP/eutelia-09610a90]
<< [ TYPE: Unknown Frametype '10' (10) SUBCLASS: Unknown Subclass (114) ]
[SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/159-09614f80]
<< [ TYPE: Control (4) SUBCLASS: T38_Parameters/Terminated (24) ]
[SIP/eutelia-09610a90]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/159-09614f80]
<< [ TYPE: Unknown Frametype '10' (10) SUBCLASS: Unknown Subclass (114) ]
[SIP/159-09614f80]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/159-09614f80]
[Oct 21 00:54:35] WARNING[12729]: chan_sip.c:3557 retrans_pkt: Maximum
retries exceeded on transmission
781afd3767ab81d160f2ef2c6fd30037 at 217.133.76.61 for seqno 101 (Critical
Response) -- See doc/sip-retransmit.txt.
[Oct 21 00:54:35] WARNING[12729]: chan_sip.c:3584 retrans_pkt: Hanging up
call 781afd3767ab81d160f2ef2c6fd30037 at 217.133.76.61 - no reply to our
critical packet (see doc/sip-retransmit.txt).
== Spawn extension (phones-sip, <exten>, 1) exited non-zero on
'SIP/159-09614f80'
This is my sip.conf:
[general]
t38pt_udptl=yes
language=it
context=default
bindport=5060
externhost=<host>
externrefresh=5
localnet=192.168.1.0/255.255.255.0
nat=yes
register=<number>:<password>@voip.eutelia.it:5060/<number>
[159]
language=it
type=friend
bindport=5060
context=phones-sip
host=dynamic
secret=<password>
nat=no
t38pt_udptl=yes
qualify=yes
[eutelia]
language=it
type=friend
host=voip.eutelia.it
username=<number>
fromuser=<number>
secret=<password>
port=5060
nat=yes
qualify=yes
canreinvite=no ;asterisk is always used as media proxy, I tried also with
yes
dtmfmode=rfc2833
insecure=invite,port
context=eutelia-in
t38pt_udptl=yes
======================================================================
----------------------------------------------------------------------
(0112686) kpfleming (administrator) - 2009-10-23 16:22
https://issues.asterisk.org/view.php?id=16107#c112686
----------------------------------------------------------------------
OK, it is as I suspected, this is not a T.38 issue at all. There are two
problems here.
First, the Kapanga softphone sent us an INVITE, which we declined as it
required authentication. It ACKed our decline, and all was good.
Second, it resent the INVITE (CSeq 2), with proper authentication.
Asterisk sent 100 Trying, and proceeded to process through the dialplan and
place a call out to your provider.
When the provider sent 183 Session Progress, Asterisk sent 183 Session
Progress to Kapanga. Immediately after that, Kapanga sent *another* INVITE
(Cseq 3), identical to the previous one. There is no reason for it to do
this, but it should not be harmful.
Because the previous INVITE (CSeq 2) is still in process, Asterisk
properly responded with 491 Request Pending to the INVITE (CSeq 3). This
response was retransmitted four times, and the Kapanga softphone never
ACKed this response. Failing to do is a SIP protocol violation, and
Asterisk would normally drop the call one it has retransmitted six times.
However, after the fourth retransmission, the Kapanga softphone
retransmitted the INVITE (CSeq 3), apparently assuming it had not been
received (even though Asterisk had already replied to it four times).
Unfortunately, instead of Asterisk immediately responding 491 Request
Pending, it sent 100 Trying, followed by 491 Request Pending. While this is
not ideal, it is not harmful.
The Kapanga softphone *still* did not ACK the 491 Request Pending, and
eventually Asterisk tore down the call.
So there are two concerns here with the Kapanga softphone: first, it
should not send a reINVITE while there is a pending INVITE, but if it is
going to do that, it should properly respect the 491 Request Pending final
response from Asterisk and ACK it. Failing to do is a protocol violation,
and Asterisk can rightly assume that either the remote endpoint has
disappeared (and is not receiving the response) or has failed in some way.
There is a minor bug here in Asterisk that it shouldn't send 100 Trying
for an INVITE that is going to get a 491 response anyway, but that is
trivial.
Issue History
Date Modified Username Field Change
======================================================================
2009-10-23 16:22 kpfleming Note Added: 0112686
======================================================================
More information about the asterisk-bugs
mailing list