POTS (FXO) Translation to an Internal Extension?

Unanswered Question
Feb 12th, 2009

I have a POTS line on an FXO port (0/1/0) and want to have inbound calls to that number ring on ext 360. I will eventually have a PRI as well. In the end all calls will ring on the operator extension (testing using 360) ... company is old fashion, no AA.

I know I can "tie" the FXO to the phone via a "plar" to 360 (had it running that way), but I wanted to set things up like I believe I will have to for the PRI with DIDs getting installed in a few weeks. Therefore, I wanted to use "voice translation-profiles" for mapping inbound calls to the FXO (in prep for the new PRI) to the operator (x-360).

FYI - Since the POTS does not have DID, the "called" number is blank (aka - OriginalCalledNumber in the "show" output).

So I put in the config:

voice translation-rule 200

rule 1 /^\(.......\)$/ /8\1/

rule 2 /^\(..........\)$/ /8\1/

!

voice translation-rule 210

rule 1 /.*/ /360/

!

voice translation-profile Redirect-To-Operator

translate called 210

voice-port 0/1/0

translation-profile incoming Redirect-To-Operator

description Rockford, POTS 1, E911 Backup 1

caller-id enable

!

dial-peer voice 10 pots

description Incoming POTS-1

incoming called-number .*

port 0/1/0

!

ephone-dn 38 dual-line

number 360

pickup-group 34

label Sample User (360)

description Materials

name Sample User

call-forward busy 200

call-forward noan 200 timeout 10

corlist incoming User-LongDist

hold-alert 30 idle

!

ephone 38

description Sample User - 7962G - MAC:0021A0D98F08

mac-address 0021.A0D9.8F08

ephone-template 1

emergency response location 1

type 7962

button 1:38

!

When I call in, it picks up, then disconnects me without ringing the IP phone. If I look at the debug and show commands, I see it translates correctly (show call leg history):

Call Information - Connection ID: 128D , Call Leg ID: 34

GENERIC:

SetupTime=92358270 ms

Index=52

PeerAddress=1112223333 <--I changed

PeerSubAddress=

PeerId=20

PeerIfIndex=77

LogicalIfIndex=6

DisconnectCause=10

DisconnectText=normal call clearing (16)

ConnectTime=0 ms

DisconnectTime=92361370 ms

CallDuration=00:00:00 sec

CallOrigin=2

ReleaseSource=1

ChargedUnits=0

InfoType=speech

TransmitPackets=0

TransmitBytes=0

ReceivePackets=0

ReceiveBytes=0

TELE:

ConnectionId=[0xEE6B9A70 0xF8B411DD 0x80B0BCB9 0x827F8056]

IncomingConnectionId=[0xEE6B9A70 0xF8B411DD 0x80B0BCB9 0x827F8056]

CallID=52

Port=0/1/0 (52)

BearerChannel=0/1/0

TxDuration=0 ms

VoiceTxDuration=0 ms

FaxTxDuration=0 ms

CoderTypeRate=None

NoiseLevel=0

ACOMLevel=0

SessionTarget=

ImgPages=0

CallerName=USER, JOE <---I Changed

CallerIDBlocked=False

LongDurationCallDetected=no

LongDurCallTimeStamp=

LongDurCallDuration=

OriginalCallingNumber=1112223333 <---I Changed

OriginalCallingOctet=0x0

OriginalCalledNumber= <<<<<<NO GOOD

OriginalCalledOctet=0x80

OriginalRedirectCalledNumber=

OriginalRedirectCalledOctet=0x0

TranslatedCallingNumber=1112223333 <---I Changed

TranslatedCallingOctet=0x0

TranslatedCalledNumber=360 <<<<<<<<GOOD

TranslatedCalledOctet=0x80

TranslatedRedirectCalledNumber=

TranslatedRedirectCalledOctet=0x0

GwReceivedCallingNumber=1112223333 <---I Changed

GwReceivedCallingOctet3=0x0

GwReceivedCallingOctet3a=0x0

DSPIdentifier=0/1:1

Total call-legs: 2

It appears that the called number gets changed to 360. But 360 doesn't ring (I can ring 360 internally and call out on 360 fine). What am I doing wrong?

FYI - I see it matching the incoming dial-peer of:

r1-rtr-voip#debug voice dialpeer

Feb 13 03:46:17.404: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

Calling Number=1112223333, Called Number=360, Voice-Interface=0x47D551BC,

Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,

Peer Info Type=DIALPEER_INFO_SPEECH

Feb 13 03:46:17.404: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

Result=Success(0) after DP_MATCH_PORT; Incoming Dial-peer=10

Help?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Nicholas Matthews Thu, 02/12/2009 - 20:46

Hi Chris,

I think this is an artifact of the way that connection plar works on FXO ports. It appears that the call-control API (CCAPI) does not kick the call off right, because translating an incoming called number of "" is different than a plar statement. This can be highlighted by the fact that there is both a 'connection plar' and 'connection plar opx' which are two different call routing processes. The default behavior if there isn't a connection plar statement is to play dial tone for two-stage dialing, and it appears that the translation pattern is interfering with that.

Your translation pattern looks fine, and this should work when you have your PRI installed.

I generally prefer to put my "translation-profile incoming Redirect-To-Operator" statement under the dial peer, because I normally don't look for call routing statements under the voice port. You may try putting this on dial peer 10 and see if you have different results.

Hope this clarifies a bit.

-nick

Christopher Baker Fri, 02/13/2009 - 07:49

Having the translation profile on the matching dial-peer is how I had it originally, but that did not work.

Here is what happened...

1) moved translation from voice port to dial-peer.

voice-port 0/1/0

description Rockford, POTS 1, E911 Backup 1

caller-id enable

!

dial-peer voice 10 pots

description Incoming POTS-1

translation-profile incoming Redirect-To-Operator

incoming called-number .*

port 0/1/0

!

2) Made call in, monitoring the dial-peer (confirm match to dial-peer I thought it would and the one I applied translation to):

r1-rtr-voip#

Feb 13 15:38:41.389: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

Calling Number=7083499940, Called Number=, Voice-Interface=0x47D551BC,

Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,

Peer Info Type=DIALPEER_INFO_SPEECH

Feb 13 15:38:41.389: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:

Result=Success(0) after DP_MATCH_PORT; Incoming Dial-peer=10

r1-rtr-voip#

4) Router picked up, and then dropped call. Looking at the call leg history ...

Call Information - Connection ID: 129D , Call Leg ID: 38

GENERIC:

SetupTime=136291920 ms

Index=56

PeerAddress=1112223333 <-- I Changed it

PeerSubAddress=

PeerId=10

PeerIfIndex=75

LogicalIfIndex=6

DisconnectCause=10

DisconnectText=normal call clearing (16)

ConnectTime=0 ms

DisconnectTime=136297680 ms

CallDuration=00:00:00 sec

CallOrigin=2

ReleaseSource=1

ChargedUnits=0

InfoType=speech

TransmitPackets=0

TransmitBytes=0

ReceivePackets=0

ReceiveBytes=0

TELE:

ConnectionId=[0x396E2125 0xF91B11DD 0x80C0BCB9 0x827F8056]

IncomingConnectionId=[0x396E2125 0xF91B11DD 0x80C0BCB9 0x827F8056]

CallID=56

Port=0/1/0 (56)

BearerChannel=0/1/0

TxDuration=0 ms

VoiceTxDuration=0 ms

FaxTxDuration=0 ms

CoderTypeRate=None

NoiseLevel=0

ACOMLevel=0

SessionTarget=

ImgPages=0

CallerName=USER, JOE <--- I changed it

CallerIDBlocked=False

LongDurationCallDetected=no

LongDurCallTimeStamp=

LongDurCallDuration=

OriginalCallingNumber=1112223333 <-- I Changed it

OriginalCallingOctet=0x0

OriginalCalledNumber= <<<<<<<<<< NOT GOOD!

OriginalCalledOctet=0x80

OriginalRedirectCalledNumber=

OriginalRedirectCalledOctet=0x0

TranslatedCallingNumber=1112223333 <-- I Changed it

TranslatedCallingOctet=0x0

TranslatedCalledNumber= <<<<<<<<<< STILL NOT GOOD???

TranslatedCalledOctet=0x80

TranslatedRedirectCalledNumber=

TranslatedRedirectCalledOctet=0x0

GwReceivedCallingNumber=1112223333 <-- I Changed it

GwReceivedCallingOctet3=0x0

GwReceivedCallingOctet3a=0x0

DSPIdentifier=0/1:1

Total call-legs: 2

r1-rtr-voip#

4) So the translation pattern did not work. I just don't get it.

Are you saying this won't work this way at all with this setup (route FXO via translation pattern)?

Could it be a bug (I am using the latest CME running on "(C2800NM-SPSERVICESK9-M), 12.4(22)T / CME 7.0(1)". Should I be running something else?

Does anyone have some example configs of translation profiles and PRI's that I could model mine after?

Christopher Baker Fri, 02/13/2009 - 07:58

No that did not make a difference. Still matched the 10 dial-peer and still did not translate.

Christopher Baker Fri, 02/13/2009 - 08:10

The only way so far I can get this to work is:

1) Setup a "intermediate" dial-peer with the translation to the operator on it:

!

dial-peer voice 2300 pots

description Intermediate Dial-Peer to Operator

translation-profile incoming Redirect-To-Operator

destination-pattern 2300

!

2) Plar to the intermediate dial-peer:

!

voice-port 0/1/0

connection plar 2300

caller-id enable

!

This seems to work and lets me use translation patterns on the incoming and outgoing numbers prior to presentation to the IP phone.

I just don't understand why the other why doesn't work still. I guess I will ask for other examples of a PRI config to see what I need to do when that arrives.

Nicholas Matthews Fri, 02/13/2009 - 11:38

The thing that needs to be understood about the call flow is that connection plar is much more than a translation. By having that command under the voice port, it changes the way to port acts with other parts of software. Doing a simple translation on the calling number is not the same thing, and I would not have any expectation for this to work.

This would not be a bug, because it's fairly flagrant mis-configuration.

-nick

Actions

This Discussion