I am having an issue when an outside line is forwarding calls to a number on the 908e PRI. When the call is answered I get no audio. I am seeing a 89 Redir reason:DTE OUT OF ORDER when i run debug idsn-l2 formatted.
18:24:54.564 ISDN.L2_FMT PRI 1 ==============================================
18:24:54.564 ISDN.L2_FMT PRI 1 T Sapi:00 C/R:C Tei:00 INFO Ns:33 Nr:33 P:0
18:24:54.564 ISDN.L2_FMT PRI 1 Prot:08 CRL:2 CRV:029B
18:24:54.564 ISDN.L2_FMT PRI 1 M - 05 SETUP
18:24:54.564 ISDN.L2_FMT PRI 1 IE - 04 BEARER CAPABILITY Len=3
18:24:54.564 ISDN.L2_FMT PRI 1 80 Xfer Cap.:SPEECH
18:24:54.565 ISDN.L2_FMT PRI 1 90 Xfer Rate:64k
18:24:54.565 ISDN.L2_FMT PRI 1 A2 Layer 1:G.711 U-Law
18:24:54.565 ISDN.L2_FMT PRI 1 IE - 18 CHANNEL ID Len=3
18:24:54.565 ISDN.L2_FMT PRI 1 A1 Primary Rate
18:24:54.565 ISDN.L2_FMT PRI 1 Intfc ID:IMPLICIT
18:24:54.565 ISDN.L2_FMT PRI 1 Pref/Excl:PREFERRED
18:24:54.565 ISDN.L2_FMT PRI 1 D-Chan Indicated:NO
18:24:54.565 ISDN.L2_FMT PRI 1 Chan. Sel:FOLLOWS
18:24:54.565 ISDN.L2_FMT PRI 1 83 Numb/Map:NUMBER
18:24:54.566 ISDN.L2_FMT PRI 1 81 Channel:1
18:24:54.566 ISDN.L2_FMT PRI 1 IE - 6C CALLING PARTY # Len=12
18:24:54.566 ISDN.L2_FMT PRI 1 00 Numb. Type:UNKNOWN
18:24:54.566 ISDN.L2_FMT PRI 1 Numb. Plan:UNKNOWN
18:24:54.566 ISDN.L2_FMT PRI 1 80 Presentation:ALLOWED
18:24:54.566 ISDN.L2_FMT PRI 1 Screening:USER PROVIDED
18:24:54.566 ISDN.L2_FMT PRI 1 Ph.# 16265551212
18:24:54.566 ISDN.L2_FMT PRI 1 IE - 70 CALLED PARTY # Len=5
18:24:54.566 ISDN.L2_FMT PRI 1 80 Numb. Type:UNKNOWN
18:24:54.566 ISDN.L2_FMT PRI 1 Numb. Plan:UNKNOWN
18:24:54.566 ISDN.L2_FMT PRI 1 Ph.# 7700
18:24:54.567 ISDN.L2_FMT PRI 1 IE - 74 REDIRECTING # Len=14
18:24:54.567 ISDN.L2_FMT PRI 1 00 Numb. Type:UNKNOWN
18:24:54.567 ISDN.L2_FMT PRI 1 Numb. Plan:UNKNOWN
18:24:54.567 ISDN.L2_FMT PRI 1 00 Presentation:ALLOWED
18:24:54.567 ISDN.L2_FMT PRI 1 Screening:USER PROVIDED
18:24:54.567 ISDN.L2_FMT PRI 1 89 Redir reason:DTE OUT OF ORDER
18:24:54.567 ISDN.L2_FMT PRI 1 Ph.# 16265557700
18:24:54.585 ISDN.L2_FMT PRI 1 ==============================================
Garabed, I wouldn't expect that message to have anything to do with audio connection. If anything, the setup of the call might fail, but that would disconnect the call all together. I would suggest opening a ticket with support if you haven't already for a more in depth troubleshooting. Thanks
Garabedy,
The Problem:
When making audio calls using SIP the phone rings but when it is answered there is only one way audio or no way audio.
What Cause One Way Audio:
The cause of one way audio is a combination of NAT and STUN
How to Achieve Two Way Audio:
The solution is far simpler than you might think. Do is the following:
On your VoIP switch reduce the SIP port range. How many SIP calls do you think you will have going at any one time max?
Most of you reading this will be 10 at a guess, maybe 20. Reduce the max range to 49162 giving me 10 ports.
On your NAT device set up port forwarding for the 10 ports to your VoIP switch.
The reason this works is because when the VoIP learns it is behind a symmetric NAT via STUN it will instead tell the remote
switch to send audio to it’s local (non NATted) ports. Since we reduced the port range to 10 and have now opened these ports
manually on the NAT it will allow the audio to come in. This will eliminate one way audio.
Garabedy, did you ever figure out what the problem was? I have the same issue going on and am struggling to figure out why the audio is being lost.
I read Michael56's response but that doesn't apply to me because my 908e doesn't have any NAT. I have a direct SIP peering trunk between our PSTN SBC and the 908e. I had one of our techs do a drop and insert with a T-1 tester and verified audio was present on the call forward leg. I set up a PCAP on T01 and didn't have any audio coming out on the call forwarded leg to the PSTN. Somewhere in the Adtran it seems to be losing that RTP. I checked the SIP messaging and the RTP contact IPs are all correct and routing is good between the two end points.
By any chance are the CODEC's the same? I had trouble with a mismatch in which audio codec was elected for use with each phone call.
For example: I was using G.711a and G.711u on most of the SIP hardware, and overlooked that a branch office was only using G.729a with their desktop sets.
Calls would route, even had correct caller-id but once the called party had answered, no audio in either direction.
I paired down what audio CODEC's would be used, and had reliable audio after the changes where made.
Just an idea ...