[cisco-voip] quick question about sip and CUBE

Wed Apr 10 11:28:03 EDT 2013

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 at 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 at 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 at 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 at 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 at 172.16.XXX.XXX>;tag=1141366627
>> >
>> > Date: Tue, 09 Apr 2013 08:16:28 GMT
>> >
>> > Call-ID: 9C9AF490-A02411E2-96059282-DB3C4A98 at 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 at 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 at gmail.com>
>> wrote:
>> >
>> > > We expect + followed by 11 digits, which we receive.  We rely on the
>> inbound trunk settings to strip it to 4 digits.  Would traces show if it is
>> being stripped to 4 digits?
>> > >
>> > > RTMT isn't giving any clues either.
>> > >
>> > >
>> > >
>> > >
>> > > On Tue, Apr 9, 2013 at 10:52 AM, Kenneth Hayes <
>> kennethwhayes at gmail.com> wrote:
>> > > Have you ran RTMT? Also on the trunk have you checked what you are
>> expecting inbound?
>> > >
>> > > Sent from my iPhone
>> > >
>> > > On Apr 9, 2013, at 11:49 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>
>> wrote:
>> > >
>> > >> There is no carrier involved.
>> > >>
>> > >> The call is UK CUCM -> UK CUBE -> Global Network -> US CUBE -> US
>> CUCM
>> > >>
>> > >> All of the branches are part of the whole but operate independently
>> which is why it is set up like this.
>> > >>
>> > >> The US CUCM is sending the 503 to the UK caller.  The only thing I
>> can think of is that for some reason the trunk isn't acknowledging the set
>> significant digits.
>> > >>
>> > >>
>> > >> On Tue, Apr 9, 2013 at 10:26 AM, Kenneth Hayes <
>> kennethwhayes at gmail.com> wrote:
>> > >> 503 is a carrier issue with the service.
>> > >>
>> > >> Sent from my iPhone
>> > >>
>> > >> On Apr 9, 2013, at 11:05 AM, Erick Wellnitz <ewellnitzvoip at gmail.com>
>> wrote:
>> > >>
>> > >>> We got that working but I think we have another issue that I'm not
>> sure how to verify.
>> > >>>
>> > >>> I didn't change any of the dial-peers pointing to the CUCM yet, I
>> have only modified the one trunk to use port 5070 so it will not interfere
>> with the current trunk for inbound.
>> > >>>
>> > >>> Now we get a 503 service unavailable for calls from the remote
>> system.  Will I need to change my existing dial-peers to
>> xxx.xxx.xxx.xxx:5060 before I add any dial-peers for use on the new trunk
>> that uses 5070?  All inbound worked fine until I added this second trunk.
>> > >>>
>> > >>>
>> > >>> On Tue, Apr 9, 2013 at 9:28 AM, Nick Matthews <matthnick at gmail.com>
>> wrote:
>> > >>> I've seen this configuration before - sometimes certain call flows
>> require MTP for devices/integrations on the CUCM side.  You don't have to
>> set up multiple listening ports on CUBE, as it's indifferent. On CUCM the
>> two trunks have different source ports. If it's outbound from CUCM only
>> that matters, no CUBE changes are required. If you need inbound calls to
>> have MTP only for certain calls changing the port is the best way.
>> > >>>
>> > >>> I believe with SIP trunks CUCM will not allow two trunks to the
>> same address with the same source port, but it will allow you with H.323
>> gateways. However, the choice of which of those gateways is basically
>> random and you may think there are two but it's only using one, but that's
>> a H.323 caveat.
>> > >>>
>> > >>> -nick
>> > >>>
>> > >>>
>> > >>> On Thu, Apr 4, 2013 at 1:02 PM, Erick Wellnitz <
>> ewellnitzvoip at gmail.com> wrote:
>> > >>> Doh.  I forgot about changing the port.
>> > >>>
>> > >>> I think that answers my question.  I can have one trunk on 5060 for
>>  site to site calls w/ MTP and one trunk to 5061 for least cost routing
>> from/to other sites.
>> > >>>
>> > >>> This seems like it will suit our needs perfectly.
>> > >>>
>> > >>>
>> > >>>
>> > >>> On Thu, Apr 4, 2013 at 11:09 AM, Anthony Holloway <
>> avholloway+cisco-voip at gmail.com> wrote:
>> > >>> What's your ultimate goal that you want/need two trunks to a single
>> CUBE?
>> > >>>
>> > >>> So in CUBE you would do something like this:
>> > >>>
>> > >>> dial-peer voice 1 voip
>> > >>>  description Trunk 1
>> > >>>  session protocol sipv2
>> > >>>  destination-pattern 1...$
>> > >>>  session-target ipv4:10.1.1.1:5061
>> > >>> !
>> > >>> dial-peer voice 2 voip
>> > >>>  description Trunk 2
>> > >>>  session protocol sipv2
>> > >>>  destination-pattern 2...$
>> > >>>  session-target ipv4:10.1.1.1:5062
>> > >>> !
>> > >>>
>> > >>> And then in CUCM you would need to create two new SIP Trunk
>> Security Profiles (Found under System > Security in 8.6), specifying the
>> port in which CUCM should expect to receive the messages.  Create your two
>> trunks pointing to the CUBE, using respective SIP Trunk security profiles,
>> and that's how you force an inbound trunk.
>> > >>>
>> > >>> As for the MTP question: You can require MTP for all calls, which
>> can be good and bad.  That's no different from H323 trunks to gateways.
>>  The require only when needed comes in to play for SIP Early Offer only.
>>  And that's a matter of the calling device and whether or not CUCM receives
>> its capabilities or has to make something up using an MTP's capbilities.
>>  DTMF relay mismatch (Out of band versus In band) is a different story, and
>> there's no check box for that.  That's simply a function of the Media
>> Manager and the MRGL on the SIP trunk, which will correct DTMF mismatches
>> automatically by dynamically using an MTP as needed.  So, three different
>> things going on there.
>> > >>>
>> > >>> I hope that helped explain it a bit more.  Maybe someone else will
>> fill in some of my gaps.
>> > >>>
>> > >>>
>> > >>> On Thu, Apr 4, 2013 at 10:22 AM, Erick Wellnitz <
>> ewellnitzvoip at gmail.com> wrote:
>> > >>>
>> > >>> If I have two sip trunks from CUCM to CUBE (one which requires MTP
>> and one which does not) how does the CUBE or CUCM know which trunk settings
>> to use for inbound calls to CUCM?
>> > >>>
>> > >>> Is it best to make all of the inbound settings the same and do all
>> of the translations on the CUBE or CUCM translation patterns instead of
>> setting the significant digits?
>> > >>>
>> > >>> I'm also remembering someone telling me a while back that if you
>> uncheck the MTP Required that th etrunk will still allocate MTP if needed.
>>  Is that correct?  It would allow me to only use the one trunk with
>> translations.
>> > >>>
>> > >>> As always, thanks for the help!
>> > >>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> cisco-voip mailing list
>> > >>> cisco-voip at puck.nether.net
>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> cisco-voip mailing list
>> > >>> cisco-voip at puck.nether.net
>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> > >>>
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> cisco-voip mailing list
>> > >>> cisco-voip at puck.nether.net
>> > >>> https://puck.nether.net/mailman/listinfo/cisco-voip
>> > >>
>> > >
>> > > _______________________________________________
>> > > cisco-voip mailing list
>> > > cisco-voip at puck.nether.net
>> > > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>> >
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130410/e4528f98/attachment.html>