cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
717
Views
25
Helpful
9
Replies

Why use FXO port?

wilson_1234_2
Level 3
Level 3

My undestanding is that the FXO port holds the line that comes directly from the carrier, which would be a regular POTS line.

It would plug into a card or module in the back of a router with an rj11.

If this is correct, why would you need it to go to your FXO port on the router?

Why not just plug the line directly into the analog device that will be using it?

What benefit do you get from this?

9 Replies 9

allan.thomas
Level 8
Level 8

The specific benefit is for one of two reasons, and it depends on your call handling requirements.

As you have mentioned 'Why not just plug the line directly into the analogue device' If you do that then it will not be possible to leverage from the benefits of VoIP or traditional PBX features.

There are two typical call handling deployments, PBX or Keyswitch and here is where the benefits can be seen:-

The simplest model is the PBX model, in which most of the IP phones in your system have a single unique extension number.

Incoming PSTN calls are routed to a receptionist at an attendant console or to an automated attendant who then forwards the call to an appropriate extension.

In a keyswitch system, you can set up most of your phones to have a nearly identical configuration, in which each phone is able to answer ANY incoming PSTN call on ANY line.

For example, a keyswitch system has three PSTN lines shared across three telephones, such that all three PSTN lines appear on each of the three telephones. This permits an incoming call on any PSTN line to be directly answered by any telephone-without the aid of a receptionist, an auto-attendant service, or the use of (expensive) DID lines.

Also, the lines act as shared lines-a call can be put on hold on one phone and resumed on another phone without invoking call transfer.

None of these features would be possible without a PBX of some kind, whether it is your legacy TDM PBX, CallManager or CallManager express.

The added benefit of integrating your PSTN lines onto a voice gateway is VoIP:-

You will be able to provide inter-office communications without the expense of PSTN charges.

Centralised call processing with CallManager/Express and Voicemail integration, therefore avoiding the requirement for a local PBX and maintenance costs within your remote office(s).

Hope this helps.

Allan.

Pls rate helpful posts.

Allan,

You answer was very informative and helpful.

I have an existing site that will be moved to a new loation next month.

I am trying to get everything ready to move.

The documentation shows 4 telephone numbers being used for services like:

Analog phone

Security line

Fax machine

support modem

Two of these numbers are part of the DID block of the PRI and I can see them in the router config.

The other two are regular seperate POTS lines ordered from the telephone company. They are shown as FXO ports in the documentation, but I do not see them in the config anywhere.

The router has an FXO/FXS module in it, but I am not sure how to see if the FXO ports are being used in the config.

Where can I check this to make sure these bases are covered?

I had to order new numbers for these two lines and was to make sure everything works after the move.

Hi Richard, if these ports are utilised, then I would expect there to be configuration on the appropriate voice-ports and dial-peers whether they are MGCP or H323 controlled.

Are these endpoints controlled by Callmanager or CallManager Express via MGCP or H323?

The FXS ports will be associated with a pots dial-peer, and will have the command service mgcapp configured if they were registered to CUCM via MGCP.

If this is not the case, the you will still require pots dial-peer for H.323 but will simply have the destination-pattern configured for the number and the FXO voice-port will be configured with connection plar.

If possible post your configuration, it should contain the answers as to how the numbers have been assigned.

I would not necessarily expect your security line to be terminated on the FXO, this ideally should still be a direct exchange line.

Hope this helps.

Allan.

Pls rate helpful posts.

Thanks allan.

That is what I suspected.

The config is shown here and I do not see the FXO port numbers in the config at all.

I believe they are just lines connected directly to the devices.

If this is what you think, I have another question related to the move.

I have an existing PRI installed with a test number on it. I am going to turn up the PRI about two weeks prior to the move.

I want to test this number to make sure the PRI is up and routing calls to it before actually moving.

I have a spare router and was going to use this existing config (with different IP Addreses).

I have a PoE switch and a cisco IP phone I can use.

What would be a simple mod I could to to test the call are making it to my test phone using the test number on my PRI?

Would this be asy to do?

Hi Richard, you are quite right there does not appear to be any incoming called number digit manipulation for 409-805-0619 or 409-805-0639, so I suspect that these are not connected to the gateay?

It is evident that your gateway is configured for mgcp fallback to the default h323 application. Hence you have MGCP configured as well H.323 dial-peers when operating in fallback.

I assume that the numbers 7219363 for the Money Line, and 7218530 for the fax are incoming on your T1? These numbers are assoicated with MGCP controlled endpoints, and would therefore appear in CUCM config as such.

The POTs dial-peer 40 is for the Money Line and has the destination-pattern 7219363, and service mgcpapp. Therefore when MGCP fallbacks a DID call to 7219363 would be routed to voice-port 0/1/0.

The same principle applies to POTs dial-peer 41 for the Fax line. It has the destination-pattern 7218530, and service mgcpapp. Again when MGCP fallbacks a DID call to 7218530 will be routed to voice-port 0/1/1.

The simplest option for testing the PRI would be to configure the gateway for H323, you can simply overlay this existing configuration, and the gateway will fallback to H323 whilst it is unable to register to CUCM.

The call-manager-fallback should then register your IP Phone, providing the IP Phone has the gateway IP address as one of the CallManagers when it registered with CCM. Therefore you use one of your existing phones, otherwise it will have a problem registering.

Alternatively configure CME instead, and provision the ephone and ephone-dn manually. Just configure the telephony-service with a source ip of the gateway f/a interface address, max-dn and max-ephone and ensure that you have a dhcp-pool configured,

ip dhcp pool VOICE-DHCP

network 10.243.0.0 255.255.0.0

default-router 10.243.70.1

option 150 ip 10.243.70.1

!

telephony-service

max-ephones 42

max-dn 144

ip source-address 10.243.70.1 port 2000

create cnf

!

ephone-dn 1

number

!

ephone 1

mac-address xxxx.xxxx.xxxx (mac of phone)

type

button 1:1

!

Ensure that your translation-patterns are correct, unless you simply configure the full incoming called number as the ephone-dn number. Then your DID pots dial-peer 2 will be matched on incoming-called-number . , just make sure that your outgoing pots dial-peers have the correct voice-port.

Hope this helps.

Allan.

Pls rate helpful posts.

Thanks allan.

"I assume that the numbers 7219363 for the Money Line, and 7218530 for the fax are incoming on your T1? "

Correct, these are part of the DID block on the existing PRI.

I plan on testing the new PRI to make sure calls are routing and then have Verizon move the DID block to the new PRI.

I have no experience with voice, so I am hoping there will be no problem in doing this.

I would rather not have the router try to register in call manager.

Is it possible to have the test number ring directly to the cisco phone?

If not, could I just do a debug on the router to see if the call to the number is actually hitting the gateway (debug isdn q931) without any additonal config?

If they are being routed, I should be ok to just move the existing numbers correct?

What are the possibilites that the new PRI may not work like the existing?

Would the smart thing be to have the new site configured as a branch and test all of the features of in our phone system?

It will not be necessary to have the gateway register to CallManager via MGCP in order to test the ISDN PRI. However, you can only test the PRI if have another T1 VWIC that you can use in this gateway?

Although the existing configuration uses MGCP to register to CallManager, it also defaults to H323 when it is unable to do so.

Therefore if you use the same configuration on the spare, the gateway will simply default to H323 anyway because it will be isolated from the LAN.

In order to have the test number ring the IP Phone you will need to ensure that the phone can register to the gateway. The example I provided should be sufficient for thisthe only way this will be possible is if you configure the config it shown in the previous examplebe required is to connect the Gateway LAN interface to your POE switch with your test phone connected.

It maybe straight forward to use a simplied config to save confusion, the switch can be just connected with the defaults as there is not need to configure a trunk interface for this exercise. The controller interface will only be the same provided the VWIC is in the same slot, if not you may need to change it, and also change the dial-peer voice port too:-

network-clock-participate wic 0

network-clock-select 1 T1 0/0/0

!

ip dhcp excluded-address 10.243.121.0 10.243.255.255

ip dhcp excluded-address 10.243.0.0 10.243.120.0

!

ip dhcp pool VOICE-DHCP

network 10.243.0.0 255.255.0.0

default-router 10.243.70.1

option 150 ip 10.243.70.1

!

controller T1 0/0/0

framing esf

linecode b8zs

pri-group timeslots 1-24

no shut

!

interface FastEthernet0/0

ip address 10.243.70.1 255.255.0.0

speed 100

duplex full

no shut

!

interface Serial0/0/0:23

no ip address

encapsulation hdlc

isdn switch-type primary-ni

isdn incoming-voice voice

isdn map address .* plan unknown type unknown

no cdp enable

!

dial-peer voice 1 pots

description Incoming PSTN

incoming called-number .

direct-inward-dial

!

dial-peer voice 2 pots

description Outbound PSTN

destination-pattern 9T

port 0/0/0:23

!

telephony-service

max-ephones 5

max-dn 5

ip source-address 10.243.70.1 port 2000

create cnf

!

ephone-dn 1

number 1234567

!

ephone 1

mac-address xxxx.xxxx.xxxx (mac of phone)

type

button 1:1

!

It is possible that the ISDN PRI is not provision exactly as before, that is why it is important to ensure you provide all the relevant details to the Telco. If you are using the same Telco then they should be able to port the numbers over when you are ready, however make sure that they still present the same number of digits otherwise your translations will fail, including the SRST alias commands. This will be apparent when you do a 'debug isdn q931', currently it looks as though the Telco is sending seven digits.

When you configure the ephone-dn 1 number make sure that it matches the incoming number how ever the number of digits that the telco is sending. This will ensure that you don't need to configure translations for the purpose of the test, the seven digit called number should match the ephone dial-peer directly.

The only other concern is the IP addressing, if this is not changing when you move locations, including the WAN. Then you should be able to move the existing gateway to the new site without any further configuration when it actually comes to moving.

Continued next post....

Continued ...

It is always advanageous to make all the necessary preparations in advance, so once you are satisfied with the testing of the PRI on the new gateway, you can erase the configuration and tftp the existing configuration in the startup, and then configure the LAN switchports ready for the IP Phones.

It will then only be a matter of connecting the WAN interface when the relocation takes place, and then the gateway should register as before. The only thing that you should ensure is that the new gateway is running the same IOS to that what is on the current gateway. The last thing you want is to introduce problems you have not seen before by running old IOS version.

Hope this helps.

Allan.

Pls rate helpful posts.

Allan, sorry for all of the questions and thanks for all of the great information.

I will be putting a spare router in place and will be able to put whatever config I want in it.

The router will have all the interfaces needed to bring the MPLS and PRI on line.

This will be in place at the spare site for two weeks while the existing site is still in service.

I was just going to use the existing config, because it is working in the existing site, so I figured I could use it as a template.

When the moved has taken place, I was just going to move the router at the existing site over to the new site and remove the spare router, so it will be just as it alsways was except the serial interface will have a different IP Address.

I had the provider check to make sure the PRIs were identical in features and the number of digits.

If I just plug the PRI into the interface card and do a "debug isdn q931" will this be enough to see the call hit the gateway, or does there need to be some config in place in order for me to see it?

I will give the config you provided a try.

Can you explain the difference in registering mgcp of h323?

Why mgcp first, then h323? Does call manger only use mgcp an cannot use h323?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: