E&M T1 not getting caller-id
Submitted by jmlivingston on Wed, 05/21/2008 - 1:04pm.
I have a Sangoma A101 in a Trixbox CE 2.6 pbx, with 17 channels configured as e&m connecting to XO. This setup is not receiving any caller-id information from the telco, and I've confirmed (several times!) with their techs that they are passing on to us any caller-id information they receive. I'm guessing that the problem may be due to Trixbox answering the calls too quickly, before the CID information gets passed between the first and second ring.
Can anyone tell me how to get Trixbox to wait until the 2nd ring before answering the call?
Thanks!
John
WAIT
Wed, 05/21/2008 - 1:50pm
Wait(seconds) ; write as argument the period of time you want to be waited
exten => s,1,Wait,1
place that in the needed place inside your extensions.conf. Not sure if you can use a value less then 1, but for me with my pri's with our carrier, i buffer the invite for 100ms waiting for the qsig931 info.
This is wrong. No amount of
Wed, 05/21/2008 - 5:51pm
This is wrong. No amount of wait will help. T1's don't provide callerid during ring like a loop start line -
CallerID is inband or on the D Channel and it must be provisioned - In your case it will be presented at the wink. If you are getting DNIS and not callerid, telco is not sending it. On our circuits it appears as *7142285400*2222* - Asterisk know how to handle this.
Put something like this in you dialplan:
exten => _X.,n,Verbose(NEW CALL FROM:[${CALLERID(number)}] FOR:[${EXTEN}]
I'd double check your zaptel & zapata settings, then call telco.
Bart
Qsig931
Wed, 05/21/2008 - 6:09pm
True, the IE info does come down either the d-chan or inband. Didn't think about inband.
I just wanted to have the trix wait a few moments for the rest of the Qsig931 info to come down, that will usually comes later 10-500ms.
without the wait, mine just replicated the number in to the name field.
with the wait before the internal plan, debug showed "pending" as the name.
with the wait before the signal pick up, the name was injected into the string.
But then, i do take my pri's (all 4) and convert them to sip with a cisco 5350 for all of our sip devices to use.
so it's 4 pri in cisco 5350-> audiocodes ncite sbc -> asterisk - sipx - genband m6 - sagem-interstar t.38 foip server.
Good catch Bart, you probably saved him alot of time.
The open source model strikes again!
Clarifications
Wed, 05/21/2008 - 8:45pm
There is some very inaccurate information in response to this problem.
Bart's post is the only accurate one. The caller ID, number only is being sent inband.
You need to find out exactly how many digits the carrier is sending and what start and stop characters are being used.
Then you can use Bart's example to have Asterisk strip the decoded DTMF digits and place them into the string.
Qsig is a PRI concept and FXS caller ID is only used on analog circuits.
E&M wink start is fully supported by the Zaptel driver.
--
Scott
aka "Skyking"
With a RBS(Robbed-bit) T1(in
Wed, 05/21/2008 - 8:57pm
With a RBS(Robbed-bit) T1(in other words, not a PRI) the CallerID(Called
ANI) is sent in the digits and come across in Asterisk as part of the
extension. It is not standard, you do need to ask for it to be enabled and
you usually have to specify how you want it.
A standard way of receiving ANI on a RBS T1 is this: *NXXNXXXXXX*DNIS where
NXXNXXXXXX is the callerID and the DNIS is the last 4 digits of the number
the caller dialed.
There is no option of receiving callerIDname with RBS T1s but you do get
that 24th channel to use for voice that you don't get with a PRI.
Hope this helps,
This may help when you are
Wed, 05/21/2008 - 9:13pm
This may help when you are talking to your carrier.
Zaptel uses the RBS term. To your telco this is bizaroo Asterisk world stuff and is jargon from the Zaptel world.
There are two signaling bits on each channel of a T1 line called A and B. The state of these bits is set by "robbing" or stealing small amounts of data from the voice PCM stream. These bits are used to encode electrical signaling (IE: E&M) such as ringing, off hook, on hook and battery reversal for transport in the t-carrier (t1 or DS-1 line).
Unless the telco guy is older than dirt (like me) he is not going to know what Robbed Bit or RBS means. The Zapata guys where telco heads too when this all started and may explain the confusing terminology.
Here is the relevant telco speak:
Inband = Tones (DTMF) ard electrical signals are used for signaling ANI and CID
E&M = Trunk Type
Start = Wink (E&M could be immediate but almost is never provisioned this way
Digits fed = This is the number of DTMF digits transmitted
ANI format = The exact sequence of DTMF digits used to send your DID and CID info
--
Scott
aka "Skyking"
skynhigh quit while your
Wed, 05/21/2008 - 9:25pm
skynhigh quit while your behind:
Robbed-bit signaling (RBS) is a specific type of Channel Associated Signaling in use in North America on T1 trunks, and perhaps elsewhere in the world.
RBS was developed at the time that AT&T was moving from analog trunks onto digital equipment. This permitted AT&T to run 24 digital phone lines on the same number of wires that 2 analog phone lines would have taken, saving money and improving call quality, without the high cost of frequency-division multiplexing.
Reference:
http://en.wikipedia.org/wiki/Robbed-bit_signaling
Quote:
Inband = Tones (DTMF) ard electrical signals are used for signaling ANI and CID
Wrong as suggested by the name DTMF are AUDIO tones
Quote:
E&M = Trunk Type
Start = Wink (E&M could be immediate but almost is never provisioned this way
WRONG: Trunk type would be a T1 or DS1 E&M weather wink or immediate are signalling.
Here is what sparkles the Telco lady will know
Its a t1
Biff the telco guy which I imagine what the shyhigh guy is will know how to plug in wires and maybe plug in a meter or laptop and read pass or fail you will note a monkey can do this.
Sparky the engineer will know framing and signalling but will unlikely know weather it is immediate or wink unless you get lucky.
His job is to sit at the MDF and push a button and say well we looped up our equipment it is your fault.... It likely is your fault by the way as you hired a wire monkey like dude above or decided to go at it your self rather than getting someone who knows his head from a donkey and can get you up with as little telco interaction as possible.
Ok, I m trying to make it
Wed, 05/21/2008 - 9:45pm
Ok, I m trying to make it easier on the OP not harder. I had a typo, which I hate (sorry).
Quote:
Inband = Tones (DTMF) ard electrical signals are used for signaling ANI and CID
Should have read:
Quote:
Inband = Tones (DTMF) and electrical signals are used for signaling ANI and CID
Quote:
Trunk type would be a T1 or DS1 E&M weather wink or immediate are signalling
This is more confusing that my OP. Provisioner's associate signaling with trunk type. Each trunk of the T1 (or DS-1 if you will) has Channel Associated Signaling.
My original point is that "Robbed Bit" or RBS is an arcane telco term that will probably confuse your carrier. In my post there is a brief explanation of what "Bit Robbing" is actually doing.
I only responded to this to fix my post which had a mistake in it. I hardly see the need for insults.
Now where did I leave my meter and my butt set? Scratching head.
Scott
--
Scott
aka "Skyking"
Still not working! :(
Fri, 05/23/2008 - 8:53am
I've removed the wait statements and just tried adding this
exten => _X.,n,Verbose(NEW CALL FROM:[${CALLERID(number)}] FOR:[${EXTEN}]
to my extensions.conf file as per Bart's recommendation and it didn't help. Here's what the logs kicked back out to me:
-- Executing [7725@from-zaptel:1] Set("Zap/16-1", "DID=7725") in new stack
-- Executing [7725@from-zaptel:2] NoOp("Zap/16-1", "Next line evaluates recommendation from Trixbox Forum") in new stack
-- Executing [7725@from-zaptel:3] Verbose("Zap/16-1", "NEW CALL FROM:[") in new stack
NEW CALL FROM:[
-- Executing [7725@from-zaptel:4] Goto("Zap/16-1", "s|1") in new stack
-- Goto (from-zaptel,s,1)
-- Executing [s@from-zaptel:1] NoOp("Zap/16-1", "Entering from-zaptel with DID == 7725") in new stack
-- Executing [s@from-zaptel:2] Ringing("Zap/16-1", "") in new stack
-- Executing [s@from-zaptel:3] Wait("Zap/16-1", "4") in new stack
== Manager 'admin' logged off from 127.0.0.1
-- Executing [s@from-zaptel:4] Set("Zap/16-1", "DID=7725") in new stack
-- Executing [s@from-zaptel:5] NoOp("Zap/16-1", "DID is now 7725") in new stack
-- Executing [s@from-zaptel:6] GotoIf("Zap/16-1", "1?zapok:notzap") in new stack
-- Goto (from-zaptel,s,9)
-- Executing [s@from-zaptel:9] NoOp("Zap/16-1", "Is a Zaptel Channel") in new stack
-- Executing [s@from-zaptel:10] Set("Zap/16-1", "CHAN=16-1") in new stack
-- Executing [s@from-zaptel:11] Set("Zap/16-1", "CHAN=16") in new stack
-- Executing [s@from-zaptel:12] Macro("Zap/16-1", "from-zaptel-16|7725|1") in new stack
-- Executing [s@from-zaptel:13] NoOp("Zap/16-1", "Returned from Macro from-zaptel-16") in new stack
-- Executing [s@from-zaptel:14] Goto("Zap/16-1", "from-pstn|7725|1") in new stack
-- Goto (from-pstn,7725,1)
-- Executing [7725@from-pstn:1] Set("Zap/16-1", "__FROM_DID=7725") in new stack
-- Executing [7725@from-pstn:2] GotoIf("Zap/16-1", "0 ?cidok") in new stack
-- Executing [7725@from-pstn:3] Set("Zap/16-1", "CALLERID(name)=") in new stack
-- Executing [7725@from-pstn:4] NoOp("Zap/16-1", "CallerID is "" <>") in new stack
-- Executing [7725@from-pstn:5] Goto("Zap/16-1", "ivr-6|s|1") in new stack
-- Goto (ivr-6,s,1)
Here are copies of my config files:
zapata.conf:
;
; Zapata telephony interface
;
; Configuration file
[trunkgroups]
[channels]
language=en
context=from-zaptel
signalling=fxs_ks
rxwink=300 ; Atlas seems to use long (250ms) winks
;
; Whether or not to do distinctive ring detection on FXO lines
;
;usedistinctiveringdetection=yes
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
;echotraining=800
rxgain=0.0
txgain=0.0
group=0
callgroup=1
pickupgroup=1
immediate=no
;faxdetect=both
faxdetect=incoming
;faxdetect=outgoing
;faxdetect=no
;Include genzaptelconf configs
#include zapata-auto.conf
group=1
;Include AMP configs
#include zapata_additional.conf
and zaptel.conf:
# Autogenerated by /usr/local/sbin/sangoma/setup-sangoma -- do not hand edit
# Zaptel Channels Configurations (zaptel.conf)
#
loadzone=us
defaultzone=us
#Sangoma A101 port 1 [slot:6 bus:0 span:1]
span=1,0,0,esf,b8zs
#fxsks=1-7
e&m=8-24
We're getting ready to get on a conference call with the telco and troubleshoot this, but I wanted to make sure that I've exhausted all the possibilities on my end first.
Thanks in advance for any more help you guys can give me.
John
I don't think your allowed
Fri, 05/23/2008 - 8:57am
I don't think your allowed to do:
exten => _X.,n,Verbose(NEW CALL FROM:[${CALLERID(number)}] FOR:[${EXTEN}]
maybe:
exten => _X.,n,Verbose("NEW CALL FROM:[${CALLERID(number)}] FOR:[${EXTEN}] ")
I assume the closing ")" is missing from a shortened cut n paste... if not you need a closing )
Can you verify with the
Fri, 05/23/2008 - 9:03am
Can you verify with the telco that they are sending the caller ID (ANI) along with the DNIS digits?
It should be look like this *2165551234*5413011*
That is 10 digit ANI and 7 digit DNIS with * as start, separation and stop.
Are you able to decode the DNIS currently and route the call with an inbound route?
The carrier should tell you exactly how many digits they are sending along with separation (DTMF digits used to indicate start and stop of DNIS and ANI) .
Does this make more sense to you?
This is how FGD trunks are typically provisioned (I verified before posting).
Scott
P.S. FGD = Feature Group D
--
Scott
aka "Skyking"
Thanks James, I thought that
Fri, 05/23/2008 - 9:06am
Thanks James, I thought that debug output looked a little off. I corrected it and just tested it, here's what's getting kicked out now:
-- Executing [0474@from-zaptel:1] Set("Zap/17-1", "DID=0474") in new stack
-- Executing [0474@from-zaptel:2] NoOp("Zap/17-1", "Next line evaluates recommendation from Trixbox Forum") in new stack
-- Executing [0474@from-zaptel:3] Verbose("Zap/17-1", ""NEW CALL FROM:[] FOR:[0474"]") in new stack
"NEW CALL FROM:[] FOR:[0474"]
-- Executing [0474@from-zaptel:4] Goto("Zap/17-1", "s|1") in new stack
-- Goto (from-zaptel,s,1)
-- Executing [s@from-zaptel:1] NoOp("Zap/17-1", "Entering from-zaptel with DID == 0474") in new stack
James -
Help me out with
Fri, 05/23/2008 - 9:12am
Follow-up to problem resolution
Thu, 06/05/2008 - 9:44am
Just wanted to post a follow-up to this incident so the outcome is in the archives here.
Turns out the telco (XO Communications) was not forwarding caller-Id information, nor were they setting it on outbound calls. Apparently they have just started using a new switch type and none of their tech's new how to configure it. Go figure...... Anyways, once they started sending it via ANI and it's all working now.
Thank you gentlemen for your help with this!
John Livingston, Engineer
Crewe Technologies / www.ipphoneshack.com
Member Since:
2007-09-22