[cisco-voip] quick question about sip and CUBE

Erick Wellnitz ewellnitzvoip at gmail.com
Tue Apr 9 13:11:03 EDT 2013


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/7a00e40f/attachment.html>


More information about the cisco-voip mailing list