[cisco-voip] Force an outgoing call through a subscriber

Brian Meade bmeade90 at vt.edu
Mon Jul 24 15:50:52 EDT 2017


Ariel,

What version are you on?  There were some VMWare driver issues a long time
ago that would cause issues with IPVMS resources-
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtz29142

Brian

On Mon, Jul 24, 2017 at 3:31 PM, ROZA, Ariel <Ariel.ROZA at la.logicalis.com>
wrote:

> Hi, Ryan, Anthony, et al,
>
>
>
>   I´m sorry by the blunt nature of my first mail. I was burned out, at my
> customer´s.
>
>
>
>   My problem is this:
>
>   The users are complaining of broken audio in random calls to the PSTN
>
>
>
>   We Isolated the issue to a single subscriber that acts as MTP for calls,
> sometimes.
>
> Wireshark captures show us that whenever the sub acts as an intermediary,
> audio gets jitter (but no drops) This is on the upstream to the PSTN. The
> downstream is always fine.
>
> We suspect of a problem in the underlying nework, as the Publisher and the
> Subs are wired differently and only the Subscriber show these problems.
>
> The Publisher is connected to a CAT4500 switch and the Sub is connected to
> a NEXUS 5000  that in turn is connected to the Cat4500
>
>
>
> I am already using MRGL/MRGs to  force MTP, but sometimes the phones send
> the RTP directly to the gateway, bypassing the MTP. (calling always the
> same number)
>
>
>
>
>
> *De:* Ryan Huff [mailto:ryanhuff at outlook.com]
> *Enviado el:* domingo, 23 de julio de 2017 07:03 p.m.
> *Para:* Anthony Holloway <avholloway+cisco-voip at gmail.com>
> *CC:* ROZA, Ariel <Ariel.ROZA at LA.LOGICALIS.COM>; cisco-voip <
> cisco-voip at puck.nether.net>
> *Asunto:* Re: [cisco-voip] Force an outgoing call through a subscriber
>
>
>
> Anthony,
>
>
>
> Yes, it is splitting hairs IMO :). I'm specifically talking about a
> typical scenario where RTP is sent from/to the phone for a connected,
> like-codec call that is not forcing media termination with the next device
> in the call leg.
>
>
>
> As you and I have mentioned, there are a handful of ways to use different
> features and services of a CUCM server to terminate and join media streams
> (MTP, CFB ... etc) ... and I considers these as ancillary service and
> component capabilities to the server and not a core function of the server
> itself (hence, media not flowing through the server, although it maybe
> interacting with one or more of the aforementioned media services or
> components).
>
>
>
> Always happy to split hairs :).
>
> Sent from my iPhone
>
>
> On Jul 23, 2017, at 5:18 PM, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
> This may be splitting hair here, but two things Ryan:
>
>
>
> 1) Your first sentence reads to me like a contradiction.  Could you
> clarify what you're stating here?
>
>
>
> 2) Media can flow through, and even terminate on CUCM, since things like
> Conference Bridges, MTPs and now the new IVR media resource, are all doing
> that.
>
>
>
> On Fri, Jul 21, 2017 at 2:53 PM Ryan Huff <ryanhuff at outlook.com> wrote:
>
> So the actual media (RTP) will never flow through a CUCM server; it may
> however, terminate a connected media stream on a software based MTP
> application that CUCM runs as a service (IP Voice Media Streaming
> Application). Signaling (SIP) on the other hand, will always traverse a
> CUCM server.
>
>
>
> If you see a CUCM IP address in the Audio field of the SDP, then it's
> likely terminating on a CUCM based MTP resource (most often, due to some
> differences in DTMF negotiations or because the egress path in CUCM is
> required to use MTP).
>
>
>
> If you are trying to test a call using a CUCM MTP resource on a particular
> cluster node; the simplest way would be to create a new MRG/MRGL that only
> specifies MTP resources from the desired cluster node and then advertise
> that MRGL to the phone and/or egress path to the pstn for the phone and
> then "require" MTP termination from the phone or egress path.
>
> Is the problem you're troubleshooting have anything to do with one-way or
> no-way audio by chance?
>
>
> Thanks,
>
>
>
> Ryan
>
>
> On Jul 21, 2017, at 3:37 PM, ROZA, Ariel <Ariel.ROZA at LA.LOGICALIS.COM>
> wrote:
>
> Hi, Guys.
>
> I need to test problems with calls outgoing from an Ip phone to the PSTN
> through a particular subscriber (as MTP?).
>
> How can I force them to do that.
>
> Packet captures show me that, at times, calls go from my phone to the h323
> gateway and sometimes they go from my phone to the Sub and then to the gew.
>
> Obtener Outlook para Android
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fghei36&data=02%7C01%7CAriel.ROZA%40la.logicalis.com%7C1e58758c6884429f5d0d08d4d2169e17%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C636364441966497710&sdata=0AscsFwizg82xmGqihl67oG7G1Czd3U8w5dCXgStsqM%3D&reserved=0>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7CAriel.ROZA%40la.logicalis.com%7C1e58758c6884429f5d0d08d4d2169e17%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C636364441966497710&sdata=9oen7Q8tcFNNBPJVpnDcx53bkVd1UOGp%2Fi9H2faKf9c%3D&reserved=0>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7CAriel.ROZA%40la.logicalis.com%7C1e58758c6884429f5d0d08d4d2169e17%7C2e3290cb8d404058abe502c4f58b87e3%7C0%7C0%7C636364441966497710&sdata=9oen7Q8tcFNNBPJVpnDcx53bkVd1UOGp%2Fi9H2faKf9c%3D&reserved=0>
>
>
> _______________________________________________
> 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/20170724/9867b120/attachment.html>


More information about the cisco-voip mailing list