[asterisk-bugs] [Asterisk 0016107]: t38 passtrough not working with kapanga softphone and eutelia provider

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Oct 21 16:24:14 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/T.38
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-21 16:24 CDT
====================================================================== 
Summary:                    t38 passtrough not working with kapanga softphone
and eutelia provider
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
====================================================================== 

---------------------------------------------------------------------- 
 (0112589) kpfleming (administrator) - 2009-10-21 16:24
 https://issues.asterisk.org/view.php?id=16107#c112589 
---------------------------------------------------------------------- 
Based on this partial log, this is not a T.38-related problem in Asterisk,
but a problem with the service provider's SIP server that did not respond
to a SIP request that Asterisk sent. There's no way to know any more than
that without proper information being attached to the issue.

As the bug posting guidelines document, for all SIP-related issues the
following information should be uploaded as *attachments*:

# SIP problem?
Include debug output! Please include output from "sip debug" if you have a
SIP problem. This seems obvious, but apparently is not. Set debug to 4,
verbose to 4, turn on sip history and dumphistory in sip.conf and capture
all output. A packet trace from ethereal will not tell us what is happening
inside your Asterisk server, so that is not a replacement. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-21 16:24 kpfleming      Note Added: 0112589                          
======================================================================

More information about the asterisk-bugs mailing list