[cisco-voip] Cisco and Lync/Skype with Media Bypass

[Mark Holloway]

Thanks Matt and Mike. I installed the Lync/Skype planning tool which provided the number of mediation servers required with (24) and without (4) media bypass enabled. I was surprised the capacity planning spreadsheet didn’t have the mediation server

Regarding MTP’s, the plan is to put an Acme Packet 4600 SBC between Cisco and Skype. The SBC supports restricted-latching in the realm facing SfB to support Skype’s media bypass. The 4600 will support up to 15,000 concurrent transcoded calls and the network requires 12,000. Typically the SBC replaces the need for MTP by normalizing SIP signaling and converting CUCM delayed offer to Early offer “in between” CUCM and Lync/Skype (or a SIP Trunk provider). The cost of the 4600 with transcoding is much lower in cost compared to buying sixteen 4451-X routers with PVDM-3000.   


> On Oct 13, 2016, at 9:20 AM, Matt Slaga (AM) <matt.slaga at dimensiondata.com> wrote:
> 
> Media Bypass in SfB maximums are not posted, they only post the Mediation server transcoding maximums, which are between 1100 and 1500 for each dedicated mediation server and 150 for co-located mediation server.
> https://technet.microsoft.com/en-us/library/gg615015.aspx <https://technet.microsoft.com/en-us/library/gg615015.aspx>
>  
> In my opinion, the bigger limitation however is on the CUCM side.  SfB endpoints will bypass the mediation server, however every call will terminate to either CUCM MTP or an MTP within an IOS gateway (if configured in MRG/MRGLs).  Today, it is not possible to connect a SfB endpoint directly to a Cisco endpoint without a Cisco MTP in the middle.  This is extremely important when designing your integration, especially if you have a large deployment.
>  
>  
>   <>
> From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Norton, Mike
> Sent: Wednesday, October 12, 2016 6:50 PM
> To: Mark Holloway <mh at markholloway.com>; voip puck <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] Cisco and Lync/Skype with Media Bypass
>  
> 
> 
> Are you using the official Planning Tool that you download and install from Microsoft? One of the questions it asks about each site is what percentage of calls will use media bypass. When you get to the end it should take your media bypass use into consideration in its recommendations.
> 
> -mn
> 
> 
> -----Original Message-----
> From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net <mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Mark Holloway
> Sent: October-12-16 2:39 PM
> To: voip puck <cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>>
> Subject: [cisco-voip] Cisco and Lync/Skype with Media Bypass
> 
> This is more of a Microsoft question but I’ve searched everywhere and cannot find an answer. I’m currently working on a design to integrate CUCM and Skype for Biz. The Skype client will have media bypass enabled. All the Lync/Skype capacity calculators and TechNet articles talk about how many calls a Mediation server can handle when media is anchored. With media bypass only SIP signaling will pass through the Mediation server. There are no published numbers on how many concurrent SIP signaling only calls a mediation server can handle. Everything just reference “many more calls” but no ball park numbers. If anyone has info that would be great.
> 
> Thanks,
> Mark
> 
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
> https://protect-eu.mimecast.com/s/37w0BIoOpX0Hw <https://puck.nether.net/mailman/listinfo/cisco-voip>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
> https://protect-eu.mimecast.com/s/37w0BIoOpX0Hw <https://puck.nether.net/mailman/listinfo/cisco-voip>
> 
> 
> 
> itevomcid

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20161014/94e59e5d/attachment.html>