by jbrandoloni | Mar 21, 2011 | CUCM, H.323, Non classé, SIP, Uncategorized |
Hey Oliver,
I came across your blog when doing some research and its totally great. I have been struggling with getting CUVA to work with our deskphones.
To give you a quick background, we are running UCCE version 7.5. Our Desk phones are 7941’s with the latest firmware (9-1-1SR1S). All deskphones are configured as SIP.
Im running Video Advantage verion 2.2 (which supports SIP video) and cannot get the phone to integrate with the video software. CUVA works perfectly fine with a deskphone. One theory I had was the windows firewall was blocking CUVA from speaking with the 7941 but after disabling it, Im still experiencing the issue.
Is there soemthing major that Im missing, which is causing the webcam to no communicate with the phone?
Thanks,
Jim
by Olivier | Aug 21, 2010 | CCME, CUCM, H.323, IOS, Lab, MGCP, Non classé, SRST |
Hi ,
Just as a reminder when you sit in the lab, try to not forget to put the correct Calling number , type and plan and this for all situation so it is true as well for SRST.
So a good vision of the call routing is important
by Olivier | Mar 10, 2010 | H.323, IOS, Lab, MGCP, Non classé, Uncategorized, Written Theory |
Real-time fax over IP operates in a similar way of a regular fax transmission. The fax machines involved in the transmission synch up and then the fax data is sent between them over the intervening IP Network.
There are 2 methods of transporting fax in real time across the network:
Fax-relay
Fax-passthrough
When using fax-relay, the T30 fax signal from a connected fax machine is demodulated by the sending fax gateway and sent over the IP Network to a remote fax gateway. The remote fax gateway then recontructs the T30 fax signal and send it to the fax.
There are 2 types of fax-relay mechanisms:
Cisco fax-relay
T38 fax-relay
Cisco fax-relay is an older method. So a fax gateway terminates T30 fax tones from a local fax machine and then sends the fax data across an IP network by breaking the tones into HDLC frames and then transmitting them using RTP.
T38 fax-relay is the ITU standard T30 fax signal, it is demodulated at the local gateway and encapsulated into IP packets for transport over a network to a remote fax gateway which will then reconstruct the signal and play it to the fax. T38 includes also a mechanism by which a fax gateway can inform the remote gateway of its desire to change the media type from voice to data. T38 can also use TCP or UDP connections but will use more UDP.
For fax pass-through, modulated fax data is sent in-band across the IP network by a fax gateway using a voice codec (like G711 without any VAD or echo-cancellation). Also with fax pass-through, T30 fax calls are not distinguished from regular voice calls, they are simply sent in-band over the IP Network. With the fax detection tones, the gateway must be able then to switch to high-bandwidth codec. Fax pass-through is relatively bandwidth hungry and is sensitive to delay,jitter and packet loss
by Olivier | Mar 8, 2010 | CCME, CUC, H.323, IOS, Lab, Non classé, SIP, Written Theory |
Here are all the steps to perform if you want to integrate the CUE with the CME
- Create a SIP dial peer pointing to the CUE Module
- Configure the MWI On/Off extensions
- Configure the connectivity between CME and CUE Modules
- Perform CUE Configuration
For the first step , your dial peer will look like
dial-peer voice 1000 voip
destination-pattern 5555
session protocol sipv2
session target ipv4:172.17.1.1
dtmf-relay sip-notify
codec g711ulaw
no vad
!
The configurations of the MWI On/Off must be generic as it must cover all numbers and it is generally implemented as a kind of prefix as the MWI must know which number must be turned on or off. So it adds the number after the extension the MWI shortcut.
ephone-dn 50
number 5000….
mwi on
!
ephone-dn 60
number 6000….
mwi off
Regarding the link configuration between the CUE and CME, you need to borrow the Ethernet interface where the CUE module resides (don’t forget that CME and CUE can be splitted). So everything under the service-engine ( this is the CUE module) will rely on the Ethernet interfaces:
interface Service-Engine 1/0
ip unnumbered FastEthernet 1/0
service-module ip address 172.17.1.1 255.255.255.0
service-module ip default-gateway 172.17.1.254
!
ip route 172.17.1.1 255.255.255.255 Service-Engine1/0
!
In a multi-site implementations , you have then to configure a translation between your remote CME and the central CUE/CME because we told before that CUE relies on SIP Protocol and the rest of your network is an H323 network , so you need to translate all H323 request to SIP. You can do it generally with the config:
!
voice service voip
allow-connections H323 to sip
by Olivier | Mar 8, 2010 | CCME, CUC, H.323, IOS, Lab, Non classé, SRST |
CUE is as the CME a small business voice mail solution that you can easily deploy on a router. Most of the time, CUE will reside on the same chassis than the CME but for some implementations, you can split both. The only backdraw is that you must have a LAN connectivity between your elements.
CUE is interesting because it doens’t provide only voice mail but can also provide a small Auto-Attendant (AA). The integration between CUE and CME is done via the SIP protocol, while the integration with a Call Manager will be done via JTAPI ( CTI-QBE). It can be the case for implementation where you need to provide Unity backup on SRST location).
CUE will be supported by Network Module (NM-CUE) or as an Advanced Integration Module (AIM-CUE).
by Olivier | Mar 8, 2010 | CCME, CUC, CUCM, H.323, IOS, Lab, Non classé |
CME can be integrated with Cisco Unity, it is more or less as an integration with Call Manager except the fact that you must every setting in the CLI mode. Let’s see a kind of basic config:
!
telephony-service
voicemail 5555
!
ephone-dn 10
number 1234
call-forward busy 5555
call-forward noan 5555 timeout 10
ephone-dn 16
number 5566
mwi on
ephone-dn 17
number 5577
mwi off
ephone-dn 20
number 5555
name “VM-Port 1”
preference 0
no huntstop
ephone-dn 21
number 5555
name “VM-Port 2”
preference 1
no huntstop
ephone-dn 22
number 5555
name “VM-Port 3”
preference 2
no huntstop
ephone-dn 23
number 5555
name “VM-Port 4”
preference 3
!
ephone 20
vm-device-id “CISCOUM-VI1”
button 1:20
ephone 21
vm-device-id “CISCOUM-VI2”
button 1:21
ephone 22
vm-device-id “CISCOUM-VI3”
button 1:22
ephone 23
vm-device-id “CISCOUM-VI3”
button 1:23
So you can easily see that your config is trying to match the Unity port name and this is done with the command vm-device-id <<string>>. It helps also to register with Unity where you need the deviceId instead of a mac-address.
Recent Comments