[cisco-voip] quick question about sip and CUBE

Wed Apr 10 16:47:59 EDT 2013

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 at 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 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/2543830d/attachment.html>