[cisco-voip] quick question about sip and CUBE

Tue Apr 9 12:00:36 EDT 2013

Should but how are you translating inbound? 4 as well?

Sent from my iPhone

On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip at gmail.com> wrote:

We expect + followed by 11 digits, which we receive.  We rely on the
inbound trunk settings to strip it to 4 digits.  Would traces show if it is
being stripped to 4 digits?

RTMT isn't giving any clues either.

On Tue, Apr 9, 2013 at 10:52 AM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:

> Have you ran RTMT? Also on the trunk have you checked what you are
> expecting inbound?
>
> Sent from my iPhone
>
> On Apr 9, 2013, at 11:49 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>
> wrote:
>
> There is no carrier involved.
>
> The call is UK CUCM -> UK CUBE -> Global Network -> US CUBE -> US CUCM
>
> All of the branches are part of the whole but operate independently which
> is why it is set up like this.
>
> The US CUCM is sending the 503 to the UK caller.  The only thing I can
> think of is that for some reason the trunk isn't acknowledging the set
> significant digits.
>
>
> On Tue, Apr 9, 2013 at 10:26 AM, Kenneth Hayes <kennethwhayes at gmail.com>wrote:
>
>> 503 is a carrier issue with the service.
>>
>> Sent from my iPhone
>>
>> On Apr 9, 2013, at 11:05 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>
>> wrote:
>>
>> We got that working but I think we have another issue that I'm not sure
>> how to verify.
>>
>> I didn't change any of the dial-peers pointing to the CUCM yet, I have
>> only modified the one trunk to use port 5070 so it will not interfere with
>> the current trunk for inbound.
>>
>> Now we get a 503 service unavailable for calls from the remote system.
>> Will I need to change my existing dial-peers to xxx.xxx.xxx.xxx:5060 before
>> I add any dial-peers for use on the new trunk that uses 5070?  All inbound
>> worked fine until I added this second trunk.
>>
>>
>> On Tue, Apr 9, 2013 at 9:28 AM, Nick Matthews <matthnick at gmail.com>wrote:
>>
>>> 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
>>>>
>>>>
>>>
>> _______________________________________________
>> 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/6c1355f3/attachment.html>