Mailing List Archive

quick question about sip and CUBE
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!
Re: quick question about sip and CUBE [ In reply to ]
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@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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: quick question about sip and CUBE [ In reply to ]
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@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@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@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
Re: quick question about sip and CUBE [ In reply to ]
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@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@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@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@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: quick question about sip and CUBE [ In reply to ]
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@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@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@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@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@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
Re: quick question about sip and CUBE [ In reply to ]
503 is a carrier issue with the service.

Sent from my iPhone

On Apr 9, 2013, at 11:05 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: quick question about sip and CUBE [ In reply to ]
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@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@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@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@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@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@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@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: quick question about sip and CUBE [ In reply to ]
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@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@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@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@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@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@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@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@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: quick question about sip and CUBE [ In reply to ]
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@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@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@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@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@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@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@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@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@puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
Re: quick question about sip and CUBE [ In reply to ]
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@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@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@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@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@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@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@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@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@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@puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
Re: quick question about sip and CUBE [ In reply to ]
Is there a Warning header in the 503? CUCM sends a 503 with the following header in it when it cannot match the IP/port of the incoming SIP message to a SIP Trunk.

Warning: 399 <CUCM-Server> "Unable to find a device handler for the
request received on port <port> from <far-end-ip>"

HTH,
-Tom

On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: quick question about sip and CUBE [ In reply to ]
We aren't translating called numbers. Our current configuration worked
until last week. Only thing I did was change an outbound dial peer'
destination pattern from an exact match of the UK tech's cell phone to
match all UK numbers

Our second trunk that only handles outbound UK calls to their PSTN is the
only thing I added on CUCM.

I have a TAC caseopen now as well.


On Tue, Apr 9, 2013 at 11:00 AM, Kenneth Hayes <kennethwhayes@gmail.com>wrote:

> 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@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@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@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@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@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@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@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@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@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@puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip@puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
Re: quick question about sip and CUBE [ In reply to ]
Yes, that warning message is present.

Here is the sanitized message:


04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP
message to 10.252.xxx.xxx on port 46625 index 1864

SIP/2.0 503 Service Unavailable

Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33

From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528

To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627

Date: Tue, 09 Apr 2013 08:16:28 GMT

Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX

CSeq: 101 INVITE

Allow-Events: presence

Warning: 399 ccmsub "Unable to find a device handler for the request
received on port 5060 from 10.252.XXX.XXX"

Content-Length: 0



My trunk points to the correct address and uses port 5060 in both
directions.


On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <
tpiscite@cisco.com> wrote:

> Is there a Warning header in the 503? CUCM sends a 503 with the following
> header in it when it cannot match the IP/port of the incoming SIP message
> to a SIP Trunk.
>
> Warning: 399 <CUCM-Server> "Unable to find a device handler for the
> request received on port <port> from <far-end-ip>"
>
> HTH,
> -Tom
>
> On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cisco-voip mailing list
> >>> cisco-voip@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cisco-voip mailing list
> >>> cisco-voip@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: quick question about sip and CUBE [ In reply to ]
Sorry, I forgot an important piece of the puzzle. CUCM will only accept SIP messages for a given SIP Trunk on CUCM nodes that are in the CM Group of the SIP Trunk's Device Pool. For example:

Here are your 3 CUCM nodes in the cluster:
publisher
subscriber-a
subscriber-b

and you create a SIP Trunk, call it "To_UK_CUBE" and put it in a Device Pool with the following CM Group:

subscriber-a
subscriber-b

CUCM will reply with a 503 if you send a SIP INVITE to the publisher from the UK CUBE.

HTH,
-Tom

On Apr 9, 2013, at 1:11 PM, Erick Wellnitz <ewellnitzvoip@gmail.com> wrote:

> Yes, that warning message is present.
>
> Here is the sanitized message:
>
> 04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.252.xxx.xxx on port 46625 index 1864
>
> SIP/2.0 503 Service Unavailable
>
> Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33
>
> From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528
>
> To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627
>
> Date: Tue, 09 Apr 2013 08:16:28 GMT
>
> Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX
>
> CSeq: 101 INVITE
>
> Allow-Events: presence
>
> Warning: 399 ccmsub "Unable to find a device handler for the request received on port 5060 from 10.252.XXX.XXX"
>
> Content-Length: 0
>
>
> My trunk points to the correct address and uses port 5060 in both directions.
>
>
>
> On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <tpiscite@cisco.com> wrote:
> Is there a Warning header in the 503? CUCM sends a 503 with the following header in it when it cannot match the IP/port of the incoming SIP message to a SIP Trunk.
>
> Warning: 399 <CUCM-Server> "Unable to find a device handler for the
> request received on port <port> from <far-end-ip>"
>
> HTH,
> -Tom
>
> On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cisco-voip mailing list
> >>> cisco-voip@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cisco-voip mailing list
> >>> cisco-voip@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: quick question about sip and CUBE [ In reply to ]
That makes sense and jives with what I had been reading. I switched the
priority of the dial peers to match the CM Group. I believe that would
resolve the issue, correct?


On Tue, Apr 9, 2013 at 2:36 PM, Tom Piscitell (tpiscite) <tpiscite@cisco.com
> wrote:

> Sorry, I forgot an important piece of the puzzle. CUCM will only accept
> SIP messages for a given SIP Trunk on CUCM nodes that are in the CM Group
> of the SIP Trunk's Device Pool. For example:
>
> Here are your 3 CUCM nodes in the cluster:
> publisher
> subscriber-a
> subscriber-b
>
> and you create a SIP Trunk, call it "To_UK_CUBE" and put it in a Device
> Pool with the following CM Group:
>
> subscriber-a
> subscriber-b
>
> CUCM will reply with a 503 if you send a SIP INVITE to the publisher from
> the UK CUBE.
>
> HTH,
> -Tom
>
> On Apr 9, 2013, at 1:11 PM, Erick Wellnitz <ewellnitzvoip@gmail.com>
> wrote:
>
> > Yes, that warning message is present.
> >
> > Here is the sanitized message:
> >
> > 04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP
> TCP message to 10.252.xxx.xxx on port 46625 index 1864
> >
> > SIP/2.0 503 Service Unavailable
> >
> > Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33
> >
> > From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528
> >
> > To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627
> >
> > Date: Tue, 09 Apr 2013 08:16:28 GMT
> >
> > Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX
> >
> > CSeq: 101 INVITE
> >
> > Allow-Events: presence
> >
> > Warning: 399 ccmsub "Unable to find a device handler for the request
> received on port 5060 from 10.252.XXX.XXX"
> >
> > Content-Length: 0
> >
> >
> > My trunk points to the correct address and uses port 5060 in both
> directions.
> >
> >
> >
> > On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <
> tpiscite@cisco.com> wrote:
> > Is there a Warning header in the 503? CUCM sends a 503 with the
> following header in it when it cannot match the IP/port of the incoming SIP
> message to a SIP Trunk.
> >
> > Warning: 399 <CUCM-Server> "Unable to find a device handler for the
> > request received on port <port> from <far-end-ip>"
> >
> > HTH,
> > -Tom
> >
> > On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> cisco-voip mailing list
> > >>> cisco-voip@puck.nether.net
> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> cisco-voip mailing list
> > >>> cisco-voip@puck.nether.net
> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> > >>
> > >
> > > _______________________________________________
> > > cisco-voip mailing list
> > > cisco-voip@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
>
>
Re: quick question about sip and CUBE [ In reply to ]
Here is what fixed the problem:

CM Group contains:
Sub
Pub

Dial Peers had preference:
Pub
Sub

I switched the dial peer preference to:
Sub
Pub

Now all calls work as expected. I have seen this before but I seem to
forget this trunk behavior in troubleshooting.

Thanks for all of the advice!


On Tue, Apr 9, 2013 at 2:36 PM, Tom Piscitell (tpiscite) <tpiscite@cisco.com
> wrote:

> Sorry, I forgot an important piece of the puzzle. CUCM will only accept
> SIP messages for a given SIP Trunk on CUCM nodes that are in the CM Group
> of the SIP Trunk's Device Pool. For example:
>
> Here are your 3 CUCM nodes in the cluster:
> publisher
> subscriber-a
> subscriber-b
>
> and you create a SIP Trunk, call it "To_UK_CUBE" and put it in a Device
> Pool with the following CM Group:
>
> subscriber-a
> subscriber-b
>
> CUCM will reply with a 503 if you send a SIP INVITE to the publisher from
> the UK CUBE.
>
> HTH,
> -Tom
>
> On Apr 9, 2013, at 1:11 PM, Erick Wellnitz <ewellnitzvoip@gmail.com>
> wrote:
>
> > Yes, that warning message is present.
> >
> > Here is the sanitized message:
> >
> > 04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP
> TCP message to 10.252.xxx.xxx on port 46625 index 1864
> >
> > SIP/2.0 503 Service Unavailable
> >
> > Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33
> >
> > From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528
> >
> > To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627
> >
> > Date: Tue, 09 Apr 2013 08:16:28 GMT
> >
> > Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX
> >
> > CSeq: 101 INVITE
> >
> > Allow-Events: presence
> >
> > Warning: 399 ccmsub "Unable to find a device handler for the request
> received on port 5060 from 10.252.XXX.XXX"
> >
> > Content-Length: 0
> >
> >
> > My trunk points to the correct address and uses port 5060 in both
> directions.
> >
> >
> >
> > On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <
> tpiscite@cisco.com> wrote:
> > Is there a Warning header in the 503? CUCM sends a 503 with the
> following header in it when it cannot match the IP/port of the incoming SIP
> message to a SIP Trunk.
> >
> > Warning: 399 <CUCM-Server> "Unable to find a device handler for the
> > request received on port <port> from <far-end-ip>"
> >
> > HTH,
> > -Tom
> >
> > On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> cisco-voip mailing list
> > >>> cisco-voip@puck.nether.net
> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> cisco-voip mailing list
> > >>> cisco-voip@puck.nether.net
> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> > >>
> > >
> > > _______________________________________________
> > > cisco-voip mailing list
> > > cisco-voip@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
>
>
Re: quick question about sip and CUBE [ In reply to ]
In 8.x and later trunks have an option to run on all nodes (like RLs). This would likely have saved you some pain.

-Ryan

On Apr 10, 2013, at 10:38 AM, Erick Wellnitz <ewellnitzvoip@gmail.com> wrote:

Here is what fixed the problem:

CM Group contains:
Sub
Pub

Dial Peers had preference:
Pub
Sub

I switched the dial peer preference to:
Sub
Pub

Now all calls work as expected. I have seen this before but I seem to forget this trunk behavior in troubleshooting.

Thanks for all of the advice!


On Tue, Apr 9, 2013 at 2:36 PM, Tom Piscitell (tpiscite) <tpiscite@cisco.com> wrote:
Sorry, I forgot an important piece of the puzzle. CUCM will only accept SIP messages for a given SIP Trunk on CUCM nodes that are in the CM Group of the SIP Trunk's Device Pool. For example:

Here are your 3 CUCM nodes in the cluster:
publisher
subscriber-a
subscriber-b

and you create a SIP Trunk, call it "To_UK_CUBE" and put it in a Device Pool with the following CM Group:

subscriber-a
subscriber-b

CUCM will reply with a 503 if you send a SIP INVITE to the publisher from the UK CUBE.

HTH,
-Tom

On Apr 9, 2013, at 1:11 PM, Erick Wellnitz <ewellnitzvoip@gmail.com> wrote:

> Yes, that warning message is present.
>
> Here is the sanitized message:
>
> 04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.252.xxx.xxx on port 46625 index 1864
>
> SIP/2.0 503 Service Unavailable
>
> Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33
>
> From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528
>
> To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627
>
> Date: Tue, 09 Apr 2013 08:16:28 GMT
>
> Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX
>
> CSeq: 101 INVITE
>
> Allow-Events: presence
>
> Warning: 399 ccmsub "Unable to find a device handler for the request received on port 5060 from 10.252.XXX.XXX"
>
> Content-Length: 0
>
>
> My trunk points to the correct address and uses port 5060 in both directions.
>
>
>
> On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <tpiscite@cisco.com> wrote:
> Is there a Warning header in the 503? CUCM sends a 503 with the following header in it when it cannot match the IP/port of the incoming SIP message to a SIP Trunk.
>
> Warning: 399 <CUCM-Server> "Unable to find a device handler for the
> request received on port <port> from <far-end-ip>"
>
> HTH,
> -Tom
>
> On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cisco-voip mailing list
> >>> cisco-voip@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cisco-voip mailing list
> >>> cisco-voip@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: quick question about sip and CUBE [ In reply to ]
I guess the next question would be: Why did it work before with the dial
peer with preference 1 pointing at the publisher which is the secondary in
the CM Group and why did it suddenly stop working?


On Wed, Apr 10, 2013 at 10:02 AM, Ryan Ratliff <rratliff@cisco.com> wrote:

> In 8.x and later trunks have an option to run on all nodes (like RLs).
> This would likely have saved you some pain.
>
> -Ryan
>
> On Apr 10, 2013, at 10:38 AM, Erick Wellnitz <ewellnitzvoip@gmail.com>
> wrote:
>
> Here is what fixed the problem:
>
> CM Group contains:
> Sub
> Pub
>
> Dial Peers had preference:
> Pub
> Sub
>
> I switched the dial peer preference to:
> Sub
> Pub
>
> Now all calls work as expected. I have seen this before but I seem to
> forget this trunk behavior in troubleshooting.
>
> Thanks for all of the advice!
>
>
> On Tue, Apr 9, 2013 at 2:36 PM, Tom Piscitell (tpiscite) <
> tpiscite@cisco.com> wrote:
>
>> Sorry, I forgot an important piece of the puzzle. CUCM will only accept
>> SIP messages for a given SIP Trunk on CUCM nodes that are in the CM Group
>> of the SIP Trunk's Device Pool. For example:
>>
>> Here are your 3 CUCM nodes in the cluster:
>> publisher
>> subscriber-a
>> subscriber-b
>>
>> and you create a SIP Trunk, call it "To_UK_CUBE" and put it in a Device
>> Pool with the following CM Group:
>>
>> subscriber-a
>> subscriber-b
>>
>> CUCM will reply with a 503 if you send a SIP INVITE to the publisher from
>> the UK CUBE.
>>
>> HTH,
>> -Tom
>>
>> On Apr 9, 2013, at 1:11 PM, Erick Wellnitz <ewellnitzvoip@gmail.com>
>> wrote:
>>
>> > Yes, that warning message is present.
>> >
>> > Here is the sanitized message:
>> >
>> > 04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP
>> TCP message to 10.252.xxx.xxx on port 46625 index 1864
>> >
>> > SIP/2.0 503 Service Unavailable
>> >
>> > Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33
>> >
>> > From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528
>> >
>> > To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627
>> >
>> > Date: Tue, 09 Apr 2013 08:16:28 GMT
>> >
>> > Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX
>> >
>> > CSeq: 101 INVITE
>> >
>> > Allow-Events: presence
>> >
>> > Warning: 399 ccmsub "Unable to find a device handler for the request
>> received on port 5060 from 10.252.XXX.XXX"
>> >
>> > Content-Length: 0
>> >
>> >
>> > My trunk points to the correct address and uses port 5060 in both
>> directions.
>> >
>> >
>> >
>> > On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <
>> tpiscite@cisco.com> wrote:
>> > Is there a Warning header in the 503? CUCM sends a 503 with the
>> following header in it when it cannot match the IP/port of the incoming SIP
>> message to a SIP Trunk.
>> >
>> > Warning: 399 <CUCM-Server> "Unable to find a device handler for the
>> > request received on port <port> from <far-end-ip>"
>> >
>> > HTH,
>> > -Tom
>> >
>> > On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> cisco-voip mailing list
>> > >>> cisco-voip@puck.nether.net
>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> > >>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> cisco-voip mailing list
>> > >>> cisco-voip@puck.nether.net
>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> > >>
>> > >
>> > > _______________________________________________
>> > > cisco-voip mailing list
>> > > cisco-voip@puck.nether.net
>> > > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>> >
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
Re: quick question about sip and CUBE [ In reply to ]
If devices are registered to the sub and the call failed routing to the pub I'd guess the pub lost its SDL connection to the sub, or for some reason isn't aware of the devices registered to the sub.

-Ryan

On Apr 10, 2013, at 11:28 AM, Erick Wellnitz <ewellnitzvoip@gmail.com> wrote:

I guess the next question would be: Why did it work before with the dial peer with preference 1 pointing at the publisher which is the secondary in the CM Group and why did it suddenly stop working?


On Wed, Apr 10, 2013 at 10:02 AM, Ryan Ratliff <rratliff@cisco.com> wrote:
In 8.x and later trunks have an option to run on all nodes (like RLs). This would likely have saved you some pain.

-Ryan

On Apr 10, 2013, at 10:38 AM, Erick Wellnitz <ewellnitzvoip@gmail.com> wrote:

Here is what fixed the problem:

CM Group contains:
Sub
Pub

Dial Peers had preference:
Pub
Sub

I switched the dial peer preference to:
Sub
Pub

Now all calls work as expected. I have seen this before but I seem to forget this trunk behavior in troubleshooting.

Thanks for all of the advice!


On Tue, Apr 9, 2013 at 2:36 PM, Tom Piscitell (tpiscite) <tpiscite@cisco.com> wrote:
Sorry, I forgot an important piece of the puzzle. CUCM will only accept SIP messages for a given SIP Trunk on CUCM nodes that are in the CM Group of the SIP Trunk's Device Pool. For example:

Here are your 3 CUCM nodes in the cluster:
publisher
subscriber-a
subscriber-b

and you create a SIP Trunk, call it "To_UK_CUBE" and put it in a Device Pool with the following CM Group:

subscriber-a
subscriber-b

CUCM will reply with a 503 if you send a SIP INVITE to the publisher from the UK CUBE.

HTH,
-Tom

On Apr 9, 2013, at 1:11 PM, Erick Wellnitz <ewellnitzvoip@gmail.com> wrote:

> Yes, that warning message is present.
>
> Here is the sanitized message:
>
> 04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 10.252.xxx.xxx on port 46625 index 1864
>
> SIP/2.0 503 Service Unavailable
>
> Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33
>
> From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528
>
> To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627
>
> Date: Tue, 09 Apr 2013 08:16:28 GMT
>
> Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX
>
> CSeq: 101 INVITE
>
> Allow-Events: presence
>
> Warning: 399 ccmsub "Unable to find a device handler for the request received on port 5060 from 10.252.XXX.XXX"
>
> Content-Length: 0
>
>
> My trunk points to the correct address and uses port 5060 in both directions.
>
>
>
> On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <tpiscite@cisco.com> wrote:
> Is there a Warning header in the 503? CUCM sends a 503 with the following header in it when it cannot match the IP/port of the incoming SIP message to a SIP Trunk.
>
> Warning: 399 <CUCM-Server> "Unable to find a device handler for the
> request received on port <port> from <far-end-ip>"
>
> HTH,
> -Tom
>
> On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cisco-voip mailing list
> >>> cisco-voip@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> cisco-voip mailing list
> >>> cisco-voip@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: quick question about sip and CUBE [ In reply to ]
I don't see any SDL alerts but now I have other devices that are registered
to the sub that can't call to devices on the Pub.


On Wed, Apr 10, 2013 at 10:57 AM, Ryan Ratliff <rratliff@cisco.com> wrote:

> If devices are registered to the sub and the call failed routing to the
> pub I'd guess the pub lost its SDL connection to the sub, or for some
> reason isn't aware of the devices registered to the sub.
>
> -Ryan
>
> On Apr 10, 2013, at 11:28 AM, Erick Wellnitz <ewellnitzvoip@gmail.com>
> wrote:
>
> I guess the next question would be: Why did it work before with the dial
> peer with preference 1 pointing at the publisher which is the secondary in
> the CM Group and why did it suddenly stop working?
>
>
> On Wed, Apr 10, 2013 at 10:02 AM, Ryan Ratliff <rratliff@cisco.com> wrote:
>
>> In 8.x and later trunks have an option to run on all nodes (like RLs).
>> This would likely have saved you some pain.
>>
>> -Ryan
>>
>> On Apr 10, 2013, at 10:38 AM, Erick Wellnitz <ewellnitzvoip@gmail.com>
>> wrote:
>>
>> Here is what fixed the problem:
>>
>> CM Group contains:
>> Sub
>> Pub
>>
>> Dial Peers had preference:
>> Pub
>> Sub
>>
>> I switched the dial peer preference to:
>> Sub
>> Pub
>>
>> Now all calls work as expected. I have seen this before but I seem to
>> forget this trunk behavior in troubleshooting.
>>
>> Thanks for all of the advice!
>>
>>
>> On Tue, Apr 9, 2013 at 2:36 PM, Tom Piscitell (tpiscite) <
>> tpiscite@cisco.com> wrote:
>>
>>> Sorry, I forgot an important piece of the puzzle. CUCM will only accept
>>> SIP messages for a given SIP Trunk on CUCM nodes that are in the CM Group
>>> of the SIP Trunk's Device Pool. For example:
>>>
>>> Here are your 3 CUCM nodes in the cluster:
>>> publisher
>>> subscriber-a
>>> subscriber-b
>>>
>>> and you create a SIP Trunk, call it "To_UK_CUBE" and put it in a Device
>>> Pool with the following CM Group:
>>>
>>> subscriber-a
>>> subscriber-b
>>>
>>> CUCM will reply with a 503 if you send a SIP INVITE to the publisher
>>> from the UK CUBE.
>>>
>>> HTH,
>>> -Tom
>>>
>>> On Apr 9, 2013, at 1:11 PM, Erick Wellnitz <ewellnitzvoip@gmail.com>
>>> wrote:
>>>
>>> > Yes, that warning message is present.
>>> >
>>> > Here is the sanitized message:
>>> >
>>> > 04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP
>>> TCP message to 10.252.xxx.xxx on port 46625 index 1864
>>> >
>>> > SIP/2.0 503 Service Unavailable
>>> >
>>> > Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33
>>> >
>>> > From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528
>>> >
>>> > To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627
>>> >
>>> > Date: Tue, 09 Apr 2013 08:16:28 GMT
>>> >
>>> > Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX
>>> >
>>> > CSeq: 101 INVITE
>>> >
>>> > Allow-Events: presence
>>> >
>>> > Warning: 399 ccmsub "Unable to find a device handler for the request
>>> received on port 5060 from 10.252.XXX.XXX"
>>> >
>>> > Content-Length: 0
>>> >
>>> >
>>> > My trunk points to the correct address and uses port 5060 in both
>>> directions.
>>> >
>>> >
>>> >
>>> > On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <
>>> tpiscite@cisco.com> wrote:
>>> > Is there a Warning header in the 503? CUCM sends a 503 with the
>>> following header in it when it cannot match the IP/port of the incoming SIP
>>> message to a SIP Trunk.
>>> >
>>> > Warning: 399 <CUCM-Server> "Unable to find a device handler for the
>>> > request received on port <port> from <far-end-ip>"
>>> >
>>> > HTH,
>>> > -Tom
>>> >
>>> > On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
>>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>> _______________________________________________
>>> > >>> cisco-voip mailing list
>>> > >>> cisco-voip@puck.nether.net
>>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>> _______________________________________________
>>> > >>> cisco-voip mailing list
>>> > >>> cisco-voip@puck.nether.net
>>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> > >>
>>> > >
>>> > > _______________________________________________
>>> > > cisco-voip mailing list
>>> > > cisco-voip@puck.nether.net
>>> > > https://puck.nether.net/mailman/listinfo/cisco-voip
>>> >
>>> >
>>>
>>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
Re: quick question about sip and CUBE [ In reply to ]
I have also discovered that SCCP devices do not experience the issue. It
is only SIP from what I can tell.


On Wed, Apr 10, 2013 at 12:33 PM, Erick Wellnitz <ewellnitzvoip@gmail.com>wrote:

> I don't see any SDL alerts but now I have other devices that are
> registered to the sub that can't call to devices on the Pub.
>
>
> On Wed, Apr 10, 2013 at 10:57 AM, Ryan Ratliff <rratliff@cisco.com> wrote:
>
>> If devices are registered to the sub and the call failed routing to the
>> pub I'd guess the pub lost its SDL connection to the sub, or for some
>> reason isn't aware of the devices registered to the sub.
>>
>> -Ryan
>>
>> On Apr 10, 2013, at 11:28 AM, Erick Wellnitz <ewellnitzvoip@gmail.com>
>> wrote:
>>
>> I guess the next question would be: Why did it work before with the dial
>> peer with preference 1 pointing at the publisher which is the secondary in
>> the CM Group and why did it suddenly stop working?
>>
>>
>> On Wed, Apr 10, 2013 at 10:02 AM, Ryan Ratliff <rratliff@cisco.com>wrote:
>>
>>> In 8.x and later trunks have an option to run on all nodes (like RLs).
>>> This would likely have saved you some pain.
>>>
>>> -Ryan
>>>
>>> On Apr 10, 2013, at 10:38 AM, Erick Wellnitz <ewellnitzvoip@gmail.com>
>>> wrote:
>>>
>>> Here is what fixed the problem:
>>>
>>> CM Group contains:
>>> Sub
>>> Pub
>>>
>>> Dial Peers had preference:
>>> Pub
>>> Sub
>>>
>>> I switched the dial peer preference to:
>>> Sub
>>> Pub
>>>
>>> Now all calls work as expected. I have seen this before but I seem to
>>> forget this trunk behavior in troubleshooting.
>>>
>>> Thanks for all of the advice!
>>>
>>>
>>> On Tue, Apr 9, 2013 at 2:36 PM, Tom Piscitell (tpiscite) <
>>> tpiscite@cisco.com> wrote:
>>>
>>>> Sorry, I forgot an important piece of the puzzle. CUCM will only accept
>>>> SIP messages for a given SIP Trunk on CUCM nodes that are in the CM Group
>>>> of the SIP Trunk's Device Pool. For example:
>>>>
>>>> Here are your 3 CUCM nodes in the cluster:
>>>> publisher
>>>> subscriber-a
>>>> subscriber-b
>>>>
>>>> and you create a SIP Trunk, call it "To_UK_CUBE" and put it in a Device
>>>> Pool with the following CM Group:
>>>>
>>>> subscriber-a
>>>> subscriber-b
>>>>
>>>> CUCM will reply with a 503 if you send a SIP INVITE to the publisher
>>>> from the UK CUBE.
>>>>
>>>> HTH,
>>>> -Tom
>>>>
>>>> On Apr 9, 2013, at 1:11 PM, Erick Wellnitz <ewellnitzvoip@gmail.com>
>>>> wrote:
>>>>
>>>> > Yes, that warning message is present.
>>>> >
>>>> > Here is the sanitized message:
>>>> >
>>>> > 04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP
>>>> TCP message to 10.252.xxx.xxx on port 46625 index 1864
>>>> >
>>>> > SIP/2.0 503 Service Unavailable
>>>> >
>>>> > Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33
>>>> >
>>>> > From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528
>>>> >
>>>> > To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627
>>>> >
>>>> > Date: Tue, 09 Apr 2013 08:16:28 GMT
>>>> >
>>>> > Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX
>>>> >
>>>> > CSeq: 101 INVITE
>>>> >
>>>> > Allow-Events: presence
>>>> >
>>>> > Warning: 399 ccmsub "Unable to find a device handler for the request
>>>> received on port 5060 from 10.252.XXX.XXX"
>>>> >
>>>> > Content-Length: 0
>>>> >
>>>> >
>>>> > My trunk points to the correct address and uses port 5060 in both
>>>> directions.
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <
>>>> tpiscite@cisco.com> wrote:
>>>> > Is there a Warning header in the 503? CUCM sends a 503 with the
>>>> following header in it when it cannot match the IP/port of the incoming SIP
>>>> message to a SIP Trunk.
>>>> >
>>>> > Warning: 399 <CUCM-Server> "Unable to find a device handler for the
>>>> > request received on port <port> from <far-end-ip>"
>>>> >
>>>> > HTH,
>>>> > -Tom
>>>> >
>>>> > On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
>>>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>> _______________________________________________
>>>> > >>> cisco-voip mailing list
>>>> > >>> cisco-voip@puck.nether.net
>>>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>> _______________________________________________
>>>> > >>> cisco-voip mailing list
>>>> > >>> cisco-voip@puck.nether.net
>>>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> > >>
>>>> > >
>>>> > > _______________________________________________
>>>> > > cisco-voip mailing list
>>>> > > cisco-voip@puck.nether.net
>>>> > > https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> >
>>>> >
>>>>
>>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>
Re: quick question about sip and CUBE [ In reply to ]
We restsrted the Ris data collector snd it all stsrted working again.
I have also discovered that SCCP devices do not experience the issue. It
is only SIP from what I can tell.


On Wed, Apr 10, 2013 at 12:33 PM, Erick Wellnitz <ewellnitzvoip@gmail.com>wrote:

> I don't see any SDL alerts but now I have other devices that are
> registered to the sub that can't call to devices on the Pub.
>
>
> On Wed, Apr 10, 2013 at 10:57 AM, Ryan Ratliff <rratliff@cisco.com> wrote:
>
>> If devices are registered to the sub and the call failed routing to the
>> pub I'd guess the pub lost its SDL connection to the sub, or for some
>> reason isn't aware of the devices registered to the sub.
>>
>> -Ryan
>>
>> On Apr 10, 2013, at 11:28 AM, Erick Wellnitz <ewellnitzvoip@gmail.com>
>> wrote:
>>
>> I guess the next question would be: Why did it work before with the dial
>> peer with preference 1 pointing at the publisher which is the secondary in
>> the CM Group and why did it suddenly stop working?
>>
>>
>> On Wed, Apr 10, 2013 at 10:02 AM, Ryan Ratliff <rratliff@cisco.com>wrote:
>>
>>> In 8.x and later trunks have an option to run on all nodes (like RLs).
>>> This would likely have saved you some pain.
>>>
>>> -Ryan
>>>
>>> On Apr 10, 2013, at 10:38 AM, Erick Wellnitz <ewellnitzvoip@gmail.com>
>>> wrote:
>>>
>>> Here is what fixed the problem:
>>>
>>> CM Group contains:
>>> Sub
>>> Pub
>>>
>>> Dial Peers had preference:
>>> Pub
>>> Sub
>>>
>>> I switched the dial peer preference to:
>>> Sub
>>> Pub
>>>
>>> Now all calls work as expected. I have seen this before but I seem to
>>> forget this trunk behavior in troubleshooting.
>>>
>>> Thanks for all of the advice!
>>>
>>>
>>> On Tue, Apr 9, 2013 at 2:36 PM, Tom Piscitell (tpiscite) <
>>> tpiscite@cisco.com> wrote:
>>>
>>>> Sorry, I forgot an important piece of the puzzle. CUCM will only accept
>>>> SIP messages for a given SIP Trunk on CUCM nodes that are in the CM Group
>>>> of the SIP Trunk's Device Pool. For example:
>>>>
>>>> Here are your 3 CUCM nodes in the cluster:
>>>> publisher
>>>> subscriber-a
>>>> subscriber-b
>>>>
>>>> and you create a SIP Trunk, call it "To_UK_CUBE" and put it in a Device
>>>> Pool with the following CM Group:
>>>>
>>>> subscriber-a
>>>> subscriber-b
>>>>
>>>> CUCM will reply with a 503 if you send a SIP INVITE to the publisher
>>>> from the UK CUBE.
>>>>
>>>> HTH,
>>>> -Tom
>>>>
>>>> On Apr 9, 2013, at 1:11 PM, Erick Wellnitz <ewellnitzvoip@gmail.com>
>>>> wrote:
>>>>
>>>> > Yes, that warning message is present.
>>>> >
>>>> > Here is the sanitized message:
>>>> >
>>>> > 04/09/2013 03:16:28.118 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP
>>>> TCP message to 10.252.xxx.xxx on port 46625 index 1864
>>>> >
>>>> > SIP/2.0 503 Service Unavailable
>>>> >
>>>> > Via: SIP/2.0/TCP 10.252.xxx.xxx:5060;branch=z9hG4bKAFEE1E33
>>>> >
>>>> > From: sip:+4420319#####@10.252.XXX.XXX;tag=E8A08E44-2528
>>>> >
>>>> > To: <sip:+131260XXXXX@172.16.XXX.XXX>;tag=1141366627
>>>> >
>>>> > Date: Tue, 09 Apr 2013 08:16:28 GMT
>>>> >
>>>> > Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98@10.252.XXX.XXX
>>>> >
>>>> > CSeq: 101 INVITE
>>>> >
>>>> > Allow-Events: presence
>>>> >
>>>> > Warning: 399 ccmsub "Unable to find a device handler for the request
>>>> received on port 5060 from 10.252.XXX.XXX"
>>>> >
>>>> > Content-Length: 0
>>>> >
>>>> >
>>>> > My trunk points to the correct address and uses port 5060 in both
>>>> directions.
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Apr 9, 2013 at 11:22 AM, Tom Piscitell (tpiscite) <
>>>> tpiscite@cisco.com> wrote:
>>>> > Is there a Warning header in the 503? CUCM sends a 503 with the
>>>> following header in it when it cannot match the IP/port of the incoming SIP
>>>> message to a SIP Trunk.
>>>> >
>>>> > Warning: 399 <CUCM-Server> "Unable to find a device handler for the
>>>> > request received on port <port> from <far-end-ip>"
>>>> >
>>>> > HTH,
>>>> > -Tom
>>>> >
>>>> > On Apr 9, 2013, at 11:59 AM, Erick Wellnitz <ewellnitzvoip@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@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@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@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@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@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@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@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@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@puck.nether.net
>>>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>> _______________________________________________
>>>> > >>> cisco-voip mailing list
>>>> > >>> cisco-voip@puck.nether.net
>>>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>> _______________________________________________
>>>> > >>> cisco-voip mailing list
>>>> > >>> cisco-voip@puck.nether.net
>>>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> > >>
>>>> > >
>>>> > > _______________________________________________
>>>> > > cisco-voip mailing list
>>>> > > cisco-voip@puck.nether.net
>>>> > > https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> >
>>>> >
>>>>
>>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>