Recently a connection on LinkedIn (thanks Jason) brought my attention to RFC 1925, The Twelve Networking Truths. I was kind of ashamed that I didn’t know about this to start with but it may have been I have seen it before and forgotten. I thought if I didn’t know about this or remember there may be other ignorant people like me out there living in caves that haven’t seen this.
http://www.rfc-editor.org/rfc/rfc1925.txt
Not your typical RFC. Although not technical in nature it has some interesting rules that make a lot of sense.I think there is one rule missing though. Rule 13 – No matter how hard you wave an RFC in the air someone, somewhere is interpreting it different than you are so refer back to rule number 1.
Comments welcomed.
VoIPNorm
Collaboration and a whole bunch of other stuff. BTW I work @ Cisco Systems.
Important OCS CUCM Interop Update: RTCP Timer Issue Solved
The KB article is here.
In my last post I talked a little about the issue of Microsoft Cisco interoperability and the issue with RTCP causing Cisco IP phones being dropped from calls when being put on mute while in an OCS audio conference by the conference leader. This is an issue I have been involved in and following for some time. The issue stems from when being put on mute a SIP message is sent telling the Cisco IP phone to go to recvonly and the call subsequently drops because when in recvonly only Cisco IP phones stop send RTCP. The problem here is that when this occurs the mediation server starts an RTCP timer that eventually drops the IP phone from a conference after 30 seconds. Now you may ask why this doesn’t occur when the Cisco IP phone is put on mute at the phone by the end user. Well, glad you asked. When a Cisco IP phone is placed on mute by the end user this is only a physical mute and RTCP packets still flow. Mystery solved:)
Quick diagram of the problem in question.
Cisco IP Phone ----------------------------------OCS
| <--Re-Invite(send Only)-------------|
| (RTCP Receiver Report) GOODBYE-->OCS|
| -----100 Trying------------------->|
| -----200OK (recvonly)------------->|
| <--ACK------------------------------|
| (After 30 secs) |
| <------BYE--------------------------|
| (RTCP Receiver Report) GOODBYE-->OCS|
Although I have only indicated that this affects Cisco IP Phones this issue also affects Cisco Unity and Cisco ISR gateways. The issue with Unity is a little different in that when you are recording a voicemail message Unity doesn’t send RTCP packets and therefore the recording stops at 30 seconds. This KB article should also solve this issue also.
Here is part of the SIP message stream that indicates a media timeout for the Unity issue.
BYE sip:chris.norman@rtctest.contoso.com;opaque=user:epid:U_CefZQFsVm9gVJSmY_DWgAA;gruu SIP/2.0
FROM:;epid=B9723D714F;tag=f823396c4d
TO:;epid=9277a8242a;tag=6e417bfd42
CSEQ: 1 BYE
CALL-ID: 8110143875c0465ea6add6729c04f800
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 130.42.108.237:1620;branch=z9hG4bK8941dab2
ROUTE:
CONTENT-LENGTH: 0
USER-AGENT: RTCC/3.5.0.0 MediationServer
Ms-diagnostics: 10011;source="Server.RTCTEST.TL.CONTOSO.COM";reason="Media Gateway side stream timeout";component="MediationServer"
There has also been a large number of posts on Technet regarding these issues. Here is just one thread but if you look through the other discussions I know there are more.
So what possible side effect could turning this timer off possibly have on a deployment? Well I have not tested this myself but it could possibly leave to open conversation windows that do not close themselves after a call has ended. So the other end of the call hangs up and you leave the conversation window to close on its own, it is conceivable in certain circumstance that it won’t hang up and you will have to manually close it. But again just a theory. Although not a huge issue if this is a result you may have a few user grumbles. But on the flip side having calls stay up is by far more important.
Some notes from the KB article:
On the Microsoft Office Communications Server 2007 R2, Mediation Server, a media time-out occurs. This time-out occurs if no Real-Time Transport Protocol (RTP) packets or Real-Time Control Protocol (RTCP) packets are received for 30 seconds. When Office Communications Server 2007 R2, Mediation Server interacts directly through Session Initiation Protocol (SIP) with Cisco Call Manager (CCM), the following scenarios in which no RTP packets or RTCP packets are received for a call occur:
•For a call that is on hold, the direction attribute is inactive from the perspective of the Mediation Server and the perspective of CCM. In this case, CCM does not send any RTP packets or RTCP packets. Existing Mediation Server code ignored the media time-out. Therefore, the call is not dropped.
•A CCM user joins in an Office Communications Server 2007 R2 conference, and then mutes the telephone. Additionally, the direction attribute for the Mediation Server for the interaction with CCM is sendonly. Additionally, the direction attribute for the phone is recvonly. In this case, CCM does not send any RTP packets or RTCP packets while the telephone is muted. Therefore, the call is dropped after 30 seconds.
•An Office Communicator user calls a CCM user who is configured to use Cisco Unity voice mail. When the call is connected to Cisco Unity, the call obtains the original media packets from Cisco Unity. Then, the Office Communicator user is prompted to leave a voice mail. However, Cisco Unity does not send any RTP packets or RTCP packets when the Office Communicator user leaves a voice mail. Therefore, a media time-out occurs after 30 seconds. Then, the call is disconnected, and the Office Communicator user cannot leave a voice mail.
To solve this issue you will need to download and install the April updates for the mediation server. After you have installed the update the mediation server it set to ignore media timeouts from the gateway.
Comments welcomed.
VoIPNorm
In my last post I talked a little about the issue of Microsoft Cisco interoperability and the issue with RTCP causing Cisco IP phones being dropped from calls when being put on mute while in an OCS audio conference by the conference leader. This is an issue I have been involved in and following for some time. The issue stems from when being put on mute a SIP message is sent telling the Cisco IP phone to go to recvonly and the call subsequently drops because when in recvonly only Cisco IP phones stop send RTCP. The problem here is that when this occurs the mediation server starts an RTCP timer that eventually drops the IP phone from a conference after 30 seconds. Now you may ask why this doesn’t occur when the Cisco IP phone is put on mute at the phone by the end user. Well, glad you asked. When a Cisco IP phone is placed on mute by the end user this is only a physical mute and RTCP packets still flow. Mystery solved:)
Quick diagram of the problem in question.
Cisco IP Phone ----------------------------------OCS
| <--Re-Invite(send Only)-------------|
| (RTCP Receiver Report) GOODBYE-->OCS|
| -----100 Trying------------------->|
| -----200OK (recvonly)------------->|
| <--ACK------------------------------|
| (After 30 secs) |
| <------BYE--------------------------|
| (RTCP Receiver Report) GOODBYE-->OCS|
Although I have only indicated that this affects Cisco IP Phones this issue also affects Cisco Unity and Cisco ISR gateways. The issue with Unity is a little different in that when you are recording a voicemail message Unity doesn’t send RTCP packets and therefore the recording stops at 30 seconds. This KB article should also solve this issue also.
Here is part of the SIP message stream that indicates a media timeout for the Unity issue.
BYE sip:chris.norman@rtctest.contoso.com;opaque=user:epid:U_CefZQFsVm9gVJSmY_DWgAA;gruu SIP/2.0
FROM:
TO:
CSEQ: 1 BYE
CALL-ID: 8110143875c0465ea6add6729c04f800
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 130.42.108.237:1620;branch=z9hG4bK8941dab2
ROUTE:
CONTENT-LENGTH: 0
USER-AGENT: RTCC/3.5.0.0 MediationServer
Ms-diagnostics: 10011;source="Server.RTCTEST.TL.CONTOSO.COM";reason="Media Gateway side stream timeout";component="MediationServer"
There has also been a large number of posts on Technet regarding these issues. Here is just one thread but if you look through the other discussions I know there are more.
So what possible side effect could turning this timer off possibly have on a deployment? Well I have not tested this myself but it could possibly leave to open conversation windows that do not close themselves after a call has ended. So the other end of the call hangs up and you leave the conversation window to close on its own, it is conceivable in certain circumstance that it won’t hang up and you will have to manually close it. But again just a theory. Although not a huge issue if this is a result you may have a few user grumbles. But on the flip side having calls stay up is by far more important.
Some notes from the KB article:
On the Microsoft Office Communications Server 2007 R2, Mediation Server, a media time-out occurs. This time-out occurs if no Real-Time Transport Protocol (RTP) packets or Real-Time Control Protocol (RTCP) packets are received for 30 seconds. When Office Communications Server 2007 R2, Mediation Server interacts directly through Session Initiation Protocol (SIP) with Cisco Call Manager (CCM), the following scenarios in which no RTP packets or RTCP packets are received for a call occur:
•For a call that is on hold, the direction attribute is inactive from the perspective of the Mediation Server and the perspective of CCM. In this case, CCM does not send any RTP packets or RTCP packets. Existing Mediation Server code ignored the media time-out. Therefore, the call is not dropped.
•A CCM user joins in an Office Communications Server 2007 R2 conference, and then mutes the telephone. Additionally, the direction attribute for the Mediation Server for the interaction with CCM is sendonly. Additionally, the direction attribute for the phone is recvonly. In this case, CCM does not send any RTP packets or RTCP packets while the telephone is muted. Therefore, the call is dropped after 30 seconds.
•An Office Communicator user calls a CCM user who is configured to use Cisco Unity voice mail. When the call is connected to Cisco Unity, the call obtains the original media packets from Cisco Unity. Then, the Office Communicator user is prompted to leave a voice mail. However, Cisco Unity does not send any RTP packets or RTCP packets when the Office Communicator user leaves a voice mail. Therefore, a media time-out occurs after 30 seconds. Then, the call is disconnected, and the Office Communicator user cannot leave a voice mail.
To solve this issue you will need to download and install the April updates for the mediation server. After you have installed the update the mediation server it set to ignore media timeouts from the gateway.
Comments welcomed.
VoIPNorm
New OCS 2007 R2 Cisco UBE Interop Document
This week I am taking some time out from my schedule to catch up and do a bit of training. I am also taking a look at the new Cisco 8.x SRND as well as the new Cisco interoperability document on using the CUBE with OCS 2007 R2.
Cisco Unified Border Element and OCS 2007 R2 Interoperability Document
Get the document here.
There are some really good things about this documents that are well worth checking out but there also a few items to be aware of such as support from Microsoft for the IOS version and some of the CUCM setup used. The current Microsoft supported IOS version can be found here. If you are currently using the CUBE to do interoperability between OCS and CUCUM this offers some new commands in the IOS code (15.1.1T) that will help overcome some previously encountered issues . In saying that direct SIP to CUCM 7.1 is also supported by Microsoft so using the CUBE is not a requirement for interoperability.
First stop is a comment on page 5. “Some Microsoft Client endpoints require RTCP packets. If RTCP packets are not generated by all endpoints, additional features of the Cisco Unified Border Element can be used to resolve this issue. Contact your Cisco sales engineer for information.” If you read down the page, 5 bullet points down you get a better understanding about what they are talking about. Basically if you stop sending RTCP packets to Communicator or the conferencing service, they will hang up after 30 seconds under certain circumstances which are explained in the document. This behaviour has been seen with Cisco IP phones and Unity when they stop sending RTCP. Cisco have a work around for Unity with ISR's acting as MGCP gateways as well, so its an issue they have had to deal within their own ecosystem and not just with OCS.
There is one more point worthy of a mention in this first part of the document. The last bullet in this section talks about early media negotiation and ringback not working. It does not require a CUBE to solve this issue but having the IOS command suggested as a fix does simplify things if you have a CUBE deployed. This issue can be solved using a MSPL script on the front ends of your OCS deployment. Doug Lawty wrote a great blog post on this sometime ago if you’re experiencing this issue. For the CUBE, Cisco are recommending using the command “voice-class sip block 183 sdp present” on dial peers. This only allows 180 SIP ringing messages towards CUCM.
After skipping through the OCS configuration (beaware the screenshots showing the dialplan is not using Microsoft recommended E.164 best practices) on page 46 you get to the IOS configuration which is pretty helpful. If you are using an earlier version of Cisco UCM prior to 7.1 you may have to experiment a little with some of these commands to see if they work as expected.
The last half of the document is screen shots from CUCM configuration. Looking over the SIP trunk portion, one point to be aware of is this document does not show MTP as required selected. Now, for the SIP endpoints registered with CUCM this is not going to be an issue but for first generation Cisco SCCP IP phones this could cause a problem. 7940’s and 7960’s to be clear. Just something to keep in mind when you follow this document if you run into issues. With that you may also need to do some MTP planning which can be also run on the CUBE which is in flow though mode. The media is going to run through the CUBE regardless if the MTP is hosted there or not.
The last couple of areas worth mentioning is Appendix A which talks about earlier versions OF CUCM and removing the + sign and transcoding G.711 to G.729. Appendix A is handy if you plan to do it this way rather than remove the + at the mediation server itself. So again you do not need to use the CUBE to fix this issue. Then finally the transcoding section is handy if you implemented G.729 in areas of your Cisco network.
So overall this looks and feels like a lot of preceding documents Cisco have done on OCS integration. Something’s have provided a handy fix and other parts of the document are there for the sake of showing how it’s done with a sceenshot. Don't expect an in-depth analysis and I think you will be okay. Of course the main part of the document is the IOS configuration so its worth a look if for nothing else than that.
Comments welcomed.
VoIPNorm
Cisco Unified Border Element and OCS 2007 R2 Interoperability Document
Get the document here.
There are some really good things about this documents that are well worth checking out but there also a few items to be aware of such as support from Microsoft for the IOS version and some of the CUCM setup used. The current Microsoft supported IOS version can be found here. If you are currently using the CUBE to do interoperability between OCS and CUCUM this offers some new commands in the IOS code (15.1.1T) that will help overcome some previously encountered issues . In saying that direct SIP to CUCM 7.1 is also supported by Microsoft so using the CUBE is not a requirement for interoperability.
First stop is a comment on page 5. “Some Microsoft Client endpoints require RTCP packets. If RTCP packets are not generated by all endpoints, additional features of the Cisco Unified Border Element can be used to resolve this issue. Contact your Cisco sales engineer for information.” If you read down the page, 5 bullet points down you get a better understanding about what they are talking about. Basically if you stop sending RTCP packets to Communicator or the conferencing service, they will hang up after 30 seconds under certain circumstances which are explained in the document. This behaviour has been seen with Cisco IP phones and Unity when they stop sending RTCP. Cisco have a work around for Unity with ISR's acting as MGCP gateways as well, so its an issue they have had to deal within their own ecosystem and not just with OCS.
There is one more point worthy of a mention in this first part of the document. The last bullet in this section talks about early media negotiation and ringback not working. It does not require a CUBE to solve this issue but having the IOS command suggested as a fix does simplify things if you have a CUBE deployed. This issue can be solved using a MSPL script on the front ends of your OCS deployment. Doug Lawty wrote a great blog post on this sometime ago if you’re experiencing this issue. For the CUBE, Cisco are recommending using the command “voice-class sip block 183 sdp present” on dial peers. This only allows 180 SIP ringing messages towards CUCM.
After skipping through the OCS configuration (beaware the screenshots showing the dialplan is not using Microsoft recommended E.164 best practices) on page 46 you get to the IOS configuration which is pretty helpful. If you are using an earlier version of Cisco UCM prior to 7.1 you may have to experiment a little with some of these commands to see if they work as expected.
The last half of the document is screen shots from CUCM configuration. Looking over the SIP trunk portion, one point to be aware of is this document does not show MTP as required selected. Now, for the SIP endpoints registered with CUCM this is not going to be an issue but for first generation Cisco SCCP IP phones this could cause a problem. 7940’s and 7960’s to be clear. Just something to keep in mind when you follow this document if you run into issues. With that you may also need to do some MTP planning which can be also run on the CUBE which is in flow though mode. The media is going to run through the CUBE regardless if the MTP is hosted there or not.
The last couple of areas worth mentioning is Appendix A which talks about earlier versions OF CUCM and removing the + sign and transcoding G.711 to G.729. Appendix A is handy if you plan to do it this way rather than remove the + at the mediation server itself. So again you do not need to use the CUBE to fix this issue. Then finally the transcoding section is handy if you implemented G.729 in areas of your Cisco network.
So overall this looks and feels like a lot of preceding documents Cisco have done on OCS integration. Something’s have provided a handy fix and other parts of the document are there for the sake of showing how it’s done with a sceenshot. Don't expect an in-depth analysis and I think you will be okay. Of course the main part of the document is the IOS configuration so its worth a look if for nothing else than that.
Comments welcomed.
VoIPNorm
OCS User Training and Adoption materials
This is always on the top of the list when talking to customers who are planning on using UC. Below are a couple of resources that companies can use to help with that area. In particular I really like the rolodex. It has material for all the different features in OC and other UC clients including the console attendant and group chat .It can be setup in your own environment customized to the features and clients you have deployed.
Adoption & Training Kit: http://www.microsoft.com/communicationsserver/r2-adoption-and-training-kit/default.html
The Microsoft Unified Communications 2007 R2 Adoption and Training Kit provides resources and guidance for IT Professionals, Helpdesk and Support Professionals, and Trainers to support end-users who use Microsoft Unified Communications Technologies. Content includes:
•IT Pro - Planning Checklist, Benefit Statements, E-Mail Campaign Samples, Success Metrics Examples, and User Education Materials
•Helpdesk - Planning Checklist, Frequently Asked Questions, and Troubleshooting Guides.
•Trainer - Planning Checklist, Quick Reference Cards, Tips and Tricks Flash Cards. How-to's, Getting Started Tours, and Web-based Tutorials and Training
Silverlight Rolodex: http://stage.xcarab.com/microsoft/rolodex/
To download the rolodex to setup in your own environment:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=aba240af-b5ba-4e14-bc12-c98eae1f6d15
Adoption & Training Kit: http://www.microsoft.com/communicationsserver/r2-adoption-and-training-kit/default.html
The Microsoft Unified Communications 2007 R2 Adoption and Training Kit provides resources and guidance for IT Professionals, Helpdesk and Support Professionals, and Trainers to support end-users who use Microsoft Unified Communications Technologies. Content includes:
•IT Pro - Planning Checklist, Benefit Statements, E-Mail Campaign Samples, Success Metrics Examples, and User Education Materials
•Helpdesk - Planning Checklist, Frequently Asked Questions, and Troubleshooting Guides.
•Trainer - Planning Checklist, Quick Reference Cards, Tips and Tricks Flash Cards. How-to's, Getting Started Tours, and Web-based Tutorials and Training
Silverlight Rolodex: http://stage.xcarab.com/microsoft/rolodex/
To download the rolodex to setup in your own environment:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=aba240af-b5ba-4e14-bc12-c98eae1f6d15
Subscribe to:
Posts (Atom)