It's been way too long since we all got together, we've been busy getting our hands dirty with Exchange 2010 with a few customers and the folks at MS have been busy making the product.
Before we get too busy eating holiday food and taking vacations, let's get together to prepare for next year and chat about what we've learned this year.
Date:
December 9th, 2009, 4:30pm - 8:30pm
Location:
Microsoft Campus
Address:
Conf Room Studio B/4519.
15101 ND 40th Street
Redmond, WA 98052
RSVP:
http://event.pingg.com/UCDoers-1209
Tuesday, November 10, 2009
Sunday, November 1, 2009
Why isn’t CUCiMOC supported by Microsoft?
Something I do pretty regularly is look up what people are search for when they reach my blog. CUCiMOC is the top topic for hits. This week while looking over the keyword analysis I came across the CUCiMOC Microsoft support question. This is really a loaded question that causes contention in some of the discussions I have seen when Cisco is presenting their sales material. When looking at this situation or any that involves the use of Microsoft’s APIs to create LOB application integration, the reason Microsoft has stated that CUCiMOC is not supported by Microsoft is pretty clear.
CUCiMOC makes extensive use of two areas of integration within Microsoft Office Communicator. The Communicator client API and the Custom Tab. The client API provides the functionality and the custom tab provides the presentation of the CUCiMOC client to put it in simple terms. Both of these Communicator features (the API and Custom Tabs) are fully supported by Microsoft and I have worked with other vendors and internal staff who have developed applications that use both of these features. In these cases (as is the case with CUCiMOC) they were independently developed and supported by either the vendor of the product or internal support staff. The key to all this is “independently developed”. There is no joint roadmap and no cooperation in development unlike other areas of innovation that Microsoft does do with some of its partners.
What can we take away from this question? Well, the first thing is that both Communicators APIs offer a great deal of potential to developers to integrate both at a client and server level. Second is that avenues for developers to get support for Microsoft API’s are available at http://msdn.microsoft.com/en-us/aa570318.aspx.
CUCiMOC makes extensive use of two areas of integration within Microsoft Office Communicator. The Communicator client API and the Custom Tab. The client API provides the functionality and the custom tab provides the presentation of the CUCiMOC client to put it in simple terms. Both of these Communicator features (the API and Custom Tabs) are fully supported by Microsoft and I have worked with other vendors and internal staff who have developed applications that use both of these features. In these cases (as is the case with CUCiMOC) they were independently developed and supported by either the vendor of the product or internal support staff. The key to all this is “independently developed”. There is no joint roadmap and no cooperation in development unlike other areas of innovation that Microsoft does do with some of its partners.
What can we take away from this question? Well, the first thing is that both Communicators APIs offer a great deal of potential to developers to integrate both at a client and server level. Second is that avenues for developers to get support for Microsoft API’s are available at http://msdn.microsoft.com/en-us/aa570318.aspx.
Sunday, October 25, 2009
The Future of VoIP
Last week I traveled down to DuPont to the Intel campus to attend the CIPTUG Tech Forum. It really was a great event run and hosted by the NW chapter of CIPTUG. Seeing as I am no longer the president of the NW chapter I can’t take any credit for the day which is a pity because it was very successful single day event.
One interesting question that was asked during the ask the experts panel was, “what’s the future of the hard phone?” Of course seeing as this was a Cisco conference the answer was hard phones aren’t going away and why would they want one of the largest revenue drivers in the company to go any where. With VoIP hard phone sales driving switch and router upgrades it makes perfect sense to keep that momentum going.
I kind of agree that there will be hard phone requirements but only to an extent. I think the form factor of the phone will change as we move more mobile and dedicated desk space is less common to more cellular services ( that one is kind of obvious, I know). Even though a few companies have tried to bring back virtual workers back into the office I think the trend is more in the other direction. Of course information workers have slightly different work profile than that of other workers so how these other cross section of workers take up different form factors for business purposes may be more influential than just information workers alone. The person cutting your sandwich at Subway or a factory worker still has a use for a business phone of some description even if it is very seldom. So making all our assumptions based on information workers can be a false one.
The Senior Voice Architect where I used to work pushed the idea of mobile VoIP was the direction and that eventually we wouldn’t need carrier voice service. I am not sure how fast we will get there but AT&T’s recent change of heart on iphone VoIP applications over their wireless network certainly pushes the bounds on what the industry able to do. Whether voice quality will be good enough with the use of 3G when uptake increases we will see but it certainly heading in the right direction to see my former co-workers vision come true. Maybe AT&T just doesn’t see this as a threat yet and they have certainly made no guarantees on quality to date which may be the reason why they have allowed it to happen. “Poor quality, put people off early adoption, keep the cellular revenue rolling in, keep searching for new hosted markets to fill the gap when it finally happens in the advent of G4 or other cellular bandwidth break through”. I am just guessing here but they are the thoughts that come to my mind anyway.
So whether you want to believe it or not cellular VoIP is just around the corner in a big way and moving in on us fast. Lets just hope its well thought out before it explodes on enterprises everywhere.
Finally there was also plenty of talk about CUCiMOC while I was at Intel (this is still at the top of my blog hit list notching around 40% of all hits) but I will leave that subject for another post. The interest is there but I think it’s for all the wrong reasons.
One interesting question that was asked during the ask the experts panel was, “what’s the future of the hard phone?” Of course seeing as this was a Cisco conference the answer was hard phones aren’t going away and why would they want one of the largest revenue drivers in the company to go any where. With VoIP hard phone sales driving switch and router upgrades it makes perfect sense to keep that momentum going.
I kind of agree that there will be hard phone requirements but only to an extent. I think the form factor of the phone will change as we move more mobile and dedicated desk space is less common to more cellular services ( that one is kind of obvious, I know). Even though a few companies have tried to bring back virtual workers back into the office I think the trend is more in the other direction. Of course information workers have slightly different work profile than that of other workers so how these other cross section of workers take up different form factors for business purposes may be more influential than just information workers alone. The person cutting your sandwich at Subway or a factory worker still has a use for a business phone of some description even if it is very seldom. So making all our assumptions based on information workers can be a false one.
The Senior Voice Architect where I used to work pushed the idea of mobile VoIP was the direction and that eventually we wouldn’t need carrier voice service. I am not sure how fast we will get there but AT&T’s recent change of heart on iphone VoIP applications over their wireless network certainly pushes the bounds on what the industry able to do. Whether voice quality will be good enough with the use of 3G when uptake increases we will see but it certainly heading in the right direction to see my former co-workers vision come true. Maybe AT&T just doesn’t see this as a threat yet and they have certainly made no guarantees on quality to date which may be the reason why they have allowed it to happen. “Poor quality, put people off early adoption, keep the cellular revenue rolling in, keep searching for new hosted markets to fill the gap when it finally happens in the advent of G4 or other cellular bandwidth break through”. I am just guessing here but they are the thoughts that come to my mind anyway.
So whether you want to believe it or not cellular VoIP is just around the corner in a big way and moving in on us fast. Lets just hope its well thought out before it explodes on enterprises everywhere.
Finally there was also plenty of talk about CUCiMOC while I was at Intel (this is still at the top of my blog hit list notching around 40% of all hits) but I will leave that subject for another post. The interest is there but I think it’s for all the wrong reasons.
Monday, October 19, 2009
Using MTP’s for interop for CUCM to OCS
I have been on the path of interop for Office communications Server and Cisco Unified Communication Manager for some time. Lots of experimenting, successes and some failures. Microsoft even used some of the documentation I have written to pass on to some of their customers. But one thing that never really gets talked about is the best way to use and deploy Media termination points in the Cisco environment for this interop story. With this post I am going to try and shed some light on some of the best ways to make best use of MTP’s for interop.
What are MTP’s, how do I configure them and what’s the best combination to ensure I get the best bang for my buck?
Media Termination Point (MTP)
MTP’s are a required option on the CUCM (h323 or SIP) trunk/gateway that connects to your OCS environment whether you are doing direct connect or through a gateway with H323 as the trunking protocol. They form an important part of the interop environment for different reasons depending on what protocols you are using. In the case of H323 its required for extended services (hold, transfer etc) and SIP its for compliance with RFC 2833. As an example of the first with H323, nearly all functions will work without MTP’s except ad-hoc conferencing from a Cisco IP Phone that has a Communicator user as the first participant. The communicator user is dropped due to the conference going on hold as the first step in the process.
Depending on the version of CUCM you are using it can make a difference as to your choices whether you are using some intermediate gateway to interop between the two environments. If you’re like a lot of companies and are stalled on CUCM 4.X you may have chosen not to do direct trunking between the two environments.
Cisco link to more information on MTP configuration and use:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_1_1/ccmsys/a05mtp.html#wp1030050
Software MTP’s CUCM Server
One thing I haven’t mentioned so far is locating MTPS on the CUCM subscribers. This is a great idea for a single site with limited users, low traffic volumes and the easiest option. MTP’s are much less resource intensive than other CUCM services like transcoding and conferencing. This can have its limitations though such as not being able to locate the MTP’s locally and if your subscriber is heavily loaded it may cause some issues with call quality as the RTP stream will pass through the server.
CUCM 4.x Enhanced MTP’s (on a Cisco ISR)
CUCM 4.x can have some limitations with SIP, so H323 is a safe option and with the IP-IP GW it works pretty well (depending on IOS on your gateway version of course). I have settled on the IOS version 12.4.22yb4 currently while running MTPS onboard the router in software(this uses the router CPU). You can run MTP’s in DSP hardware on an ISR but I believe this to be a waste of resources unless your router is under significant load. DSP’s are very costly and can significantly increase the cost of router hardware. My advice is save these resources for transcoding or conferencing for which DSP’s are a requirement in your Cisco environment. The MTP configuration is below for an IOS router. Take note that although you can name your MTP anything you want there is a 15 character limit. In my case I have called it MTPOCSRouter1. The name must be unique for registration in CUCM. Whats also important is that you have the priority of the of your CUCM subscribers that same as the preference of you dial peers. I have seen one way audio occurrence because this wasn’t set correctly.
sccp local FastEthernet0/0
sccp ccm XX.XX.XX.XX identifier 1 version 4.1
sccp ccm XX.XX.XX.XX identifier 2 version 4.1
sccp
!
sccp ccm group 1
description SCCP CCM group
bind interface FastEthernet0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 101 register MTPOCSRouter1
!
!
dspfarm profile 101 mtp
codec g711ulaw
maximum sessions software 200
associate application SCCP
Below is a diagram to show the full configuration. MTP’s located on the ISR router as well as traffic to the OCS environment passing through the ISR working as an IP-IP GW. This is for a single site like a datacenter where call volumes may be high and you need redundancy. You can also apply the same logic to a branch where you may also have a ISR located for local PSTN access for your Cisco deployment. Placing a mediation server and MTP local will stop tromboning calls across the WAN which is what would happen is both the mediation server and MTP’s where located in a central site and a OC user at a remote site calling a Cisco user at the same remote site. So not much point having one without the other.
In the diagram it shows the MTP as separate entities bound to just one trunk. You could have pooled the MTP resources in to one media resource group but what this could lead to is media traffic having to flow through two device before reaching the medaiton server. Not a desired behaviour and has no benefit. Best bet is to only allow the MTP’s on each gateway only be used for that gateway. One to one if you would like to consider that way.
Although not shown in the first diagram the MTP’s are controlled using Skinny similar to the Cisco IP phone. Skinny is a Cisco propritiory protocol.
CUCM 5.x,6.x and 7.x
The use of MTPs looks somewhat different as you do not have RTP flows having to transition through the ISR for any other reason than the MTP’s themselves. The ISR is now removed from the call signaling flow and the MTP’s are pooled together as a single resource rather than for just one connection.
MTP’s are an unfortunate evil in the interop story between these two infrastructures. If for instance your entire infrastructure was SIP on the Cisco side MTP’s would be much less of a problem but since most Cisco deployments have a mix of control protocols (SCCP, H323 and MGCP) they are a requirement.
What are MTP’s, how do I configure them and what’s the best combination to ensure I get the best bang for my buck?
Media Termination Point (MTP)
MTP’s are a required option on the CUCM (h323 or SIP) trunk/gateway that connects to your OCS environment whether you are doing direct connect or through a gateway with H323 as the trunking protocol. They form an important part of the interop environment for different reasons depending on what protocols you are using. In the case of H323 its required for extended services (hold, transfer etc) and SIP its for compliance with RFC 2833. As an example of the first with H323, nearly all functions will work without MTP’s except ad-hoc conferencing from a Cisco IP Phone that has a Communicator user as the first participant. The communicator user is dropped due to the conference going on hold as the first step in the process.
Depending on the version of CUCM you are using it can make a difference as to your choices whether you are using some intermediate gateway to interop between the two environments. If you’re like a lot of companies and are stalled on CUCM 4.X you may have chosen not to do direct trunking between the two environments.
Cisco link to more information on MTP configuration and use:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/6_1_1/ccmsys/a05mtp.html#wp1030050
Software MTP’s CUCM Server
One thing I haven’t mentioned so far is locating MTPS on the CUCM subscribers. This is a great idea for a single site with limited users, low traffic volumes and the easiest option. MTP’s are much less resource intensive than other CUCM services like transcoding and conferencing. This can have its limitations though such as not being able to locate the MTP’s locally and if your subscriber is heavily loaded it may cause some issues with call quality as the RTP stream will pass through the server.
CUCM 4.x Enhanced MTP’s (on a Cisco ISR)
CUCM 4.x can have some limitations with SIP, so H323 is a safe option and with the IP-IP GW it works pretty well (depending on IOS on your gateway version of course). I have settled on the IOS version 12.4.22yb4 currently while running MTPS onboard the router in software(this uses the router CPU). You can run MTP’s in DSP hardware on an ISR but I believe this to be a waste of resources unless your router is under significant load. DSP’s are very costly and can significantly increase the cost of router hardware. My advice is save these resources for transcoding or conferencing for which DSP’s are a requirement in your Cisco environment. The MTP configuration is below for an IOS router. Take note that although you can name your MTP anything you want there is a 15 character limit. In my case I have called it MTPOCSRouter1. The name must be unique for registration in CUCM. Whats also important is that you have the priority of the of your CUCM subscribers that same as the preference of you dial peers. I have seen one way audio occurrence because this wasn’t set correctly.
sccp local FastEthernet0/0
sccp ccm XX.XX.XX.XX identifier 1 version 4.1
sccp ccm XX.XX.XX.XX identifier 2 version 4.1
sccp
!
sccp ccm group 1
description SCCP CCM group
bind interface FastEthernet0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 101 register MTPOCSRouter1
!
!
dspfarm profile 101 mtp
codec g711ulaw
maximum sessions software 200
associate application SCCP
Below is a diagram to show the full configuration. MTP’s located on the ISR router as well as traffic to the OCS environment passing through the ISR working as an IP-IP GW. This is for a single site like a datacenter where call volumes may be high and you need redundancy. You can also apply the same logic to a branch where you may also have a ISR located for local PSTN access for your Cisco deployment. Placing a mediation server and MTP local will stop tromboning calls across the WAN which is what would happen is both the mediation server and MTP’s where located in a central site and a OC user at a remote site calling a Cisco user at the same remote site. So not much point having one without the other.
In the diagram it shows the MTP as separate entities bound to just one trunk. You could have pooled the MTP resources in to one media resource group but what this could lead to is media traffic having to flow through two device before reaching the medaiton server. Not a desired behaviour and has no benefit. Best bet is to only allow the MTP’s on each gateway only be used for that gateway. One to one if you would like to consider that way.
Although not shown in the first diagram the MTP’s are controlled using Skinny similar to the Cisco IP phone. Skinny is a Cisco propritiory protocol.
CUCM 5.x,6.x and 7.x
The use of MTPs looks somewhat different as you do not have RTP flows having to transition through the ISR for any other reason than the MTP’s themselves. The ISR is now removed from the call signaling flow and the MTP’s are pooled together as a single resource rather than for just one connection.
MTP’s are an unfortunate evil in the interop story between these two infrastructures. If for instance your entire infrastructure was SIP on the Cisco side MTP’s would be much less of a problem but since most Cisco deployments have a mix of control protocols (SCCP, H323 and MGCP) they are a requirement.
Subscribe to:
Posts (Atom)
Posts
