[cisco-voip] quick question about sip and CUBE

Wed Apr 10 13:33:06 EDT 2013

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 at 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 at 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 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/9569bbf8/attachment.html>