[cisco-voip] CUCM 9+ and SIP trunk provider w/o CUBE

Brian Meade bmeade90 at vt.edu
Wed Aug 13 13:27:10 EDT 2014


I agree with you that LUA scripting is much more powerful but I use it as a
last resort just do to supportability.  Just because I know how to do
something fancy in a LUA script doesn't mean the next guy is going to be
able to maintain/troubleshoot my script whereas sip-profiles on the CUBE
are much simpler and have full TAC support in case anything goes wrong.


On Wed, Aug 13, 2014 at 12:27 PM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> Not to stir the pot, but it's currently my opinion that SIP normalization
> on CUCM via Lua scripting is more powerful than SIP profiles in IOS.
>  That's not to say that I recommend a sans CUBE design, because I don't,
> but I am saying that CUBE is not a preferred solution because of its SIP
> normalization capabilities.  Which are pretty basic, when compared to the
> full control, offered by Lua scripting in CUCM.
>
> Does anyone think otherwise?  I'm open to being corrected here.  Maybe
> it's my misunderstanding of SIP normalization in IOS that makes me think
> this way.  I do have real world experience solving SIP issues with both IOS
> and CUCM, albeit a small amount of experience.
>
> And on the main topic, yes it would work with CUBE, but CUBE provides you
> with an extra layer of control, security, and simplifies your design.  If
> you're having CUCM insert MTPs anyway (think CTI and RFC2833
> incompatibilities and DO to EO conversions) might as well use that same MTP
> router as CUBE and have CUBE locally control the media resources
> <http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/115018-configure-cube-lti.html>
> on itself.
>
>
> On Wed, Aug 13, 2014 at 8:59 AM, Ryan Ratliff (rratliff) <
> rratliff at cisco.com> wrote:
>
>>  +1
>>
>>  The IOS features to manipulate SIP headers are very powerful and will
>> let you workaround any interworking problems between the SBC and UCM quite
>> easily.
>>
>> -Ryan
>>
>>  On Aug 12, 2014, at 10:29 PM, Brian Meade <bmeade90 at vt.edu> wrote:
>>
>>  Robert,
>>
>>  You can technically get away with just using the provider's SBC but be
>> prepared for a lot of going back and forth with them to solve any interop
>> issues.  I like having my own SBC/CUBE so that I can modify whatever I want
>> and have more control over the setup.
>>
>>  It's also nice to be able to completely hide your internal network
>> behind the CUBE.
>>
>>  Brian
>>
>>
>> On Tue, Aug 12, 2014 at 7:41 PM, Robert Blayzor <rblayzor.bulk at inoc.net>
>> wrote:
>>
>>> I am planning on replacing an again CallManager deployment with SCCP
>>> phones with a new CUCM 10.x and SIP phones.
>>>
>>> Our service provider can provide all of our trunking and PSTN
>>> connectivity via a direct SIP trunk, so I no longer need a PSTN gateway or
>>> PRI card, etc.  (or at least I should not).
>>>
>>> We will be peering SIP from the CUCM to our providers SBC, so the
>>> question begs to ask on our side is a CUBE absolutely required to make this
>>> work?  Pros/Cons?  I'd rather not have to add a CUBE in if I don't have to.
>>>
>>> Since the phones are native SIP as is the CallManager I'm trying to
>>> understand why a CUBE is required? (or is it not?)
>>>
>>> TIA
>>>
>>> -Robert
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
>>  _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140813/38d5e5ac/attachment.html>


More information about the cisco-voip mailing list