[Home]

Summary:ASTERISK-10602: Asterisk SIP Connections to systems that support t38 fax detection may fail
Reporter:Jon Webster (jon)Labels:
Date Opened:2007-10-23 14:06:31Date Closed:2008-03-19 12:26:23
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) sip-debug.txt
Description:I've got a list of about 5 Direct Voice or IVR numbers right now that we can not call using asterisk SIP.

Using SIP, the following errors are logged (full debug attached in sip-debug.txt):

[Oct 22 14:49:14] WARNING[6327]: chan_sip.c:5017 process_sdp: Unsupported SDP me
dia type in offer: image 19596 udptl t38
   -- SIP/bandwidth-08444138 is making progress passing it to SIP/jon-b5e00468
[Oct 22 14:49:24] WARNING[6327]: chan_sip.c:5017 process_sdp: Unsupported SDP me
dia type in offer: image 19596 udptl t38
   -- SIP/bandwidth-08444138 answered SIP/jon-b5e00468
 == Spawn extension (local, dial-12128482036, 6) exited non-zero on 'SIP/ingramoffice2-b5e00468'
[Oct 22 14:49:26] WARNING[6327]: chan_sip.c:12528 handle_response: Remote host can't match request BYE to call '4944de5b1fc061d90823411753ee8fc4@4.68.250.148'. Giving up.


Calling with IAX2 and ZAP works fine, the numbers ring and the IVR or user answers.

****** ADDITIONAL INFORMATION ******

sip.conf
=========
[general]
context=inbound
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
domain=pbx.mydomain.local,local
pedantic=no
videosupport=yes
disallow=all
allow=ulaw
allow=gsm
allow=h263
allowsubscribe=yes
notifybusy=yes
limitonpeer=yes
notifyhold=yes

[authentication]

[jon]
regextet=555
callerid="Jon" <555>

secret=password
type=friend
host=dynamic
nat=yes
canreinvite=no
context=local
qualify=yes

call-limit=100
busy-limit=99
Comments:By: Jon Webster (jon) 2007-10-26 13:18:45

T38 is not enabled, but the other side is sending T.38 data in the SDP and chan_sip presently can't "fall back" to an audio codec like ulaw and thus fails.
By: Olle Johansson (oej) 2007-11-19 12:39:44.000-0600

Hmm. We could handle this properly by simply refusing the T.38 offer and accept the audio  offer as usual.  What we can't do is fall back to G711 after a T.38 transmission, but we can make sure to handle this correctly, like we handle video offers that can't be accepted.
By: Joshua C. Colp (jcolp) 2008-02-14 13:02:00.000-0600

oej: The thing for this scenario though is that a reinvite is not involved, they are sending T38 back in the 200 OK to the original INVITE... how can we handle that?
By: Joshua C. Colp (jcolp) 2008-03-19 12:26:22

I've researched this and come to the conclusion that there is currently nothing in chan_sip we can do to accomodate this. We send out an initial INVITE with audio, but instead of getting audio in the 200 OK the remote side sends T38. We can't "fall back" so we terminate the call.