[cisco-voip] quick question about sip and CUBE

Tue Apr 9 15:49:41 EDT 2013

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 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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130409/e4479b49/attachment.html>