I am having problems connecting incoming calls from my VOIP Provider (GoTalk.com.au) through to my Sipura 2100 ATA via Asterisk (v1.2.2…5).
My scenario is this:
I have an Asterisk server (Debian Sarge) with the following friends:
- Sipura 2100 ATA
- sipgate.co.uk
- astratel.com.au
- gotalk.com.au
Now when an incoming call comes in via sipgate or astratel, the native bridging function of Asterisk works perfectly. Asterisk takes itself out of the loop allowing the RTP packets to flow seamlessly between the originator of the call (say sipgate) and the Sipura 2100 ATA.
When I do this for GoTalk, the following T.38 fax weirdness happens. (The configs for all my VOIP providers are identical except for required username / password):
The following trace is the debug from the Asterisk Open Source PABX console:
– Executing Answer(“SIP/09426999-0e91”, “”) in new stack (Someone is ringing 09426999… my GoTalk VOIP number)
-- Executing Dial("SIP/09426999-0e91", "SIP/aussie|30") in new stack (Forward the call to aussie as per dial plan. aussie is a SIPURA2100 ATA registered with the Asterisk server)
-- Called aussie
-- SIP/aussie-5a70 is ringing (Sipura ATA phone is ringing... I can hear it!)
-- SIP/aussie-5a70 answered SIP/09426999-0e91 (I answer it...)
-- Attempting native bridge of SIP/09426999-0e91 and SIP/aussie-5a70 (Asterisk tries to bridge GoTalk and the SIPURA2100 taking itself out of the loop)
Mar 11 05:54:45 WARNING[4499]: chan_sip.c:3478 process_sdp: Unknown SDP media type in offer: image 4308 RTP/AVP t38 (And this appears to fail because GoTalk is telling Asterisk this call is a T38 FAX ???)
Mar 11 06:16:38 WARNING[4613]: rtp.c:460 ast_rtp_read: RTP Read too short
Mar 11 05:54:46 WARNING[4499]: chan_sip.c:9549 handle_response_invite: Re-invite to non-existing call leg on other UA. SIP dialog '34343132656235363466656600000000@ens.com’. Giving up.
(These messages occur after Sipura 2100 ATA handset is hung up) =>
asteriskpbx*CLI>
== Spawn extension (incoming, 09426999, 2) exited non-zero on ‘SIP/09426999-0e91’
– Got SIP response 481 “Call Leg/Transaction Does Not Exist” back from 203.166.7.169
I have the SIP debug also if anyone is interested. Here is an excerpt during the native bridge establishment.
asteriskpbx*CLI>
<-- SIP read from 203.166.7.169:5060:
INVITE sip:09426999@81.81.16.186:5060 SIP/2.0
Via: SIP/2.0/UDP 203.166.7.169:5060;branch=z9hG4bK44125e04-1340-102
To: sip:09426999@81.81.16.186:5060;tag=as4967eb08
From: “Gotalk” sip:0409152999@203.166.7.169:5060;tag=ff004af2-ensOBJ01340 (PSTN number=0409152999)
Call-ID: 34343132663236363531303100000000@ens.com
CSeq: 52680 INVITE
Max-Forwards: 70
Contact: sip:0409152999@203.166.7.169:5060
User-Agent: Entice_2.2
Content-Type: application/sdp
Content-Length: 265
v=0
o=- 4278209266 4278209267 IN IP4 203.166.7.169
s=ENS Session
c=IN IP4 203.166.7.167
t=0 0
m=image 5200 RTP/AVP t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxRateManagement:transferredTCF
a=sendrecv
— (11 headers 12 lines)—
Using INVITE request as basis request - 34343132663236363531303100000000@ens.com
Sending to 203.166.7.169 : 5060 (non-NAT)
Mar 11 06:24:53 WARNING[4597]: chan_sip.c:3478 process_sdp: Unknown SDP media type in offer: image 5200 RTP/AVP t38
Transmitting (no NAT) to 203.166.7.169:5060:
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 203.166.7.169:5060;branch=z9hG4bK44125e04-1340-102;received=203.166.7.169
From: “Gotalk” sip:0409152999@203.166.7.169:5060;tag=ff004af2-ensOBJ01340
To: sip:09426999@81.81.16.186:5060;tag=as4967eb08
Call-ID: 34343132663236363531303100000000@ens.com
CSeq: 52680 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: sip:09426999@81.81.16.186
Content-Length: 0
X-Asterisk-HangupCause: Normal Clearing
There appears to be some confusion with the Native bridge between GoTalk / Asterisk. Somehow a T.38 fax image type is confusing the audio call transfer.
If anyone has an idea or a solution, that would be great.
I can provide sip.conf and dialplan info if people would like. But as I’ve said above, the native bridge works with all my other providers and the fundamental configuration is the same for GoTalk.
Many thanks,
Geoff.
P.S. I’ve changed IP addresses, SIP id’s and phone numbers above to protect the innocent.