In case you haven’t see the UC Interoperability Forum yet here it is. I am in New York this week but when I get back from vacation I will be taking a closer look at the Forum and the positive impact this could potentially have in the UC space. It has been a long time coming.
Comments welcomed.
VoIPNorm
VoIPNorm’s Myth Busters
Recently on UC strategies Dave Michaels wrote an opinion piece on Microsoft’s UC strategy. I am always interested to read or hear what independent industry analysts have to say on the topic because it is my belief that they are typically an unbiased opinion based upon well researched material. Even though Dave brought forward some valid points he certainly has fallen victim to some common myths and generalities around Microsoft’s UC strategy.
As you can guess Dave received some feedback in the comments on his piece that make just as interesting reading as the article itself. Some in his favor others not so much. While I don’t call into questions Dave’s motives or research method I felt compelled to talk about some of the common myths and generalities that Dave has called out and some others that I have heard over the last few years.
I can’t take all the credit for collecting the myth’s that I will be covering in the next few posts. Darryl Rowe (a fellow voice warrior from Microsoft) was kind enough to collaborate with me on these posts which I hope people enjoy.
So without any further ado:
In no particular order:
Myth#1” Microsoft only supports its own proprietary voice codec.”
As a matter of fact Communicator 2007 R2 supports a total of 7 voice codecs besides RTAudio.
While it is true that the mediation server only supports RTAudio (OCS Side) and G.711 for connectivity to the PSTN, Communicator supports this full list of codec’s.
While on the subject of the mediation server, Dave’s article calls out the mediation server with “to transcode every external call is a questionable trade-off”. This is incorrect. The two main reasons the mediation server is required in OCS R2 is transcoding and encryption. In saying that, not every call to the PSTN is transcoded in OCS R2. Microsoft recognized the fact that LAN calls really do not require the use of RTAudio where there is less jitter and latency. Also when calling the PSTN RTAudio will always fall back to narrowband due to the fact that the PSTN does not support wideband . So whenever a Communicator endpoint is within 20ms of a mediation server it uses G.711 and there is no transcoding required only encryption.
RTAudio is proprietary but it has been licensed by a number of vendors (including Tandberg which we all know by now is part of Cisco). That of course doesn’t make it open just easily obtainable under license. I don’t believe you can truly call it open until it is ratified by the IETF as an RFC and it is free to use, but this is just my opinion. Even though G.729 may be a recommended standard according to the ITU, guess what, you still have to pay a license so I have trouble with discerning something as a standard when you still need to pay for it. It may as well be propriety.
So, after dissecting this myth a little. I think we can safely say it is BUSTED.
Myth#2 “Microsoft doesn’t support quality of Service (QoS)”
If you have followed my blog at any length you already know this is false. While I have argued the validity of certain areas of QoS and their necessity, it is universally agreed that it is an important architecture element of any VoIP enterprise network, hence the reason OCS supports DSCP both at a server and desktop level. Does this get easier and better with Windows 7 and CS14? Absolutely, but the current product still supports QoS.
With that in mind, there is no QoS on the internet which more and more enterprises are leaning on for remote workers and intercompany traffic. So while having QoS on the enterprise network is fine, using RTAudio gives the enterprise some ability to achieve call quality over the internet and other uncontrolled networks. More company’s are moving towards these types of codec’s, Microsoft isn't alone. Google’s purchase of GIS and acquiring the rights to iSAC (a propriety adaptive codec), which was submitted to the IETF in conjunction with Cisco, shows that this isn't just a Microsoft trend but an industry trend. Variable bandwidth codecs are the way of the future, solidifying Microsoft’s initiatives behind RTAudio.
So after dissecting this myth a little. I think we can safely say it is BUSTED.
Myth#3 “Microsoft does not support SIP endpoints”
Probably the most common reason that generic SIP phones cannot register with OCS is because they do not support SIP/TLS over TCP which is an integral part of the OCS design. Now with that said, there is an open standard SIP phone manufacture (SNOM) that has in fact gone and created a firmware load that supports direct registration with OCS using SIP/TLS.
How is this possible? Microsoft, as with nearly every manufacture, supports the standard SIP RFC’s(RFC 3261 etc, etc).
Is it possible for other phone manufactures to do the same? Absolutely.
But don’t they need to implement RTAudio? No they don’t as SNOM has proven with using the other supported OCS codecs (G.711 and G.722).
Even though SNOM is not a Microsoft certified endpoint, SNOM has been fully supporting its OCS(snom Open Communication Solution Edition)edition for a few years now and has a SNOM supported production firmware build.
So after dissecting this myth a little. I think we can safely say it is BUSTED.
Well, thats all for MythBusters this week. I am on vacation next week but look forward to busting more myths on my return.
Comments welcomed.
VoIPNorm
As you can guess Dave received some feedback in the comments on his piece that make just as interesting reading as the article itself. Some in his favor others not so much. While I don’t call into questions Dave’s motives or research method I felt compelled to talk about some of the common myths and generalities that Dave has called out and some others that I have heard over the last few years.
I can’t take all the credit for collecting the myth’s that I will be covering in the next few posts. Darryl Rowe (a fellow voice warrior from Microsoft) was kind enough to collaborate with me on these posts which I hope people enjoy.
So without any further ado:
In no particular order:
Myth#1” Microsoft only supports its own proprietary voice codec.”
As a matter of fact Communicator 2007 R2 supports a total of 7 voice codecs besides RTAudio.
While it is true that the mediation server only supports RTAudio (OCS Side) and G.711 for connectivity to the PSTN, Communicator supports this full list of codec’s.
While on the subject of the mediation server, Dave’s article calls out the mediation server with “to transcode every external call is a questionable trade-off”. This is incorrect. The two main reasons the mediation server is required in OCS R2 is transcoding and encryption. In saying that, not every call to the PSTN is transcoded in OCS R2. Microsoft recognized the fact that LAN calls really do not require the use of RTAudio where there is less jitter and latency. Also when calling the PSTN RTAudio will always fall back to narrowband due to the fact that the PSTN does not support wideband . So whenever a Communicator endpoint is within 20ms of a mediation server it uses G.711 and there is no transcoding required only encryption.
RTAudio is proprietary but it has been licensed by a number of vendors (including Tandberg which we all know by now is part of Cisco). That of course doesn’t make it open just easily obtainable under license. I don’t believe you can truly call it open until it is ratified by the IETF as an RFC and it is free to use, but this is just my opinion. Even though G.729 may be a recommended standard according to the ITU, guess what, you still have to pay a license so I have trouble with discerning something as a standard when you still need to pay for it. It may as well be propriety.
So, after dissecting this myth a little. I think we can safely say it is BUSTED.
Myth#2 “Microsoft doesn’t support quality of Service (QoS)”
If you have followed my blog at any length you already know this is false. While I have argued the validity of certain areas of QoS and their necessity, it is universally agreed that it is an important architecture element of any VoIP enterprise network, hence the reason OCS supports DSCP both at a server and desktop level. Does this get easier and better with Windows 7 and CS14? Absolutely, but the current product still supports QoS.
With that in mind, there is no QoS on the internet which more and more enterprises are leaning on for remote workers and intercompany traffic. So while having QoS on the enterprise network is fine, using RTAudio gives the enterprise some ability to achieve call quality over the internet and other uncontrolled networks. More company’s are moving towards these types of codec’s, Microsoft isn't alone. Google’s purchase of GIS and acquiring the rights to iSAC (a propriety adaptive codec), which was submitted to the IETF in conjunction with Cisco, shows that this isn't just a Microsoft trend but an industry trend. Variable bandwidth codecs are the way of the future, solidifying Microsoft’s initiatives behind RTAudio.
So after dissecting this myth a little. I think we can safely say it is BUSTED.
Myth#3 “Microsoft does not support SIP endpoints”
Probably the most common reason that generic SIP phones cannot register with OCS is because they do not support SIP/TLS over TCP which is an integral part of the OCS design. Now with that said, there is an open standard SIP phone manufacture (SNOM) that has in fact gone and created a firmware load that supports direct registration with OCS using SIP/TLS.
How is this possible? Microsoft, as with nearly every manufacture, supports the standard SIP RFC’s(RFC 3261 etc, etc).
Is it possible for other phone manufactures to do the same? Absolutely.
But don’t they need to implement RTAudio? No they don’t as SNOM has proven with using the other supported OCS codecs (G.711 and G.722).
Even though SNOM is not a Microsoft certified endpoint, SNOM has been fully supporting its OCS(snom Open Communication Solution Edition)edition for a few years now and has a SNOM supported production firmware build.
So after dissecting this myth a little. I think we can safely say it is BUSTED.
Well, thats all for MythBusters this week. I am on vacation next week but look forward to busting more myths on my return.
Comments welcomed.
VoIPNorm
VoIPNorm Stats
So recently if you subscribe to VoIPNorm you may have noticed a change in the way the feed comes to your inbox or RSS folder etc. Now you have to click on the link to view the content. I didn’t do this just to annoy everyone, I actually have a real reason. I wanted to get a better idea of what people are viewing to help me provide better content. I also wanted to know just how many people are visiting the blog. Some of this I have solved with Feedburner but looking at Feedburner just doesn’t give me a warm fuzzy feeling that these stats are accurate.
If you look at the stats above, Monday saw a sudden increase in hits. This is mainly attributed to this change. Unfortunately my blog doesn’t get hits in the thousands as you can see, I guess you could say I am working in a niche market but this isn’t going to stop me from doing what I do. I think the biggest benefit to my blog is it helps me connect with people. When I meet someone for the first time and they have already seen my blog it automatically opens a connection.
I am interested in what other people that blog about UC see as far as traffic. So if you have a UC blog let me know your blog name and feed/hit count.
Comments welcomed.
VoIPNorm
If you look at the stats above, Monday saw a sudden increase in hits. This is mainly attributed to this change. Unfortunately my blog doesn’t get hits in the thousands as you can see, I guess you could say I am working in a niche market but this isn’t going to stop me from doing what I do. I think the biggest benefit to my blog is it helps me connect with people. When I meet someone for the first time and they have already seen my blog it automatically opens a connection.
I am interested in what other people that blog about UC see as far as traffic. So if you have a UC blog let me know your blog name and feed/hit count.
Comments welcomed.
VoIPNorm
Ringback, Ringback, Ringback where are you?
Ringback has been an issue that has surfaced quite a few times over the period I have worked with OCS R2 and nearly every time is surfaces it’s related to early media. It seems something relatively simple but it does seem hard to get right in the SIP world. I really want this post to be more of an analysis in nature rather than a he said she said type deal with RFC’s used to poke other vendors in the eye. In saying that I will take a look at what some of the claims being made by Cisco in their configuration documents and whether they can withstand the test of being compared to RFC information.
So what is ringback? According to RFC 3261:
RFC 3261 does have some information about ringback and the way it is generated but doesn’t really go into the way it should be generated with the use of early media. RFC 3960 is the best resource on how things are supposed to function in a SIP world with early media and ringtone.
There is some interesting information in this RFC which depending on how a vendor implements it, could make a world of difference when doing interoperability. Let’s just say there are a lot of shoulds and coulds in this document that mean it is open for interpretation. It also calls out some complications for the methods of establishing early media for ringback in particular when signaling packets arrive at different times from media.
So I am not going to break down the RFC bit by bit but just call out a couple of interesting sections . The first one is:
This is a pretty interesting part because even though it begins with a SHOULD it pretty clearly defines how to implement early media and provide ringback. Keeping this in mind though it can provide some interesting issues which brings me to the next section:
The passage above is kind of self-explanatory. If the media gets there in time all well and good. But if for some reason its delayed what should be done in the meantime. Guess what, play local ringback until it does. Sort of seems like a duh moment right there. This really lends itself to also the fact that just because its negotiated doesn’t mean that the UAS is going to send any media at all, so in that situation play local ringback.
This is pretty much follows how Office Communications Server implements early media to stop audio clipping during ICE negotiations. The Communications Server team talk about in their blog here.
Lets take a closer look how its done in OCS. Using a 183 session progress message with SDP the mediation server now waits for the PRACK response.:
Received:
SIP/2.0 183 Session Progress
FROM: "Norman, Christopher";tag=12495098-1453
TO:;tag=7c679c5a62;epid=53CEB3AA6E
CSEQ: 101 INVITE
CALL-ID: 5399E937-489511DE-887FD928-A02D50B2@192.168.18.46
VIA: SIP/2.0/TCP 192.168.18.46:5060;branch=z9hG4bK39F25
CONTACT:
CONTENT-LENGTH: 254
CONTENT-TYPE: application/sdp; charset=utf-8
ALLOW: UPDATE
REQUIRE: 100rel
SERVER: RTCC/3.5.0.0 MediationServer
Rseq: 1
v=0
o=- 46 1 IN IP4 130.42.18.28
s=session
c=IN IP4 130.42.18.28
b=CT:1000
t=0 0
m=audio 63940 RTP/AVP 0 101
c=IN IP4 130.42.18.28
a=rtcp:63941
a=label:Audio
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
The mediation server now waits for the PRACK response:
004386: May 25 19:01:45.793: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
PRACK sip:xch.contoso.com:5060;maddr=192.168.18.36;transport=Tcp SIP/2.0
Date: Mon, 25 May 2009 19:01:45 GMT
From: "Norman, Christopher";tag=12495098-1453
RAck: 1 101 INVITE
Allow-Events: telephone-event
Content-Length: 0
To:;tag=7c679c5a62
Call-ID: 5399E937-489511DE-887FD928-A02D50B2@130.42.18.46
Via: SIP/2.0/TCP 192.168.18.46:5060;branch=z9hG4bK3A22AA
CSeq: 102 PRACK
Max-Forwards: 70
This establishes the media channel before the call has begun. This is pretty standard stuff. Early media can be negotiated with a 180 ringing message as well but in OCS’s case its use only the 183 w/SDP. In the case of OCS it does not send the ringback tone to the UAC. Therefor the local endpoint needs to have a policy as described in the RFC to overcome this and play ringback locally.
Here is where we run into some claims made by Cisco in their configuration documentation.
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/861590.pdf
And:
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/8464511.pdf
These are both interesting comments. First one makes the claim that Microsoft hasn’t followed a mysterious RFC which isn’t named that a majority of PBX’s in the field follow. Is this a very deceptive way of saying no one is following the RFC? I am not sure. Interesting that Cisco would call out an entire industry as not correctly following an RFC. The second is basically a fix because once a Cisco endpoint accepts the early media it no longer checks to see if there are any media packets to see whether it should still play a ringback local as the RFC suggests .Notice I use the word suggests. The RFC specifies should and not must for this functionality and only suggests a possible policy, so neither vendor is really in the wrong here. So do their claims stack up, well shaky at best I feel. Blaming Microsoft for broken functionality is really a stretch as I have proven in this case.
Below I have tried to gather a few things that may help with ringback issues with other vendors. I have outlined a few links and a possible fix where I can. Some of these are notes I have collected that I have not tested myself so as I said possible fixes.
Nortel
http://support.microsoft.com/kb/963126
Cisco
CUCM Direct SIP with OCS
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/861590.pdf
CUCM via CUBE to OCS
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/8464511.pdf
Technet discussion on Cisco ISR and ringback fix
http://social.microsoft.com/Forums/en-US/communicationsservertelephony/thread/b7f0c3d2-4e5b-4c92-aa7a-0b3541f758a9
Avaya
Ringback with OCS fixed CM 5.2.1 SP#2. If a call was made over a SIP trunk, the originator did not hear ringback if 183 Session Progress was received after 180 Ringing and the far end had already sent back SDP information either in 180 Ringing or 183 Session Progress.
If you have a ringback fix from another vendor let me know and I will post it up here.
Thanks to Dave and Aamer for providing me with ideas for this post.
Comments welcomed.
VoIPNorm
So what is ringback? According to RFC 3261:
"Ringback: Ringback is the signaling tone produced by the calling party's application indicating that a called party is being alerted (ringing)."
RFC 3261 does have some information about ringback and the way it is generated but doesn’t really go into the way it should be generated with the use of early media. RFC 3960 is the best resource on how things are supposed to function in a SIP world with early media and ringtone.
There is some interesting information in this RFC which depending on how a vendor implements it, could make a world of difference when doing interoperability. Let’s just say there are a lot of shoulds and coulds in this document that mean it is open for interpretation. It also calls out some complications for the methods of establishing early media for ringback in particular when signaling packets arrive at different times from media.
So I am not going to break down the RFC bit by bit but just call out a couple of interesting sections . The first one is:
“With this in mind, a UAC should develop its local policy regarding local ringing generation. For example, a POTS ("Plain Old Telephone Service")-like SIP User Agent (UA) could implement the following local policy:
1. Unless a 180 (Ringing) response is received, never generate local ringing.
2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing.
3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing.
Note that a 180 (Ringing) response means that the callee is being alerted, and a UAS should send such a response if the callee is being alerted, regardless of the status of the early media session.”
This is a pretty interesting part because even though it begins with a SHOULD it pretty clearly defines how to implement early media and provide ringback. Keeping this in mind though it can provide some interesting issues which brings me to the next section:
“One important reason limiting the benefit of a potential early media indicator is the loose coupling between SIP signalling and the media path. SIP signalling traverses a different path than the media. The
media path is typically optimized to reduce the end-to-end delay (e.g., minimum number of intermediaries), while the SIP signalling path typically traverses a number of proxies providing different
services for the session. Hence, it is very likely that the media packets with early media reach the UAC before any SIP message that could contain an early media indicator.
Nevertheless, sometimes SIP responses arrive at the UAC before any media packet. There are situations in which the UAS intends to send early media but cannot do it straight away. For example, UAs using Interactive Connectivity Establishment (ICE) [6] may need to exchange several Simple Traversals of the UDP Protocol through NAT (STUN) messages before being able to exchange media. In this situation, an early media indicator would keep the UAC from generating a local ringing tone during this time. However, while the early media is not arriving at the UAC, the user would not be aware that the remote user is being alerted, even though a 180 (Ringing) had been received. Therefore, a better solution would be to apply a local ringing tone until the early media packets could be sent from the UAS to the UAC. This solution does not require any early media indicator.”
The passage above is kind of self-explanatory. If the media gets there in time all well and good. But if for some reason its delayed what should be done in the meantime. Guess what, play local ringback until it does. Sort of seems like a duh moment right there. This really lends itself to also the fact that just because its negotiated doesn’t mean that the UAS is going to send any media at all, so in that situation play local ringback.
This is pretty much follows how Office Communications Server implements early media to stop audio clipping during ICE negotiations. The Communications Server team talk about in their blog here.
Lets take a closer look how its done in OCS. Using a 183 session progress message with SDP the mediation server now waits for the PRACK response.:
Received:
SIP/2.0 183 Session Progress
FROM: "Norman, Christopher"
TO:
CSEQ: 101 INVITE
CALL-ID: 5399E937-489511DE-887FD928-A02D50B2@192.168.18.46
VIA: SIP/2.0/TCP 192.168.18.46:5060;branch=z9hG4bK39F25
CONTACT:
CONTENT-LENGTH: 254
CONTENT-TYPE: application/sdp; charset=utf-8
ALLOW: UPDATE
REQUIRE: 100rel
SERVER: RTCC/3.5.0.0 MediationServer
Rseq: 1
v=0
o=- 46 1 IN IP4 130.42.18.28
s=session
c=IN IP4 130.42.18.28
b=CT:1000
t=0 0
m=audio 63940 RTP/AVP 0 101
c=IN IP4 130.42.18.28
a=rtcp:63941
a=label:Audio
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
The mediation server now waits for the PRACK response:
004386: May 25 19:01:45.793: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
PRACK sip:xch.contoso.com:5060;maddr=192.168.18.36;transport=Tcp SIP/2.0
Date: Mon, 25 May 2009 19:01:45 GMT
From: "Norman, Christopher"
RAck: 1 101 INVITE
Allow-Events: telephone-event
Content-Length: 0
To:
Call-ID: 5399E937-489511DE-887FD928-A02D50B2@130.42.18.46
Via: SIP/2.0/TCP 192.168.18.46:5060;branch=z9hG4bK3A22AA
CSeq: 102 PRACK
Max-Forwards: 70
This establishes the media channel before the call has begun. This is pretty standard stuff. Early media can be negotiated with a 180 ringing message as well but in OCS’s case its use only the 183 w/SDP. In the case of OCS it does not send the ringback tone to the UAC. Therefor the local endpoint needs to have a policy as described in the RFC to overcome this and play ringback locally.
Here is where we run into some claims made by Cisco in their configuration documentation.
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/861590.pdf
"OCS 2007 R2 implementation of Early Media does not follow the standard implementation of the RFC used by the majority of PBX’s in the field. As a result Cisco UCM behavior might be different from what some early media test scenarios from the Microsoft test plan expect."
And:
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/8464511.pdf
"Early-media negotiation may not be supported due to the new provisional response mechanism implemented on Microsoft OCS 2007 R2. Microsoft OCS 2007 R2 sends three provisional responses to a single INVITE (183 w/SDP, 180, 183) which causes incompatibility agaianst Cisco UBE which expects ringback media to flow from the Miscrosoft OCS due to the 183 with SDP response message (early media indication), but the Microsoft OCS does not send ringback media and the calling user never hears ringback. The workaround is to use the command “voice-class sip block 183 sdp present” and apply it to the appropriate dial-peer, not globally, in Cisco UBE to block all 183 messages from msft OCS toward
Cisco UCM allowing only 180 message to be sent to Cisco UCM and receiving local generated ringback on the calling side."
These are both interesting comments. First one makes the claim that Microsoft hasn’t followed a mysterious RFC which isn’t named that a majority of PBX’s in the field follow. Is this a very deceptive way of saying no one is following the RFC? I am not sure. Interesting that Cisco would call out an entire industry as not correctly following an RFC. The second is basically a fix because once a Cisco endpoint accepts the early media it no longer checks to see if there are any media packets to see whether it should still play a ringback local as the RFC suggests .Notice I use the word suggests. The RFC specifies should and not must for this functionality and only suggests a possible policy, so neither vendor is really in the wrong here. So do their claims stack up, well shaky at best I feel. Blaming Microsoft for broken functionality is really a stretch as I have proven in this case.
Below I have tried to gather a few things that may help with ringback issues with other vendors. I have outlined a few links and a possible fix where I can. Some of these are notes I have collected that I have not tested myself so as I said possible fixes.
Nortel
http://support.microsoft.com/kb/963126
Cisco
CUCM Direct SIP with OCS
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/861590.pdf
CUCM via CUBE to OCS
http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/8464511.pdf
Technet discussion on Cisco ISR and ringback fix
http://social.microsoft.com/Forums/en-US/communicationsservertelephony/thread/b7f0c3d2-4e5b-4c92-aa7a-0b3541f758a9
Avaya
Ringback with OCS fixed CM 5.2.1 SP#2. If a call was made over a SIP trunk, the originator did not hear ringback if 183 Session Progress was received after 180 Ringing and the far end had already sent back SDP information either in 180 Ringing or 183 Session Progress.
If you have a ringback fix from another vendor let me know and I will post it up here.
Thanks to Dave and Aamer for providing me with ideas for this post.
Comments welcomed.
VoIPNorm
Using Remote MTP Resources for OCS Interoperability with CUCM
Sometimes in life, things are a fine art to get just right. Media Termination Points are kind of like that along with other resources in the Cisco VoIP infrastructure. Knowing where to place them and what resources to use can be a little confusing to those new to Cisco VoIP or those trying to do interoperability to Microsoft Office Communications Server for the first time. This post builds upon a much earlier post I did on configuring MTP’s for interoperability with OCS.
The number one rule to remember when doing interop Between CUCM and OCS is if you want to avoid having VoIP trombone across your WAN links is you’re going to need to place some MTP’s at the same site as a mediation server. Although the SIP traffic is not going to be routed to your MTP’s from the mediation server, RTP traffic certainly will. So how is this accomplished?
First off, for every mediation server you are going to allocate a SIP trunk in CUCM (doesn’t matter what version it’s all the same). Secondly, you’re going to need to build the MTP, a Media Resource Group and a Media Resource Group List. Of course the media resource group and the media resource group list can contain more than just MTP’s but to keep things simple I like to have specifically defined groups and lists just for the SIP trunk to which you want to control the flow of RTP traffic. Example below:
In this example I have shown a workflow of what the MTP design would look like within CUCM. At your main site if your CUCM servers aren’t terribly taxed you could actually host your MTP’s on the CUCM subscriber servers themselves but at the remote site you would need a local MTP resource to avoid the trombone effect I described earlier with RTP.
This next diagram shows a simplistic picture of the signaling and RTP traffic that is happening between a Cisco IP Phone and Microsoft Communicator endpoint. I have removed the endpoint signaling traffic just to simplify the example a little. But as you can see the RTP local to the site stays local when you have the right resources in place.
In this example I have used the design of configuring the MTP resources on the ISR devices utilizing either DSP hardware or router software. Using DSP’s might be a good idea if your router is multitasked and its CPU utilization is already seeing regular usage beyond 50-60%.
The idea behind this post comes from some recent questions from customers in regards to remote site configuration. This type of design is for the current version of OCS 2007 R2 when doing interoperability to a CUCM environment, how this will change in the future is yet to be seen.
Comments welcomed
VoIPNorm
The number one rule to remember when doing interop Between CUCM and OCS is if you want to avoid having VoIP trombone across your WAN links is you’re going to need to place some MTP’s at the same site as a mediation server. Although the SIP traffic is not going to be routed to your MTP’s from the mediation server, RTP traffic certainly will. So how is this accomplished?
First off, for every mediation server you are going to allocate a SIP trunk in CUCM (doesn’t matter what version it’s all the same). Secondly, you’re going to need to build the MTP, a Media Resource Group and a Media Resource Group List. Of course the media resource group and the media resource group list can contain more than just MTP’s but to keep things simple I like to have specifically defined groups and lists just for the SIP trunk to which you want to control the flow of RTP traffic. Example below:
In this example I have shown a workflow of what the MTP design would look like within CUCM. At your main site if your CUCM servers aren’t terribly taxed you could actually host your MTP’s on the CUCM subscriber servers themselves but at the remote site you would need a local MTP resource to avoid the trombone effect I described earlier with RTP.
This next diagram shows a simplistic picture of the signaling and RTP traffic that is happening between a Cisco IP Phone and Microsoft Communicator endpoint. I have removed the endpoint signaling traffic just to simplify the example a little. But as you can see the RTP local to the site stays local when you have the right resources in place.
In this example I have used the design of configuring the MTP resources on the ISR devices utilizing either DSP hardware or router software. Using DSP’s might be a good idea if your router is multitasked and its CPU utilization is already seeing regular usage beyond 50-60%.
The idea behind this post comes from some recent questions from customers in regards to remote site configuration. This type of design is for the current version of OCS 2007 R2 when doing interoperability to a CUCM environment, how this will change in the future is yet to be seen.
Comments welcomed
VoIPNorm
CUCM handling of REFERs for Exchange 2010/2007 UM Dial Plans
CUCM handling of REFERs for Ex2010UM/Ex2007UM Dial Plans
Below is an interesting situation that may occur as you head down your migration path from Exchange Unified Messaging 2007 to 2010. In case you didn’t already know a Exchange 2007 and 2010 UM server can be part of the same dial plan for the purposes of mailbox migration. When a call from CUCM hits the Exchange 2010 UM server it uses a REFFER to transfer the call to the Exchange 2007 server if the user hasn’t been migrated yet. This is a pretty simplistic description but I think you get the idea. This link fully describes the migration process from Exchange 2007 to 2010.
Thanks to Dave Howe for providing the following information.
ProblemCisco Unified Communications Manager (CUCM) does not handle REFER properly for Ex2010UM/Ex2007UM Dial Plans
Configuration
(UM) Dial Plan is associated both Ex2010UM and Ex2007UM servers
(Cisco) SIP Trunk configured between CUCM and Ex2010UM server
(Cisco) Route Pattern for SA Pilot (70000) configured to use SIP Trunk
Behavior
Caller dials 70000 (SA Pilot Number)
-Call is placed from an unrecognized number (PSTN, conference room, etc)
-Caller has Exchange 2007 mailbox and is enabled for Unified Messaging
Ex2010UM server does not recognize caller, answers and prompts for extension
Caller enters extension, mailbox resolves to Exchange 2007 server
Ex2010UM server sends REFER to CUCM to transfer the caller to Ex2007UM server
CUCM responds with 202 Accepted, followed by two NOTIFY packets with 404 Not Found (transfer fails)
Ex2010UM cannot handle call, disconnects after telling caller that mailbox version is unsupported
Issue #1
DNS resolution failure
REFER-TO header sent from Ex2010UM contains FQDN of Ex2007UM server
REFER-TO:
CUCM must be able to resolve FQDN of Ex2007UM server to routable IP address
Issue #2
FQDN of Ex2007UM server sent in REFER-TO header is not defined as a routing target within CUCM
Route Pattern is used to route calls placed to extension 70000 to the IP address of Ex2010UM server
SIP Route Pattern containing FQDN of Ex2007UM server is required
In CUCM Administration UI:
1. Go to Call Routing > SIP Route Pattern > Add New
2. Select Domain Routing, enter the FQDN of the Ex2007UM server, then select the Ex2010UM trunk
3. Select the correct Route Partition, then click Save
Issue #3
INVITE from referred calls handled by CUCM do not contain REFERRED-BY information
Extension entered by caller is provided by Ex2010UM server in REFERRED-BY header
REFERRED-BY:
CUCM fails to use the REFERRED-BY extension in the INVITE that is sent to the Ex2007UM server
Caller hears, “Welcome, you are connected ….” and is prompted to enter their extension a second time
No workaround, contact Cisco (UM Product Group has a ticket open with them)
Below is an interesting situation that may occur as you head down your migration path from Exchange Unified Messaging 2007 to 2010. In case you didn’t already know a Exchange 2007 and 2010 UM server can be part of the same dial plan for the purposes of mailbox migration. When a call from CUCM hits the Exchange 2010 UM server it uses a REFFER to transfer the call to the Exchange 2007 server if the user hasn’t been migrated yet. This is a pretty simplistic description but I think you get the idea. This link fully describes the migration process from Exchange 2007 to 2010.
Thanks to Dave Howe for providing the following information.
ProblemCisco Unified Communications Manager (CUCM) does not handle REFER properly for Ex2010UM/Ex2007UM Dial Plans
Configuration
(UM) Dial Plan is associated both Ex2010UM and Ex2007UM servers
(Cisco) SIP Trunk configured between CUCM and Ex2010UM server
(Cisco) Route Pattern for SA Pilot (70000) configured to use SIP Trunk
Behavior
Caller dials 70000 (SA Pilot Number)
-Call is placed from an unrecognized number (PSTN, conference room, etc)
-Caller has Exchange 2007 mailbox and is enabled for Unified Messaging
Ex2010UM server does not recognize caller, answers and prompts for extension
Caller enters extension, mailbox resolves to Exchange 2007 server
Ex2010UM server sends REFER to CUCM to transfer the caller to Ex2007UM server
CUCM responds with 202 Accepted, followed by two NOTIFY packets with 404 Not Found (transfer fails)
Ex2010UM cannot handle call, disconnects after telling caller that mailbox version is unsupported
Issue #1
DNS resolution failure
REFER-TO header sent from Ex2010UM contains FQDN of Ex2007UM server
REFER-TO:
CUCM must be able to resolve FQDN of Ex2007UM server to routable IP address
Issue #2
FQDN of Ex2007UM server sent in REFER-TO header is not defined as a routing target within CUCM
Route Pattern is used to route calls placed to extension 70000 to the IP address of Ex2010UM server
SIP Route Pattern containing FQDN of Ex2007UM server is required
In CUCM Administration UI:
1. Go to Call Routing > SIP Route Pattern > Add New
2. Select Domain Routing, enter the FQDN of the Ex2007UM server, then select the Ex2010UM trunk
3. Select the correct Route Partition, then click Save
Issue #3
INVITE from referred calls handled by CUCM do not contain REFERRED-BY information
Extension entered by caller is provided by Ex2010UM server in REFERRED-BY header
REFERRED-BY:
CUCM fails to use the REFERRED-BY extension in the INVITE that is sent to the Ex2007UM server
Caller hears, “Welcome, you are connected ….” and is prompted to enter their extension a second time
No workaround, contact Cisco (UM Product Group has a ticket open with them)
Support for Direct SIP for CUCM 7.1.3 and OCS 2007 R2
In case you haven’t visited the OCS OIP page recently there has been an update to include Cisco UCM 7.1.3. With that Cisco have also released a Direct SIP interoperability document for that version. Cisco has done a good job of documenting the configuration with what information was probably available at the time. There are a few things that have been released since this document was written that will help with this interoperability further that I have outlined below. I think Cisco have done a good job at collecting current issues that can occur with this interoperability. They call out some now resolved Microsoft issues as well as a lot of their own current issues. Also interesting, whether intentional or not is some questionable material in the last limitation section which is surprising to have in a configuration document. Maybe Cisco are just trying to clearly (not sure clearly is the right word) outline what Cisco are supporting but they seem more like blanket compete statements to me.
The first section covers the tools and testing procedures used. They also make mention that E.164 is used throughout the document which is also a plus. E.164 seems to be the direction Cisco is now heading with the release of IME which requires E.164. There is also a plug for CUCiMOC in this first section. For those of you that have read my blog for some time, you will already know how I feel about a plugin versus native features in Communicator but for those that haven’t please feel free to check it out.
The limitations section has a few points that have changed due to newly available updates that have resolved the issues noted. The first one is –
This has been available for some time with the update mentioned here.
Next is a recent topic here on VoIPNorm with the RTCP incompatibilities. –
This has been resolved with update mentioned here.
I understand that these things would appear in a Cisco document since they may not be tracking every update of OCS or the document was released after the fact.
The last section on known limitations has a couple of interesting lines that are in no way related to Direct SIP interoperability but I thought it would be good to mention them anyway. They are really generalized statements that had they been given some direction may have made sense in relation to the content but they were just sort of flopped out there. Some of these statements are correct and Microsoft are resolving them with Communication Server “14” and some are a little misleading.
This first comment is correct in that the mediation server cannot transcode video. But in saying that there are solutions out there today from Cisco (this is the funny part), that allow an OCS client to talk video with other video endpoints including Cisco endpoints. Here is the one from Cisco that describes using a Cisco MCU to do video interoperability with OCS and Communicator. Furthermore with the acquisition of Tandberg there are a couple of different ways to do video interoperability with what are soon to be Cisco endpoints to OCS through the VCS and Tandberg’s soon to be released UC gateway.
This is a true statement, it’s also true if you substitute “OCS” for any other product or manufacturer besides Cisco. Further as some of the more frequent readers already know CAC has been announced in Communication Server “14” as a new feature. But this is a blanket statement from Cisco. Maybe they have had questions at the TAC over using Cisco CAC on OCS endpoints. If it had been defined better I think that would be more useful to customers.
Again another true statement. OCS users cannot use Cisco’s SRST. Again, feel free to play the ‘substitute your non-Cisco-product-here game – neither can Avaya, Siemens or Sametime clients. As announced at VoiceCon,with Communications Server “14” Microsoft will be Offering their own survivable branch solution called the Survivable Branch Appliance or SBA with Microsoft’s gateway partners. This is another blanket statement but again this may be something that has come up with the TAC.
This statement could have been correct had it been defined more clearly. Again, a blanket statement that doesn’t describe support by who. Certainly ambiguous. Had they said Cisco it would be correct. There are third party providers providing E.911 support for OCS 2007 R2 that I have talked about on my blog here. Had some due diligence been done they would have known that E911 Enable can in fact support OCS R2and CUCM endpoints on the same E911 Enable infrastructure. Its just so happens that E911 Enable (in addition to Intrado) have also announced support for Communications Server “14” in conjunction with native endpoint support being offer by Microsoft.
I do find it a little annoying that Cisco is calling out what another vendor supports in a configuration document, and as I have shown some of them are only partly correct statements anyway. So in the end it detracts from the intention of the document and hurts their credibility somewhat.. That being said, Call Admission Control, Branch Survivability and E911 are three key features coming in CS “14” – and Microsoft is super excited about being able to share them with everyone.
The bulk of the document is actually pretty standard for this style from Cisco. Even though it is mainly just screen shots they have done a good job at getting the configuration documented. In the end I think that people that have OCS and CUCM deployed already may find that this configuration is a little simpler than first thought. If you plan your OCS dial plan correctly it takes little to no management once implemented when used in conjunction with CUCM.
Finally, the following links are done by the Microsoft team to help with Direct SIP configuration for earlier versions of CUCM.
OCS to CUCM 4.x
OCS to CUCM 6.x
Hopefully this was a helpful post and some of the distracting things mentioned in Cisco’s documents get less attention than they really should.
Comments welcomed.
VoIPNorm
The first section covers the tools and testing procedures used. They also make mention that E.164 is used throughout the document which is also a plus. E.164 seems to be the direction Cisco is now heading with the release of IME which requires E.164. There is also a plug for CUCiMOC in this first section. For those of you that have read my blog for some time, you will already know how I feel about a plugin versus native features in Communicator but for those that haven’t please feel free to check it out.
The limitations section has a few points that have changed due to newly available updates that have resolved the issues noted. The first one is –
“OCS 2007 R2 does not support calling and connected name. Cisco UCM sends its calling name and number to mediation server/OCS, but the OC only displays the calling number. Name is not sent by Mediation Server.”
This has been available for some time with the update mentioned here.
Next is a recent topic here on VoIPNorm with the RTCP incompatibilities. –
“During a three-way conference initiated by an OC user the OC user is unable to “mute” any participant that is connected to the conference using a Cisco Unified IP phone. The issue is caused by the incompatibility between Microsoft OCS R2 media keepalive mechanism against Cisco Unified Communications solutions.”
This has been resolved with update mentioned here.
I understand that these things would appear in a Cisco document since they may not be tracking every update of OCS or the document was released after the fact.
The last section on known limitations has a couple of interesting lines that are in no way related to Direct SIP interoperability but I thought it would be good to mention them anyway. They are really generalized statements that had they been given some direction may have made sense in relation to the content but they were just sort of flopped out there. Some of these statements are correct and Microsoft are resolving them with Communication Server “14” and some are a little misleading.
“The Microsoft Mediation Server does not support video transcoding, thus video is not possible between OCS and UCM endpoints.”
This first comment is correct in that the mediation server cannot transcode video. But in saying that there are solutions out there today from Cisco (this is the funny part), that allow an OCS client to talk video with other video endpoints including Cisco endpoints. Here is the one from Cisco that describes using a Cisco MCU to do video interoperability with OCS and Communicator. Furthermore with the acquisition of Tandberg there are a couple of different ways to do video interoperability with what are soon to be Cisco endpoints to OCS through the VCS and Tandberg’s soon to be released UC gateway.
“ Call Admission Control (CAC) is available for UCM endpoints but not OCS endpoints”
This is a true statement, it’s also true if you substitute “OCS” for any other product or manufacturer besides Cisco. Further as some of the more frequent readers already know CAC has been announced in Communication Server “14” as a new feature. But this is a blanket statement from Cisco. Maybe they have had questions at the TAC over using Cisco CAC on OCS endpoints. If it had been defined better I think that would be more useful to customers.
“Survivable Remote Site Telephony (SRST) is available for UCM endpoints but not OCS endpoints”
Again another true statement. OCS users cannot use Cisco’s SRST. Again, feel free to play the ‘substitute your non-Cisco-product-here game – neither can Avaya, Siemens or Sametime clients. As announced at VoiceCon,with Communications Server “14” Microsoft will be Offering their own survivable branch solution called the Survivable Branch Appliance or SBA with Microsoft’s gateway partners. This is another blanket statement but again this may be something that has come up with the TAC.
“E.911 support is available for UCM endpoints but not OCS endpoints.”
This statement could have been correct had it been defined more clearly. Again, a blanket statement that doesn’t describe support by who. Certainly ambiguous. Had they said Cisco it would be correct. There are third party providers providing E.911 support for OCS 2007 R2 that I have talked about on my blog here. Had some due diligence been done they would have known that E911 Enable can in fact support OCS R2and CUCM endpoints on the same E911 Enable infrastructure. Its just so happens that E911 Enable (in addition to Intrado) have also announced support for Communications Server “14” in conjunction with native endpoint support being offer by Microsoft.
I do find it a little annoying that Cisco is calling out what another vendor supports in a configuration document, and as I have shown some of them are only partly correct statements anyway. So in the end it detracts from the intention of the document and hurts their credibility somewhat.. That being said, Call Admission Control, Branch Survivability and E911 are three key features coming in CS “14” – and Microsoft is super excited about being able to share them with everyone.
The bulk of the document is actually pretty standard for this style from Cisco. Even though it is mainly just screen shots they have done a good job at getting the configuration documented. In the end I think that people that have OCS and CUCM deployed already may find that this configuration is a little simpler than first thought. If you plan your OCS dial plan correctly it takes little to no management once implemented when used in conjunction with CUCM.
Finally, the following links are done by the Microsoft team to help with Direct SIP configuration for earlier versions of CUCM.
OCS to CUCM 4.x
OCS to CUCM 6.x
Hopefully this was a helpful post and some of the distracting things mentioned in Cisco’s documents get less attention than they really should.
Comments welcomed.
VoIPNorm
CS 14 Airlift Hangover
Last week some of you may have noticed that I didn’t post. Well, it was an especially busy week with having to attend the Communications Server 14 Airlift in Redmond. This was the first time that I have had the opportunity to attend an Airlift. It was a great week but after having to squeeze as much information into my brain at one time I seem to have a hangover feeling even though I drank no alcohol.
For me, even though I can’t go into any details, PowerShell is going to be a major component in CS 14. Adam mentions it use here. I think it’s a blessing if you're familiar with the constructs of PowerShell and somewhat scary if you’re not. To be honest I am no PowerShell expert, which means I am a little intimidated by it but I can certainly see the potential when combined with its scripting capabilities and anyone that has worked with a command line system before will adapt quickly. After spending 10 years working on Cisco IOS its only a matter of time before I become more comfortable I feel.
Hopefully the next few weeks ease up so I can go back to writing more content here on VoIPNorm. I got some great feedback from people at the Airlift (thanks Henry, Jason and Andrew). One thing people really seem to like is the steady flow of posts. Keeping a blog going with regular posts is a challenge which if you let it, it can fall by the wayside when other more important stuff arises. I am currently in the process of putting together some really interesting posts on some new and not so new interoperability information, so stay tuned over the following weeks.
Comments welcomed.
VoIPNorm
For me, even though I can’t go into any details, PowerShell is going to be a major component in CS 14. Adam mentions it use here. I think it’s a blessing if you're familiar with the constructs of PowerShell and somewhat scary if you’re not. To be honest I am no PowerShell expert, which means I am a little intimidated by it but I can certainly see the potential when combined with its scripting capabilities and anyone that has worked with a command line system before will adapt quickly. After spending 10 years working on Cisco IOS its only a matter of time before I become more comfortable I feel.
Hopefully the next few weeks ease up so I can go back to writing more content here on VoIPNorm. I got some great feedback from people at the Airlift (thanks Henry, Jason and Andrew). One thing people really seem to like is the steady flow of posts. Keeping a blog going with regular posts is a challenge which if you let it, it can fall by the wayside when other more important stuff arises. I am currently in the process of putting together some really interesting posts on some new and not so new interoperability information, so stay tuned over the following weeks.
Comments welcomed.
VoIPNorm
Subscribe to:
Posts (Atom)