[cisco-voip] quick question about sip and CUBE

[Nick Matthews]

I've seen this configuration before - sometimes certain call flows require
MTP for devices/integrations on the CUCM side.  You don't have to set up
multiple listening ports on CUBE, as it's indifferent. On CUCM the two
trunks have different source ports. If it's outbound from CUCM only that
matters, no CUBE changes are required. If you need inbound calls to have
MTP only for certain calls changing the port is the best way.

I believe with SIP trunks CUCM will not allow two trunks to the same
address with the same source port, but it will allow you with H.323
gateways. However, the choice of which of those gateways is basically
random and you may think there are two but it's only using one, but that's
a H.323 caveat.

-nick


On Thu, Apr 4, 2013 at 1:02 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>wrote:

> Doh.  I forgot about changing the port.
>
> I think that answers my question.  I can have one trunk on 5060 for  site
> to site calls w/ MTP and one trunk to 5061 for least cost routing from/to
> other sites.
>
> This seems like it will suit our needs perfectly.
>
>
>
> On Thu, Apr 4, 2013 at 11:09 AM, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
>> What's your ultimate goal that you want/need two trunks to a single CUBE?
>>
>> So in CUBE you would do something like this:
>>
>> dial-peer voice 1 voip
>>  description Trunk 1
>>  session protocol sipv2
>>  destination-pattern 1...$
>>  session-target ipv4:10.1.1.1:5061
>> !
>> dial-peer voice 2 voip
>>  description Trunk 2
>>  session protocol sipv2
>>  destination-pattern 2...$
>>  session-target ipv4:10.1.1.1:5062
>> !
>>
>> And then in CUCM you would need to create two new SIP Trunk Security
>> Profiles (Found under System > Security in 8.6), specifying the port in
>> which CUCM should expect to receive the messages.  Create your two trunks
>> pointing to the CUBE, using respective SIP Trunk security profiles, and
>> that's how you force an inbound trunk.
>>
>> As for the MTP question: You can require MTP for all calls, which can be
>> good and bad.  That's no different from H323 trunks to gateways.  The
>> require only when needed comes in to play for SIP Early Offer only.  And
>> that's a matter of the calling device and whether or not CUCM receives its
>> capabilities or has to make something up using an MTP's capbilities.  DTMF
>> relay mismatch (Out of band versus In band) is a different story, and
>> there's no check box for that.  That's simply a function of the Media
>> Manager and the MRGL on the SIP trunk, which will correct DTMF mismatches
>> automatically by dynamically using an MTP as needed.  So, three different
>> things going on there.
>>
>> I hope that helped explain it a bit more.  Maybe someone else will fill
>> in some of my gaps.
>>
>>
>> On Thu, Apr 4, 2013 at 10:22 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>wrote:
>>
>>>
>>> If I have two sip trunks from CUCM to CUBE (one which requires MTP and
>>> one which does not) how does the CUBE or CUCM know which trunk settings to
>>> use for inbound calls to CUCM?
>>>
>>> Is it best to make all of the inbound settings the same and do all of
>>> the translations on the CUBE or CUCM translation patterns instead of
>>> setting the significant digits?
>>>
>>> I'm also remembering someone telling me a while back that if you uncheck
>>> the MTP Required that th etrunk will still allocate MTP if needed.  Is that
>>> correct?  It would allow me to only use the one trunk with translations.
>>>
>>> As always, thanks for the help!
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20130409/2697b420/attachment.html>