Interesting reading for anyone wanting to know more about CoR
I strongly believe CoR cant work with SRST and IP phones.
Phones register and are assigned dial-peers as they register first come first served i.e: dynamically assigned !!!
These are not static like ephones in ITS which you configure.
The phones are SRST aware because the boss CM told them to be!!!!
So if someone can prove me wrong I'd like to see an example.Because this feature would be very usefull it would have been great over the weekend when the wan failed.
If anyone wanted to restrict FXS ports or ephones on ITS we could do it.
This should be a feature thats workable with SRST and ip phones with out any doubt in my mind.
Lets say you have Lobby phones lift phones etc etc IP phones that is.
what happens when the CM fails or the wan goes down.
Yep you hit the nail on the head Charlie no more CSS restriction controll its all over red rover the guy in the lift is going to hit emergancy stop button and call Bermuda till he needs fresh air great isnt it : )
What are the other options for IP phones registering with SRST capabale device lock down everyone with use of H.323 dial-peers (pretty shitty option and if you dont use MGCP to start with nothing would work)The best option is to use fxs ports for these phones then use CoR this will work
The documentation on CCO with regards to this feature is difficult to understand, it was for me this post should clear a few things up if your confused as i was.
If COR applied on an incoming dial-peer (for incoming calls) is a super set or equal to the COR applied to the outgoing dial-peer (for outgoing calls), the call will go through. Now incoming and outgoing are with respect to the "voice ports". If you hook up a phone to one of the FXS port of the router and try to make a call from that phone, it is an incoming call for the router/voice-port. Similarly if you make a call to that FXS phone, then it is an outgoing call.
By default an incoming call leg has the highest COR priority and the outgoing COR
list has the lowest COR priority which means if there is no COR configuration for incoming calls on a dial-peer, then you can make a call from this dial-peer( a phone attached to this dial-peer) going out of any other dial-peer irrespective of the COR configuration on that dial-peer.
How do you make sub sets and super sets..?
First you configure dial-peer cor custom and assign a whole bunch of meaningful names under this. For example:
Dial-peer cor custom
Now you create the actual lists that you apply to the dial-peer.
Dial-peer cor list call911
Dial-peer cor list call1800
Dial-peer cor list call1900
Dial-peer cor list calllocal
Dial-peer cor list Engineering
Dial-peer cor list Manager
Dial-peer cor list HR
We have created five dial-peers below for the following destination numbers = 734 ., 1800 ., 1900 ., 911 and 316 . Appropriate cor-list is applied to each of the dial-peer.
Dial-peer voice 1 voip
Destination pattern 734 .
Session target ipv4:184.108.40.206
Cor outgoing calllocal
Dial-peer voice 2 voip
Destination pattern 1800 .
Session target ipv4:220.127.116.11
Cor outgoing call1800
Dial-peer voice 3 pots
Destination pattern 1900 .
Cor outgoing call1900
Dial-peer voice 4 pots
Destination pattern 911
Cor outgoing call911
Dial-peer voice 5 pots
Destination pattern 316 .
Port 1/1/0 --à No cor applied here
Now we apply the COR list to the individual phones/ephone-dns.
Cor incoming Engineering
Cor incoming HR
Cor incoming Manager
---à No COR applied to this ephone-dn
With the above configuration ephone-dn 1 (1001) can call 408 numbers,911 AND 316 .
Ephone-dn 2 (1002) can call 408 , 1800 numbers, 911 AND 316 .
Ephone-dn 3 can call all the numbers possible from that router.
Ephone-dn 4 can call all the numbers possible from that router
All ephone-dns can call 316 .
Various combinations of COR list and the results are shown below.
COR list on Incoming dial-peer COR list on outgoing dial-peer Result Reason
No COR No COR Call will Succeed COR not in picture at all.
No COR COR list applied for outgoing calls Call will Succeed Incoming dial-peer by default has the highest COR priority when no COR is applied. So if you apply no COR for an incoming call leg to a dial-peer, then this dial-peer can make calls out of any other dial-peer irrespective of the COR configuration on the outgoing dial-peer
COR list applied for incoming calls No COR Call will Succeed Outgoing dial-peer by default has the lowest priority. Since there is some COR configurations for incoming calls on the incoming/originating dial-peer it is a super set of the outgoing call CORconfigs on outgoing/terminating dial-peer.
COR list applied for incoming calls. (super set of COR list applied for outgoing calls on the outgoing dial-peer) COR list applied for outgoing calls.(subs set of COR list applied for incoming calls on the incoming dial-peer) Call will Succeed COR list for incoming calls on the incoming dial-peer is a super set of COR list for outgoing calls on the outgoing dial-peer
COR list applied for incoming calls. (sub set of COR list applied for outgoing calls on the outgoing dial-peer) COR list applied for outgoing calls.(super set of COR list applied for incoming calls on the incoming dial-peer) Call will not Suceed COR list for incoming calls on the incoming dial-peer is NOT a super set of COR list for outgoing calls on the outgoing dial-peer
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...