Wassim

There are two types of CUCM audio conferences: Ad Hoc and Meetme. And we are going to see one example configuration of each. The network setting for our sample config includes three phones registered to CUCM: CIPC: x1000 EyeBeam: x1002 X-Lite: x1003 You find a good amount of theory on audio conference types in CUCM here . Ad Hoc From CIPC, I make a call to EyeBeam then press the Confrn softkey: I make a second call to X-Lite and press the Confrn softkey: Now all participants are in an audio conference. To display the conference participants, press the ConfrList softkey To remove a participant, highlight it and press the Remove softkey The conference bridge is released and we have a two-leg simple call: MeetMe The second type of CUCM audio conferences we have is MeetMe conferences. We configure a MeetMe pattern on CUCM in this way: Call Routing -> MeetMe Number/Pattern CIPC is the first to enter the MeetMe conference; he must press the MeetMe softkey and dial the MeetMe pattern: On ...

The network setup: we have three phones registered to CUCM: one CIPC: x1000 one EyeBeam: x1002 one X-Lite: x1003 The below settings will be applied to the line 1000 as it pertains to the device CIPC Line Text Label Without it, the phone simply displays the line extension I modified it to “si Rchid” and “si Rchid” now appears as the name of the line. Display (Caller ID) When CIPC calls Eyebeam, Eyebeam sees a call from x1000: If I want EyeBeam to see the call coming from “Rchid”, I configure it at the Display (Caller ID) field. But the other way around is not true. When Eyebeam calls CIPC at x1000, the called number does not get transformed to Rchid Bolice:

This article demonstrates how to use the COR feature to establish classes of service. We have two phones at HQ site: x1000 and x1003. x1000 is a manager. x1003 is a security guard. Obviously, we will assign the national PSTN access to the manager and restrict the security guard access. In the topology below, I left only what is relevent to the experiment.   The steps required are: check which dial peers will be concerned by the COR feature configure the COR names configure COR lists according to our class of services assign COR lists to dial peers incoming COR lists to inbound matched dial peers outgoing COR lists to outbound matched dial peers We are going to apply one COR list for the inbound matched dial peer for calls from x1000; and we’re going to apply another COR list for the inbound matched dial peer for calls from x1003. Given the current configuration of the HQ router, I’m using a dial-peer 9999 for inbound call leg matching. The dial peer 9999 uses “inc...

In this blog I am displaying examples of protocol interworking performed by Cisco Unified Border Element and then display the output with some “show” CLI commands. The lab setting we are going to use is as follows: In this topology, all the following routers act as Cisco Unified Border Elements: the HQ GW the emulated PSTN the MongiShop router In case you need a refresher on H323 configuration or packet analysis , then please read this post . Protocol interworking example 1: H.323 to SIP and SIP to H.323 The HQ Cisco Unified Border Element receives a H.323 call leg from CUCM, since I configured it as a H.323 gateway on CUCM. To reach MongiShop phones, I configured a dial peer 5000 on HQ CUBE and with session protocol SIP. We allow H.323 to SIP interworking: At the PSTN router, the inbound dial-peer 9999 uses session protocol SIP. The outbound dial peer towards MongiShop uses a H.323 dial peer. the inbound dial peer on PSTN CUBE the outbound dial peer on PSTN CUBE We allow SI...