Send cisco-voip mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. Meetingplace v8.0 (Andy)
2. Ulaw -Alaw and MTP resources (abbas Wali)
3. cisco conference bridge (harbor235)
4. Re: intercluster trunk over IPSec VPN (Abebe Amare)
5. Re: Ulaw -Alaw and MTP resources (Ryan Ratliff)
6. SIP-Trunk fallback to hunt pilot (Heimo Stieg)
7. FXO port DID on H.323 VG (Peng WAN)
8. Re: Ulaw -Alaw and MTP resources (abbas Wali)
9. Re: Ulaw -Alaw and MTP resources (abbas Wali)
10. media resource exhausted (Scott Voll)
11. Re: MeetingPlace 8.5 and WebEx (Salisbury, Charles)
12. Re: media resource exhausted (abbas Wali)
13. Re: Ulaw -Alaw and MTP resources (Peter Slow)
14. Re: Ulaw -Alaw and MTP resources (abbas Wali)
15. Re: Ulaw -Alaw and MTP resources (abbas Wali)
----------------------------------------------------------------------
Message: 1
Date: Mon, 19 Nov 2012 11:37:45 +0000
From: Andy <[email protected]>
To: Cisco VoIP List <[email protected]>
Subject: [cisco-voip] Meetingplace v8.0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
HI,
I'm trying to setup a meetingplace v8.0 in my lab.
I've installed the server and it works sort of.
I get it that its only audio, but is there any way of configuring it so
that you can schedule meetings via outlook?
The documentation mentions about configuring web servers, I guess that
this is the "webex" bit which you can't do on the demo setup even though
the license says you can have it.
Any pointers?
--
Regards
Andy
------------------------------
Message: 2
Date: Mon, 19 Nov 2012 13:40:38 +0000
From: abbas Wali <[email protected]>
To: [email protected]
Subject: [cisco-voip] Ulaw -Alaw and MTP resources
Message-ID:
<cafdhcp7+z9cbantq-sp3vbvovj5em9gr0rhdh2zqls7bv7z...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
just to clairfy, we have confirgured PCM Type to ALaw (as in UK) on the
MGCP gateways but all calls received shows ULaw on the phones.
I believe our MGCP gateway is transcoding them as below
Gateway3#show voice dsp active
DSP DSP DSPWARE CURR BOOT PAK
TX/RX
TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT
PACK COUNT
==== === == ======== ========== ===== ======= === == ========= == =====
============
----------------------------FLEX VOICE CARD 0 -----------------------
-------
*DSP ACTIVE VOICE CHANNELS*
DSP DSPWARE VOX DSP SIG DSP PAK
TX/RX
TYPE VERSION CODEC NUM CH TS VOICEPORT SLT NUM CH TS RST AI ABRT
PACK COUNT
====== ========== ======== === == == ========= === === == == === == ====
============
C5510 27.3.1 *g711ulaw* 001 01 29 0/0/0:15 000 002 12 29 0 0
0 13359/13680
C5510 27.3.1 g711ulaw 001 02 31 0/0/0:15 000 002 14 31 0 0
0 3707/3816
The SIP trunks are enalbed to use MTP resources and the MTP Preferred
Originating Codec[image: Required Field] is set to ALaw.
I think we are wasting alot of MTP resources converting from A to U. is
there a way to use a uniform codec in CUCM 8.5.
Many thanks
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/a5d5ac01/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 19 Nov 2012 08:41:05 -0500
From: harbor235 <[email protected]>
To: Cisco VOIP <[email protected]>
Subject: [cisco-voip] cisco conference bridge
Message-ID:
<cab_zydk7fm9kp9wshwbzxf_xufht8fu1kofwws3fpgwax42...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I am looking for a Cisco conference bridge that will work with CME but
provide as many advanced features as possible, does
anyone have any recommendations?
thanks in advance,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/e79f3dbf/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 19 Nov 2012 16:47:28 +0300
From: Abebe Amare <[email protected]>
To: Nick Matthews <[email protected]>, Peter Slow
<[email protected]>
Cc: cisco voip <[email protected]>, Wes Sisk
<[email protected]>
Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN
Message-ID:
<CANrv87hLfJqcsB9XMYb_p_dMc-kH6U4BweARa=tx2ltpp4t...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Hi,
I apologize for digging up an old issue. The problem I am facing now is
having No Ringback Tone for Calls from Cisco CallManager to Cisco
CallManager Express. I followed the guide on
http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a0080094c33.shtml#ringcme
but it did not solve the problem.
I have attached a trace file from the CUCM while making the call.
On Thu, Feb 16, 2012 at 2:28 PM, Abebe Amare <[email protected]> wrote:
> Hi Nick, Peter
>
> Enabling H323 fast start on both ends did the trick. I highly appreciate
> all of the incredible support I received from the group.
>
> best regards,
>
> Abebe
>
> On Thu, Feb 16, 2012 at 1:28 AM, Nick Matthews <[email protected]>wrote:
>
>> A few notes:
>> -ICT to CME isn't the recommended option. ICT is very similar to
>> H.323 so it will work but you may run into weird issues like transfers
>> failing with ICT vs H323 Gateway.
>>
>> -When the ASA creates the IPsec tunnel it will automatically copy the
>> DSCP marking from the inside packet to the outside packet. So if
>> you're correctly doing QoS based on DSCP you should still be in good
>> shape. If you need it based on L4-L7 it would need to happen before
>> the ASA. On a router you use 'qos pre-classify' if it's doing both
>> the tunneling and QoS.
>>
>> -IPSec through any wan acceleration is probably not very effective.
>> It may be best to exempt the entire stream, as well as any RTP/UDP
>> traffic.
>>
>> -Pete has a very good point. They call it fast start for a reason.
>> When you switch it to a H323 gateway enable both inbound and outbound
>> fast start. You'll need to check 'MTP Required' and make sure you've
>> got a software MTP on a router to do g729 mtp sessions. This could
>> cut down a few seconds of delay.
>>
>> -nick
>>
>> On Wed, Feb 15, 2012 at 8:28 AM, Wes Sisk <[email protected]> wrote:
>> > Abebe,
>> >
>> > I also believe Jason has a good point. I have only seen bad results
>> when
>> > combining with WCCP mechanisms.
>> >
>> > /wes
>> >
>> > On Feb 15, 2012, at 3:52 AM, Abebe Amare wrote:
>> >
>> > Hi Peter,
>> >
>> > It is possible to create an ICT pointing to a CME. On the CME side, you
>> just
>> > configure voip dial-peer pointing to the CM. Saying that, here is a how
>> the
>> > problem manifests:
>> > 1.The problem occurs during call set up and on one leg (the caller does
>> not
>> > hear the receiver). This happens regardless of the call setup
>> originating
>> > from the CM or CME side.
>> > 2.The caller usually does not hear the other side for few seconds (3-4);
>> > this happens right after the ring-back tone is stopped.
>> > 3.The receiver when picking up the phone and starts by saying hello the
>> > other party does not hear any voice until 3-4 seconds elapse.
>> >
>> > Wes, I will collect packet captures and call statistics from the phone
>> > concurrently and compare the result.
>> >
>> > best regards,
>> >
>> > Abebe
>> >
>> > On Wed, Feb 15, 2012 at 12:20 AM, Jason Aarons (AM)
>> > <[email protected]> wrote:
>> >>
>> >> My coworker spent a month in November working a issue only to find a
>> >> Riverbed was messing with control traffic. Not your issue, but I find
>> you
>> >> spend more in labor hours than you get back in bandwidth costs. I?d
>> exclude
>> >> voip. How much wan optimization can you get out of G.7xx ?
>> >>
>> >>
>> >>
>> >> From: [email protected]
>> >> [mailto:[email protected]] On Behalf Of Abebe Amare
>> >> Sent: Tuesday, February 14, 2012 12:45 PM
>> >> To: Wes Sisk; Stephen Welsh; Mike King
>> >>
>> >>
>> >> Cc: cisco voip
>> >> Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Hi Wes,
>> >>
>> >> Here is how the devices involved are connected
>> >>
>> >> CUCM->6509->ASA->Packetshaper->2821->VSAT Link->Internet<-ASA<-CUCME
>> >>
>> >> I do not have control over the CUCME on the remote side for the moment.
>> >> The VPN tunnels terminate at the ASA on each side. I am not
>> comfortable with
>> >> configuring QoS on the ASA, that is why I configured on the 2821. And
>> since
>> >> the 2821 can not see the pre-tunnel traffic, I decided to put the
>> traffic
>> >> passing over the tunnel in LLQ.
>> >> The VSAT link is used for basic Internet browsing. The speed of the
>> VSAT
>> >> connection is 768 kbps and we do take slow TCP connection as
>> acceptable. We
>> >> use IronPort web security appliance together with Packetshaper to
>> tightly
>> >> control what goes on the link.
>> >>
>> >> I have collected some RTP streams using wireshark and it does not show
>> >> excessive jitter, delay or packet loss in the RTP analysis which seems
>> to
>> >> contradict what I shared about the RTP statistics directly from the
>> phone.
>> >> How do I find out if the call setup signalling is delayed?
>> >>
>> >> regards,
>> >>
>> >> Abebe
>> >>
>> >> On Tue, Feb 14, 2012 at 7:15 PM, Wes Sisk <[email protected]> wrote:
>> >>
>> >> My QoS is a bit rusty as it's time to re-certify. That said "put the
>> VPN
>> >> traffic in LLQ" doesn't sound quite right. It is *voice* that needs
>> to be
>> >> in LLQ.
>> >>
>> >>
>> >>
>> >>
>> >>
>> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/netstruc.html#wp1044413
>> >>
>> >>
>> >>
>> >> Otherwise, it might be beneficial to conduct some tests to better
>> >> understand the network. What traffic flows over the VSAT link? Is
>> the
>> >> call setup signaling delayed? Is there excessive delay at the
>> beginning of
>> >> any TCP/UDP stream or is that unique to the UDP/RTP voice traffic?
>> >>
>> >>
>> >>
>> >> Regards,
>> >>
>> >> Wes
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Feb 14, 2012, at 1:23 AM, Abebe Amare wrote:
>> >>
>> >>
>> >> Hi Wes, thanks a lot for your detail explanation, it is very
>> educational.
>> >>
>> >> I should have stated earlier that the Internet connection is a VSAT
>> link.
>> >> Here is a ping output from the CUCM to the far side CUCME,
>> >>
>> >> admin:utils network ping 192.168.100.1
>> >> PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
>> >> 64 bytes from 192.168.100.1: icmp_seq=0 ttl=254 time=577 ms
>> >> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=254 time=579 ms
>> >> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=254 time=587 ms
>> >> 64 bytes from 192.168.100.1: icmp_seq=3 ttl=254 time=584 ms
>> >>
>> >> --- 192.168.100.1 ping statistics ---
>> >> 4 packets transmitted, 4 received, 0% packet loss, time 3036ms
>> >> rtt min/avg/max/mdev = 577.892/582.386/587.697/4.048 ms, pipe 2
>> >>
>> >> I have configured QoS on the gateway routers to put the VPN traffic in
>> LLQ
>> >> with reserved bandwidth. What other mechanisms do you suggest to
>> improve the
>> >> voice quality?
>> >>
>> >> best regards,
>> >>
>> >> Abebe
>> >>
>> >> On Mon, Feb 13, 2012 at 6:06 PM, Wes Sisk <[email protected]> wrote:
>> >>
>> >> Hi Abebe,
>> >>
>> >>
>> >>
>> >> Those are pretty bad. These are of particular concern:
>> >>
>> >> Rcvr Codec G729
>> >> Sender Codec G729
>> >> Rcvr size 20ms
>> >> sender size 20ms
>> >> Rcvr Packets 476
>> >> sender packets 709
>> >> Avg Jitter 31
>> >> Max Jitter 185
>> >> Rcvr discarded 1
>> >>
>> >> Cumulative Conceal ratio 0.0319
>> >> Max Conceal ratio 0.0446
>> >> Conceal sec 5
>> >> Severly conceal sec 1
>> >>
>> >>
>> >>
>> >> I interpret this as:
>> >>
>> >> G.729 has a lower MOS so we're starting with less audio quality. The
>> >> phone sent 709 packets but received 476 packets. At 20msec
>> packetization
>> >> the phone has sent 14.1 seconds of audio but received only 9.5 seconds
>> of
>> >> audio. The phone cannot begin counting until the first RTP packet
>> arrives
>> >> so this may account for an additional gap between these metrics and
>> actual
>> >> user experience. The tx/rx is normally very similar. Either there was
>> a
>> >> delay in signaling negotiating bidirectional audio or this phone first
>> >> started receiving RTP packets ~5 seconds into the call. After that
>> Jitter
>> >> of 31 is not great but would generally still be intelligible audio.
>> Max
>> >> jitter of 185 is pretty much impossible to recover. Each packet should
>> >> contain 20msec of audio. At least one packet arrived 185msec late.
>> >>
>> >>
>> >>
>> >> Recvr discarded 1 means the phone discarded one rtp packet it received.
>> >> Discard can happen for several reasons but with max jitter 185 it is
>> very
>> >> likely the packet was just too late to be used. When a 20msec slice of
>> >> audio is unavailable the phone attempts to conceal that in the audio
>> stream.
>> >> This leads to next stats:
>> >>
>> >> Conceal sec 5
>> >> Severly conceal sec 1
>> >>
>> >> For 5 seconds the phone used the g.729 packet loss concealment
>> algorithm
>> >> to try and mask the absence of packets. This is going to be silence,
>> noise,
>> >> or otherwise unintelligible audio to the user.
>> >>
>> >>
>> >>
>> >> It looks like something is indeed inhibiting RTP packet flow toward
>> this
>> >> phone. A packet capture will show more details but it's not
>> particularly
>> >> necessary from the phone/application perspective. The underlying
>> packet
>> >> network needs some improvements to delivery adequate voice quality.
>> >>
>> >>
>> >>
>> >> /wes
>> >>
>> >>
>> >>
>> >> On Feb 13, 2012, at 9:31 AM, Abebe Amare wrote:
>> >>
>> >>
>> >> Hi Wes,
>> >>
>> >> Here is the call statistics from the phone for one call
>> >>
>> >> Rcvr Codec G729
>> >> Sender Codec G729
>> >> Rcvr size 20ms
>> >> sender size 20ms
>> >> Rcvr Packets 476
>> >> sender packets 709
>> >> Avg Jitter 31
>> >> Max Jitter 185
>> >> Rcvr discarded 1
>> >> Rcvr lost packets 0
>> >> Avg MOS LQK 0.0
>> >> Min MOS LQK 0.0
>> >> Max MOS LQK 0.0
>> >> Cumulative Conceal ratio 0.0319
>> >> Max Conceal ratio 0.0446
>> >> Conceal sec 5
>> >> Severly conceal sec 1
>> >>
>> >> Is the jitter too high?
>> >>
>> >> regards,
>> >>
>> >> Abebe
>> >>
>> >> On Fri, Feb 10, 2012 at 8:32 PM, Lelio Fulgenzi <[email protected]>
>> wrote:
>> >>
>> >> I was surprised to find that SLA is not included in the IPBase module
>> of
>> >> v15, nor in the UC module. You need the Data module.
>> >>
>> >> Sent from my iPhone...
>> >>
>> >>
>> >>
>> >> "There's no place like 127.0.0.1"
>> >>
>> >>
>> >> On Feb 10, 2012, at 12:20 PM, Dennis Heim <[email protected]> wrote:
>> >>
>> >> Maybe a good place for some IP SLA monitoring.
>> >>
>> >>
>> >>
>> >> Dennis Heim
>> >> Senior Engineer (Unified Communications)
>> >> CDW Advanced Technology Services
>> >> 10610 9th Place
>> >> Bellevue, WA 98004
>> >>
>> >> 425.310.5299 Single Number Reach (WA)
>> >>
>> >> 317.569.4255 Single Number Reach (IN)
>> >> 317.569.4201 Fax
>> >> [email protected]
>> >> cdw.com/content/solutions/unified-communications/
>> >>
>> >>
>> >>
>> >> From: [email protected]
>> >> [mailto:[email protected]] On Behalf Of Wes Sisk
>> >> Sent: Friday, February 10, 2012 10:36 AM
>> >> To: Abebe Amare
>> >> Cc: cisco voip
>> >> Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN
>> >>
>> >>
>> >>
>> >> most likely still packet throughput issues. packets may be late to the
>> >> point of discarded. they would not technically be lost in that case.
>> >>
>> >>
>> >>
>> >> this would manifest as high jitter. setup the initial all and press
>> the
>> >> "i" or "?" button twice on the phone to see call statistics. beyond
>> that
>> >> take a packet capture. wireshark has some decent RTP analysis tools
>> built
>> >> in.
>> >>
>> >>
>> >>
>> >> /wes
>> >>
>> >>
>> >>
>> >> On Feb 10, 2012, at 6:41 AM, Abebe Amare wrote:
>> >>
>> >>
>> >> Dears, thank you all for the excellent support
>> >>
>> >> I managed to keep the VPN tunnel up be sending periodic ping but the
>> >> problem still persist. Bandwidth is reserved for at least four calls
>> (taking
>> >> into consideration VPN overhead) on a Packetshaper and the call
>> quality is
>> >> good mid-conversation. But it is is clipping the first few seconds. I
>> dont
>> >> see any packet loss n the CMR records for a test call. What should I be
>> >> looking for?
>> >>
>> >> thanks in advance
>> >>
>> >> Abebe
>> >>
>> >> On Thu, Feb 9, 2012 at 5:57 PM, Wes Sisk <[email protected]> wrote:
>> >>
>> >> TCP keepalives are only used while a call is active.
>> >>
>> >>
>> >>
>> >> When no call is active there is no active h323/h225/h245 signaling, tcp
>> >> session, or udp. The only exception is when gatekeeper is used. Then
>> gk
>> >> registration messages are maintained. Those are over UDP between the
>> h323
>> >> ep and gk.
>> >>
>> >>
>> >>
>> >> for a static ICT defined between two CUCM clusters there is no network
>> >> activity without an active call.
>> >>
>> >>
>> >>
>> >> For the duration of an active call the tcp keepalive parameter will
>> help.
>> >>
>> >>
>> >>
>> >> regards,
>> >>
>> >> wes
>> >>
>> >>
>> >>
>> >> On Feb 9, 2012, at 8:13 AM, Adam Frankel (afrankel) wrote:
>> >>
>> >>
>> >>
>> >> Options Ping was added in 8.5(1).
>> >>
>> >> The parameter "Allow TCP KeepAlives For H323 " should take care of this
>> >> for H323 ICT.
>> >>
>> >> -Adam
>> >>
>> >> ________________________________
>> >>
>> >> From: Abebe Amare <[email protected]>
>> >> Sent: Thu, Feb 09, 2012 4:52:50 AM
>> >> To: Ryan Ratliff <[email protected]>
>> >> CC: cisco voip <[email protected]>
>> >> Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN
>> >>
>> >> Hi Ryan,
>> >>
>> >> The CUCM version is 6.1.3.1000-16. Is the SIP options ping parameter
>> >> available in this version? Where would you enable it if it is
>> available?
>> >>
>> >> thanks in Advance,
>> >>
>> >> Abebe
>> >>
>> >> On Wed, Feb 8, 2012 at 8:07 PM, Ryan Ratliff <[email protected]>
>> wrote:
>> >>
>> >> What about a SIP trunk with options ping enabled?
>> >>
>> >>
>> >>
>> >> -Ryan
>> >>
>> >>
>> >>
>> >> On Feb 8, 2012, at 7:05 AM, Abebe Amare wrote:
>> >>
>> >>
>> >> Hi Dennis,
>> >>
>> >> Configuring a persistent L2L tunnel proved to be very elusive. I
>> settled
>> >> for running a periodic ping scheduled to keep the tunnel running.
>> >>
>> >> Thanks for your help
>> >>
>> >> Abebe
>> >>
>> >> On Tue, Feb 7, 2012 at 6:16 PM, Dennis Heim <[email protected]>
>> wrote:
>> >>
>> >> I think you answered your own question. IPSEC tunnel?s take time to
>> bring
>> >> up. Maybe you could tweak some of the VPN negotiating parameters, or
>> create
>> >> a separate L2 tunnel profile/group just for your voice that is
>> permanent and
>> >> does not have an inactivity timer.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Dennis Heim
>> >> Senior Engineer (Unified Communications)
>> >> CDW Advanced Technology Services
>> >> 10610 9th Place
>> >> Bellevue, WA 98004
>> >>
>> >> 425.310.5299 Single Number Reach (WA)
>> >>
>> >> 317.569.4255 Single Number Reach (IN)
>> >> 317.569.4201 Fax
>> >> [email protected]
>> >> cdw.com/content/solutions/unified-communications/
>> >>
>> >>
>> >>
>> >> From: [email protected]
>> >> [mailto:[email protected]] On Behalf Of Abebe Amare
>> >> Sent: Tuesday, February 07, 2012 4:10 AM
>> >> To: cisco voip
>> >> Subject: [cisco-voip] intercluster trunk over IPSec VPN
>> >>
>> >>
>> >>
>> >> Dears,
>> >>
>> >> I have configured an Inter-Cluster trunk from CUCM to another site with
>> >> CUCME. There is an IPSec L2L VPN terminating at ASA 5500 firewall on
>> both
>> >> ends
>> >>
>> >> CUCM --->ASA 5540--->Internet <---ASA 5510<---CUCME
>> >>
>> >> On the ASA,the IPSec tunnel is terminated after 30 minute of inactivity
>> >> (default) which is causing a problem. When a phone in one site tries
>> to call
>> >> another phone in the other site there is a noticeable gap before actual
>> >> conversation is heard over the phone. Once conversation starts, there
>> is no
>> >> delay or break in audio. Has anyone faced this issue?
>> >>
>> >> best regards,
>> >>
>> >> Abebe
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> cisco-voip mailing list
>> >> [email protected]
>> >> https://puck.nether.net/mailman/listinfo/cisco-voip
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >>
>> >> cisco-voip mailing list
>> >>
>> >> [email protected]
>> >>
>> >> https://puck.nether.net/mailman/listinfo/cisco-voip
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> cisco-voip mailing list
>> >> [email protected]
>> >> https://puck.nether.net/mailman/listinfo/cisco-voip
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> cisco-voip mailing list
>> >> [email protected]
>> >> https://puck.nether.net/mailman/listinfo/cisco-voip
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> itevomcid
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > cisco-voip mailing list
>> > [email protected]
>> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/b783b784/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cucm-trace.txt
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/b783b784/attachment-0001.txt>
------------------------------
Message: 5
Date: Mon, 19 Nov 2012 09:42:06 -0500
From: Ryan Ratliff <[email protected]>
To: abbas Wali <[email protected]>
Cc: [email protected]
Subject: Re: [cisco-voip] Ulaw -Alaw and MTP resources
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
If you were actually transcoding one of those legs would be doing alaw and the
other ulaw. What you see is two ulaw legs which means that your MTP is acting
just like an MTP. I assume by enabling the SIP trunk for MTP you mean you've
checked the "MTP Required" box? That box does just what it says it does, it
forces an MTP for each call.
You aren't wasting MTP resources for transcoding between alaw and ulaw, you are
wasting them because you checked the box.
I'd guess that you are actually using a uniform codec (look at the rtp streams
on your mgcp gateway when a call is active and I'm sure you'll see they are
ulaw there too) just not the codec you want.
You've got two options for forcing ulaw vs alaw. The first is a custom codec
preference list with 711ulaw at the bottom of the list (you can't disable
codecs this way, just prioritize them). Look at System->Region
Information->Audio Codec Preference List. The second option is to disable
g.711 ulaw via the service parameter "G.711 mu-law Codec Enabled".
You may need to upgrade to get one or both of those options.
-Ryan
On Nov 19, 2012, at 8:40 AM, abbas Wali <[email protected]> wrote:
Hi all,
just to clairfy, we have confirgured PCM Type to ALaw (as in UK) on the MGCP
gateways but all calls received shows ULaw on the phones.
I believe our MGCP gateway is transcoding them as below
Gateway3#show voice dsp active
DSP DSP DSPWARE CURR BOOT PAK TX/RX
TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT PACK
COUNT
==== === == ======== ========== ===== ======= === == ========= == =====
============
----------------------------FLEX VOICE CARD 0 -----------------------
-------
*DSP ACTIVE VOICE CHANNELS*
DSP DSPWARE VOX DSP SIG DSP PAK TX/RX
TYPE VERSION CODEC NUM CH TS VOICEPORT SLT NUM CH TS RST AI ABRT PACK
COUNT
====== ========== ======== === == == ========= === === == == === == ====
============
C5510 27.3.1 g711ulaw 001 01 29 0/0/0:15 000 002 12 29 0 0 0
13359/13680
C5510 27.3.1 g711ulaw 001 02 31 0/0/0:15 000 002 14 31 0 0 0
3707/3816
The SIP trunks are enalbed to use MTP resources and the MTP Preferred
Originating Codec is set to ALaw.
I think we are wasting alot of MTP resources converting from A to U. is there a
way to use a uniform codec in CUCM 8.5.
Many thanks
--
@bbas..
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/6d93d1f7/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 19 Nov 2012 15:17:30 +0000
From: Heimo Stieg <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] SIP-Trunk fallback to hunt pilot
Message-ID:
<af9076420b5d244696ff1643aed13d213924c...@amsprd0610mb373.eurprd06.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I have a SIP trunk to an operator software which is working as intended.
Currently there is no cluster possible, so if the server breaks, the call
operator isn't working anymore.
There is an Route-pattern to the operator. The only fallback mechanism I know
is to configure a second server, but would it be possible to call a hunt pilot
if the sip trunk goes down?
Kind Regards
Heimo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/414a8c9c/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 19 Nov 2012 23:19:06 +0800
From: Peng WAN <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] FXO port DID on H.323 VG
Message-ID:
<of3771a7eb.51bc698c-on48257abb.0051a760-48257abb.00542...@lvmh-fashion.com>
Content-Type: text/plain; charset="us-ascii"
Hi All
We have H.323 VG Cisco 2921 register on CUCM 7.1.3. And one site with 2*
Vic2-4FXO. Is there some way to config on the VG so each IPT is using it`s
own FXO port?
Like
Phone 1001 using port 0/0/0 and PSTN number 61111234 for call in and call
out.
Phone 1002 using port 0/0/2 and PSTN number 61111235 for call in and call
out.
For call in, we just config connection plar to the phone directly on each
voice port.
But how to match the outgoing calls?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/4b73a403/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 19 Nov 2012 15:44:26 +0000
From: abbas Wali <[email protected]>
To: Ryan Ratliff <[email protected]>
Cc: [email protected]
Subject: Re: [cisco-voip] Ulaw -Alaw and MTP resources
Message-ID:
<cafdhcp6a4swbn6fmc67t0b7sbn1q1aeh2dki-sgzk-yfp4g...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Ryan
when i do a show call active voice brief i get the below
13EC : 361450 15:40:32.381 UTC Mon Nov 19 2012.1 +0 pid:0 Originate
connecting
dur 00:01:13 tx:3639/582240 rx:3638/582080
IP 172.30.176.162:28630 SRTP: off rtt:0ms pl:71930/0ms lost:0/0/0
delay:55/55/65ms g711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
13EC : 361449 15:40:32.379 UTC Mon Nov 19 2012.2 +10 pid:0 Originate active
dur 00:01:13 tx:3638/611184 rx:3651/584160
Tele 0/0/0:15 (361449) [0/0/0.31] tx:73010/73010/0ms* g711ulaw* noise:-76
acom:2 i/0:-27/-57 dBm
does that mean its all ulaw?
and yes you are right we have checked that box for MTP req on the trunks.
this was to cover another issue with the lose of DTMF tones when we
upgraded from CM 7 to 8.5.
Thanks
On 19 November 2012 14:42, Ryan Ratliff <[email protected]> wrote:
> If you were actually transcoding one of those legs would be doing alaw and
> the other ulaw. What you see is two ulaw legs which means that your MTP is
> acting just like an MTP. I assume by enabling the SIP trunk for MTP you
> mean you've checked the "MTP Required" box? That box does just what it
> says it does, it forces an MTP for each call.
>
> You aren't wasting MTP resources for transcoding between alaw and ulaw,
> you are wasting them because you checked the box.
>
> I'd guess that you are actually using a uniform codec (look at the rtp
> streams on your mgcp gateway when a call is active and I'm sure you'll see
> they are ulaw there too) just not the codec you want.
>
> You've got two options for forcing ulaw vs alaw. The first is a custom
> codec preference list with 711ulaw at the bottom of the list (you can't
> disable codecs this way, just prioritize them). Look at System->Region
> Information->Audio Codec Preference List. The second option is to disable
> g.711 ulaw via the service parameter "G.711 mu-law Codec Enabled".
>
> You may need to upgrade to get one or both of those options.
>
> -Ryan
>
> On Nov 19, 2012, at 8:40 AM, abbas Wali <[email protected]> wrote:
>
> Hi all,
>
> just to clairfy, we have confirgured PCM Type to ALaw (as in UK) on the
> MGCP gateways but all calls received shows ULaw on the phones.
>
> I believe our MGCP gateway is transcoding them as below
>
> Gateway3#show voice dsp active
>
> DSP DSP DSPWARE CURR BOOT PAK
> TX/RX
> TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT
> PACK COUNT
> ==== === == ======== ========== ===== ======= === == ========= == =====
> ============
>
>
> ----------------------------FLEX VOICE CARD 0 -----------------------
> -------
> *DSP ACTIVE VOICE CHANNELS*
> DSP DSPWARE VOX DSP SIG DSP PAK
> TX/RX
> TYPE VERSION CODEC NUM CH TS VOICEPORT SLT NUM CH TS RST AI ABRT
> PACK COUNT
> ====== ========== ======== === == == ========= === === == == === == ====
> ============
> C5510 27.3.1 *g711ulaw* 001 01 29 0/0/0:15 000 002 12 29 0 0
> 0 13359/13680
> C5510 27.3.1 g711ulaw 001 02 31 0/0/0:15 000 002 14 31 0 0
> 0 3707/3816
>
> The SIP trunks are enalbed to use MTP resources and the MTP Preferred
> Originating Codec[image: Required Field] is set to ALaw.
>
> I think we are wasting alot of MTP resources converting from A to U. is
> there a way to use a uniform codec in CUCM 8.5.
>
> Many thanks
> --
> @bbas..
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/613ba4f9/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 19 Nov 2012 15:45:05 +0000
From: abbas Wali <[email protected]>
To: Ryan Ratliff <[email protected]>
Cc: [email protected]
Subject: Re: [cisco-voip] Ulaw -Alaw and MTP resources
Message-ID:
<CAFdHCp5Wp+1+A=b9fg65_hbcrwshfgtum1men6qfvs89bin...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks Ryan
when i do a show call active voice brief i get the below
13EC : 361450 15:40:32.381 UTC Mon Nov 19 2012.1 +0 pid:0 Originate
connecting
dur 00:01:13 tx:3639/582240 rx:3638/582080
IP 172.30.176.162:28630 SRTP: off rtt:0ms pl:71930/0ms lost:0/0/0
delay:55/55/65ms g711ulaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long duration call duration:n/a timestamp:n/a
13EC : 361449 15:40:32.379 UTC Mon Nov 19 2012.2 +10 pid:0 Originate active
dur 00:01:13 tx:3638/611184 rx:3651/584160
Tele 0/0/0:15 (361449) [0/0/0.31] tx:73010/73010/0ms* g711ulaw* noise:-76
acom:2 i/0:-27/-57 dBm
does that mean its all ulaw?
and yes you are right we have checked that box for MTP req on the trunks.
this was to cover another issue with the lose of DTMF tones when we
upgraded from CM 7 to 8.5.
Thanks
On 19 November 2012 14:42, Ryan Ratliff <[email protected]> wrote:
> If you were actually transcoding one of those legs would be doing alaw and
> the other ulaw. What you see is two ulaw legs which means that your MTP is
> acting just like an MTP. I assume by enabling the SIP trunk for MTP you
> mean you've checked the "MTP Required" box? That box does just what it
> says it does, it forces an MTP for each call.
>
> You aren't wasting MTP resources for transcoding between alaw and ulaw,
> you are wasting them because you checked the box.
>
> I'd guess that you are actually using a uniform codec (look at the rtp
> streams on your mgcp gateway when a call is active and I'm sure you'll see
> they are ulaw there too) just not the codec you want.
>
> You've got two options for forcing ulaw vs alaw. The first is a custom
> codec preference list with 711ulaw at the bottom of the list (you can't
> disable codecs this way, just prioritize them). Look at System->Region
> Information->Audio Codec Preference List. The second option is to disable
> g.711 ulaw via the service parameter "G.711 mu-law Codec Enabled".
>
> You may need to upgrade to get one or both of those options.
>
> -Ryan
>
> On Nov 19, 2012, at 8:40 AM, abbas Wali <[email protected]> wrote:
>
> Hi all,
>
> just to clairfy, we have confirgured PCM Type to ALaw (as in UK) on the
> MGCP gateways but all calls received shows ULaw on the phones.
>
> I believe our MGCP gateway is transcoding them as below
>
> Gateway3#show voice dsp active
>
> DSP DSP DSPWARE CURR BOOT PAK
> TX/RX
> TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT
> PACK COUNT
> ==== === == ======== ========== ===== ======= === == ========= == =====
> ============
>
>
> ----------------------------FLEX VOICE CARD 0 -----------------------
> -------
> *DSP ACTIVE VOICE CHANNELS*
> DSP DSPWARE VOX DSP SIG DSP PAK
> TX/RX
> TYPE VERSION CODEC NUM CH TS VOICEPORT SLT NUM CH TS RST AI ABRT
> PACK COUNT
> ====== ========== ======== === == == ========= === === == == === == ====
> ============
> C5510 27.3.1 *g711ulaw* 001 01 29 0/0/0:15 000 002 12 29 0 0
> 0 13359/13680
> C5510 27.3.1 g711ulaw 001 02 31 0/0/0:15 000 002 14 31 0 0
> 0 3707/3816
>
> The SIP trunks are enalbed to use MTP resources and the MTP Preferred
> Originating Codec[image: Required Field] is set to ALaw.
>
> I think we are wasting alot of MTP resources converting from A to U. is
> there a way to use a uniform codec in CUCM 8.5.
>
> Many thanks
> --
> @bbas..
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/53786378/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 19 Nov 2012 07:53:08 -0800
From: Scott Voll <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [cisco-voip] media resource exhausted
Message-ID:
<cahgd+3-hosmpng6yfgzd7xrmhlqzfnphewhhqyvo+jp8_9n...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
we just upgraded to 8.6.2.22900-9 and got our RTMT alerts working again.
we are now receiving media resource list exhausted messages. They show
they are coming from our NULL_LIST and I know that I have nothing in the
null list.
what I would like to know is, (1.) what device is trying to use the null
list? and (2.) what resource is it trying to use.
is there an easy way to figure that out?
TIA
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/0069b07e/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 19 Nov 2012 14:25:50 +0000
From: "Salisbury, Charles" <[email protected]>
To: Steven Sarte <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [cisco-voip] MeetingPlace 8.5 and WebEx
Message-ID:
<9f07c1969322db428f43055d7eb33b156e68b...@zvm204-maildb2.gentex.com>
Content-Type: text/plain; charset="us-ascii"
Yes - it will use whatever on premise phone lines you use, not the webex voice
network.
THE INFORMATION CONTAINED IN THIS E-MAIL MESSAGE AND ANY ATTACHMENTS SENT FROM
GENTEX CORPORATION IS GENTEX CONFIDENTIAL INFORMATION INTENDED ONLY FOR THE
PERSONAL USE OF THE INDIVIDUAL OR ENTITY NAMED ABOVE. If you are not the
intended recipient, you are hereby notified that any review, distribution, or
copying of this communication is strictly prohibited. If you have received this
communication in error, please immediately notify the sender by return e-mail,
and delete this e-mail message and any attachments from your computer.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Steven Sarte
Sent: Thursday, November 15, 2012 5:33 PM
To: [email protected]
Subject: [cisco-voip] MeetingPlace 8.5 and WebEx
Sorry for the stupid question but just want to confirm when you integrate
MeetigPlace 8.5 and WebEx together you use your own PRI's?
Is this statement correct?
Thanks
Steven
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
Message: 12
Date: Mon, 19 Nov 2012 16:14:06 +0000
From: abbas Wali <[email protected]>
To: Scott Voll <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [cisco-voip] media resource exhausted
Message-ID:
<cafdhcp72mko8d-+eh0gdwbjlksb5sjo9rctnj38zg0f6ab7...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
we do get these messages all the time as well.
though, it does point out to a particular node. One of the engineer from
Cisco advised we get these alerts when a single node in the MRGL gets
capacitated not the whole lot.
you can setup a logger on the RTMT sending all these figures from MTP to an
excel file. and check whenever you get the alert.
regards,
On 19 November 2012 15:53, Scott Voll <[email protected]> wrote:
> we just upgraded to 8.6.2.22900-9 and got our RTMT alerts working again.
> we are now receiving media resource list exhausted messages. They show
> they are coming from our NULL_LIST and I know that I have nothing in the
> null list.
>
> what I would like to know is, (1.) what device is trying to use the null
> list? and (2.) what resource is it trying to use.
>
> is there an easy way to figure that out?
>
> TIA
>
> Scott
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/d0e6020f/attachment-0001.html>
------------------------------
Message: 13
Date: Mon, 19 Nov 2012 11:18:28 -0500
From: Peter Slow <[email protected]>
To: abbas Wali <[email protected]>
Cc: [email protected]
Subject: Re: [cisco-voip] Ulaw -Alaw and MTP resources
Message-ID:
<cama5jw5wqva-qogrxefdkdacvtdtbn6v4h06aob0po8kttx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
it certainly looks like you're using Mu-law on that call leg. furthermore,
you stated that you are using an MGCP gateway.
What command did you use on the gateway that you were saying set it to
a-law?
I believe CUCM is solely responsible for instructing the MGCP GW as to the
voice codec to use, isnt it?
-Peter
On Mon, Nov 19, 2012 at 10:45 AM, abbas Wali <[email protected]> wrote:
> Thanks Ryan
>
> when i do a show call active voice brief i get the below
>
> 13EC : 361450 15:40:32.381 UTC Mon Nov 19 2012.1 +0 pid:0 Originate
> connecting
> dur 00:01:13 tx:3639/582240 rx:3638/582080
> IP 172.30.176.162:28630 SRTP: off rtt:0ms pl:71930/0ms lost:0/0/0
> delay:55/55/65ms g711ulaw TextRelay: off
> media inactive detected:n media contrl rcvd:n/a timestamp:n/a
> long duration call detected:n long duration call duration:n/a
> timestamp:n/a
>
> 13EC : 361449 15:40:32.379 UTC Mon Nov 19 2012.2 +10 pid:0 Originate
> active
> dur 00:01:13 tx:3638/611184 rx:3651/584160
> Tele 0/0/0:15 (361449) [0/0/0.31] tx:73010/73010/0ms* g711ulaw*noise:-76
> acom:2 i/0:-27/-57 dBm
>
> does that mean its all ulaw?
>
> and yes you are right we have checked that box for MTP req on the trunks.
> this was to cover another issue with the lose of DTMF tones when we
> upgraded from CM 7 to 8.5.
>
> Thanks
>
>
> On 19 November 2012 14:42, Ryan Ratliff <[email protected]> wrote:
>
>> If you were actually transcoding one of those legs would be doing alaw
>> and the other ulaw. What you see is two ulaw legs which means that your
>> MTP is acting just like an MTP. I assume by enabling the SIP trunk for MTP
>> you mean you've checked the "MTP Required" box? That box does just what it
>> says it does, it forces an MTP for each call.
>>
>> You aren't wasting MTP resources for transcoding between alaw and ulaw,
>> you are wasting them because you checked the box.
>>
>> I'd guess that you are actually using a uniform codec (look at the rtp
>> streams on your mgcp gateway when a call is active and I'm sure you'll see
>> they are ulaw there too) just not the codec you want.
>>
>> You've got two options for forcing ulaw vs alaw. The first is a custom
>> codec preference list with 711ulaw at the bottom of the list (you can't
>> disable codecs this way, just prioritize them). Look at System->Region
>> Information->Audio Codec Preference List. The second option is to disable
>> g.711 ulaw via the service parameter "G.711 mu-law Codec Enabled".
>>
>> You may need to upgrade to get one or both of those options.
>>
>> -Ryan
>>
>> On Nov 19, 2012, at 8:40 AM, abbas Wali <[email protected]> wrote:
>>
>> Hi all,
>>
>> just to clairfy, we have confirgured PCM Type to ALaw (as in UK) on the
>> MGCP gateways but all calls received shows ULaw on the phones.
>>
>> I believe our MGCP gateway is transcoding them as below
>>
>> Gateway3#show voice dsp active
>>
>> DSP DSP DSPWARE CURR BOOT
>> PAK TX/RX
>> TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT
>> PACK COUNT
>> ==== === == ======== ========== ===== ======= === == ========= == =====
>> ============
>>
>>
>> ----------------------------FLEX VOICE CARD 0 -----------------------
>> -------
>> *DSP ACTIVE VOICE CHANNELS*
>> DSP DSPWARE VOX DSP SIG DSP
>> PAK TX/RX
>> TYPE VERSION CODEC NUM CH TS VOICEPORT SLT NUM CH TS RST AI ABRT
>> PACK COUNT
>> ====== ========== ======== === == == ========= === === == == === == ====
>> ============
>> C5510 27.3.1 *g711ulaw* 001 01 29 0/0/0:15 000 002 12 29 0
>> 0 0 13359/13680
>> C5510 27.3.1 g711ulaw 001 02 31 0/0/0:15 000 002 14 31 0 0
>> 0 3707/3816
>>
>> The SIP trunks are enalbed to use MTP resources and the MTP Preferred
>> Originating Codec[image: Required Field] is set to ALaw.
>>
>> I think we are wasting alot of MTP resources converting from A to U. is
>> there a way to use a uniform codec in CUCM 8.5.
>>
>> Many thanks
>> --
>> @bbas..
>>
>> _______________________________________________
>> cisco-voip mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
> --
> @bbas..
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/3d48f731/attachment-0001.html>
------------------------------
Message: 14
Date: Mon, 19 Nov 2012 16:21:32 +0000
From: abbas Wali <[email protected]>
To: Peter Slow <[email protected]>
Cc: [email protected]
Subject: Re: [cisco-voip] Ulaw -Alaw and MTP resources
Message-ID:
<CAFdHCp4jJZGpCsn3JxrKT1nXPUcQKuHmbY=z8lyquuycgkk...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
its not a command on the IOS its only from the CUCM GUI for these gateways
which says PCM Type is set to ALaw.
I remeber changing these to Ulaw as well but things go horrible when tested
one card. May be coz of the geographical location of being in the UK you
must use PCM type of Alaw only??
Thanks
On 19 November 2012 16:18, Peter Slow <[email protected]> wrote:
> it certainly looks like you're using Mu-law on that call leg. furthermore,
> you stated that you are using an MGCP gateway.
>
> What command did you use on the gateway that you were saying set it to
> a-law?
>
> I believe CUCM is solely responsible for instructing the MGCP GW as to the
> voice codec to use, isnt it?
>
> -Peter
>
>
> On Mon, Nov 19, 2012 at 10:45 AM, abbas Wali <[email protected]> wrote:
>
>> Thanks Ryan
>>
>> when i do a show call active voice brief i get the below
>>
>> 13EC : 361450 15:40:32.381 UTC Mon Nov 19 2012.1 +0 pid:0 Originate
>> connecting
>> dur 00:01:13 tx:3639/582240 rx:3638/582080
>> IP 172.30.176.162:28630 SRTP: off rtt:0ms pl:71930/0ms lost:0/0/0
>> delay:55/55/65ms g711ulaw TextRelay: off
>> media inactive detected:n media contrl rcvd:n/a timestamp:n/a
>> long duration call detected:n long duration call duration:n/a
>> timestamp:n/a
>>
>> 13EC : 361449 15:40:32.379 UTC Mon Nov 19 2012.2 +10 pid:0 Originate
>> active
>> dur 00:01:13 tx:3638/611184 rx:3651/584160
>> Tele 0/0/0:15 (361449) [0/0/0.31] tx:73010/73010/0ms* g711ulaw*noise:-76
>> acom:2 i/0:-27/-57 dBm
>>
>> does that mean its all ulaw?
>>
>> and yes you are right we have checked that box for MTP req on the trunks.
>> this was to cover another issue with the lose of DTMF tones when we
>> upgraded from CM 7 to 8.5.
>>
>> Thanks
>>
>>
>> On 19 November 2012 14:42, Ryan Ratliff <[email protected]> wrote:
>>
>>> If you were actually transcoding one of those legs would be doing alaw
>>> and the other ulaw. What you see is two ulaw legs which means that your
>>> MTP is acting just like an MTP. I assume by enabling the SIP trunk for MTP
>>> you mean you've checked the "MTP Required" box? That box does just what it
>>> says it does, it forces an MTP for each call.
>>>
>>> You aren't wasting MTP resources for transcoding between alaw and ulaw,
>>> you are wasting them because you checked the box.
>>>
>>> I'd guess that you are actually using a uniform codec (look at the rtp
>>> streams on your mgcp gateway when a call is active and I'm sure you'll see
>>> they are ulaw there too) just not the codec you want.
>>>
>>> You've got two options for forcing ulaw vs alaw. The first is a custom
>>> codec preference list with 711ulaw at the bottom of the list (you can't
>>> disable codecs this way, just prioritize them). Look at System->Region
>>> Information->Audio Codec Preference List. The second option is to disable
>>> g.711 ulaw via the service parameter "G.711 mu-law Codec Enabled".
>>>
>>> You may need to upgrade to get one or both of those options.
>>>
>>> -Ryan
>>>
>>> On Nov 19, 2012, at 8:40 AM, abbas Wali <[email protected]> wrote:
>>>
>>> Hi all,
>>>
>>> just to clairfy, we have confirgured PCM Type to ALaw (as in UK) on the
>>> MGCP gateways but all calls received shows ULaw on the phones.
>>>
>>> I believe our MGCP gateway is transcoding them as below
>>>
>>> Gateway3#show voice dsp active
>>>
>>> DSP DSP DSPWARE CURR BOOT
>>> PAK TX/RX
>>> TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT
>>> PACK COUNT
>>> ==== === == ======== ========== ===== ======= === == ========= == =====
>>> ============
>>>
>>>
>>> ----------------------------FLEX VOICE CARD 0 -----------------------
>>> -------
>>> *DSP ACTIVE VOICE CHANNELS*
>>> DSP DSPWARE VOX DSP SIG DSP
>>> PAK TX/RX
>>> TYPE VERSION CODEC NUM CH TS VOICEPORT SLT NUM CH TS RST AI
>>> ABRT PACK COUNT
>>> ====== ========== ======== === == == ========= === === == == === ==
>>> ==== ============
>>> C5510 27.3.1 *g711ulaw* 001 01 29 0/0/0:15 000 002 12 29 0
>>> 0 0 13359/13680
>>> C5510 27.3.1 g711ulaw 001 02 31 0/0/0:15 000 002 14 31 0 0
>>> 0 3707/3816
>>>
>>> The SIP trunks are enalbed to use MTP resources and the MTP Preferred
>>> Originating Codec[image: Required Field] is set to ALaw.
>>>
>>> I think we are wasting alot of MTP resources converting from A to U. is
>>> there a way to use a uniform codec in CUCM 8.5.
>>>
>>> Many thanks
>>> --
>>> @bbas..
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> [email protected]
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>> --
>> @bbas..
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/381c53b6/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 19 Nov 2012 16:21:49 +0000
From: abbas Wali <[email protected]>
To: Peter Slow <[email protected]>
Cc: [email protected]
Subject: Re: [cisco-voip] Ulaw -Alaw and MTP resources
Message-ID:
<CAFdHCp4CYDp-JbWpjXLAi=psqcfcf9_jwgrwvstp8zymymp...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
its not a command on the IOS its only from the CUCM GUI for these gateways
which says PCM Type is set to ALaw.
I remeber changing these to Ulaw as well but things go horrible when tested
one card. May be coz of the geographical location of being in the UK you
must use PCM type of Alaw only??
Thanks
On 19 November 2012 16:18, Peter Slow <[email protected]> wrote:
> it certainly looks like you're using Mu-law on that call leg. furthermore,
> you stated that you are using an MGCP gateway.
>
> What command did you use on the gateway that you were saying set it to
> a-law?
>
> I believe CUCM is solely responsible for instructing the MGCP GW as to the
> voice codec to use, isnt it?
>
> -Peter
>
>
> On Mon, Nov 19, 2012 at 10:45 AM, abbas Wali <[email protected]> wrote:
>
>> Thanks Ryan
>>
>> when i do a show call active voice brief i get the below
>>
>> 13EC : 361450 15:40:32.381 UTC Mon Nov 19 2012.1 +0 pid:0 Originate
>> connecting
>> dur 00:01:13 tx:3639/582240 rx:3638/582080
>> IP 172.30.176.162:28630 SRTP: off rtt:0ms pl:71930/0ms lost:0/0/0
>> delay:55/55/65ms g711ulaw TextRelay: off
>> media inactive detected:n media contrl rcvd:n/a timestamp:n/a
>> long duration call detected:n long duration call duration:n/a
>> timestamp:n/a
>>
>> 13EC : 361449 15:40:32.379 UTC Mon Nov 19 2012.2 +10 pid:0 Originate
>> active
>> dur 00:01:13 tx:3638/611184 rx:3651/584160
>> Tele 0/0/0:15 (361449) [0/0/0.31] tx:73010/73010/0ms* g711ulaw*noise:-76
>> acom:2 i/0:-27/-57 dBm
>>
>> does that mean its all ulaw?
>>
>> and yes you are right we have checked that box for MTP req on the trunks.
>> this was to cover another issue with the lose of DTMF tones when we
>> upgraded from CM 7 to 8.5.
>>
>> Thanks
>>
>>
>> On 19 November 2012 14:42, Ryan Ratliff <[email protected]> wrote:
>>
>>> If you were actually transcoding one of those legs would be doing alaw
>>> and the other ulaw. What you see is two ulaw legs which means that your
>>> MTP is acting just like an MTP. I assume by enabling the SIP trunk for MTP
>>> you mean you've checked the "MTP Required" box? That box does just what it
>>> says it does, it forces an MTP for each call.
>>>
>>> You aren't wasting MTP resources for transcoding between alaw and ulaw,
>>> you are wasting them because you checked the box.
>>>
>>> I'd guess that you are actually using a uniform codec (look at the rtp
>>> streams on your mgcp gateway when a call is active and I'm sure you'll see
>>> they are ulaw there too) just not the codec you want.
>>>
>>> You've got two options for forcing ulaw vs alaw. The first is a custom
>>> codec preference list with 711ulaw at the bottom of the list (you can't
>>> disable codecs this way, just prioritize them). Look at System->Region
>>> Information->Audio Codec Preference List. The second option is to disable
>>> g.711 ulaw via the service parameter "G.711 mu-law Codec Enabled".
>>>
>>> You may need to upgrade to get one or both of those options.
>>>
>>> -Ryan
>>>
>>> On Nov 19, 2012, at 8:40 AM, abbas Wali <[email protected]> wrote:
>>>
>>> Hi all,
>>>
>>> just to clairfy, we have confirgured PCM Type to ALaw (as in UK) on the
>>> MGCP gateways but all calls received shows ULaw on the phones.
>>>
>>> I believe our MGCP gateway is transcoding them as below
>>>
>>> Gateway3#show voice dsp active
>>>
>>> DSP DSP DSPWARE CURR BOOT
>>> PAK TX/RX
>>> TYPE NUM CH CODEC VERSION STATE STATE RST AI VOICEPORT TS ABORT
>>> PACK COUNT
>>> ==== === == ======== ========== ===== ======= === == ========= == =====
>>> ============
>>>
>>>
>>> ----------------------------FLEX VOICE CARD 0 -----------------------
>>> -------
>>> *DSP ACTIVE VOICE CHANNELS*
>>> DSP DSPWARE VOX DSP SIG DSP
>>> PAK TX/RX
>>> TYPE VERSION CODEC NUM CH TS VOICEPORT SLT NUM CH TS RST AI
>>> ABRT PACK COUNT
>>> ====== ========== ======== === == == ========= === === == == === ==
>>> ==== ============
>>> C5510 27.3.1 *g711ulaw* 001 01 29 0/0/0:15 000 002 12 29 0
>>> 0 0 13359/13680
>>> C5510 27.3.1 g711ulaw 001 02 31 0/0/0:15 000 002 14 31 0 0
>>> 0 3707/3816
>>>
>>> The SIP trunks are enalbed to use MTP resources and the MTP Preferred
>>> Originating Codec[image: Required Field] is set to ALaw.
>>>
>>> I think we are wasting alot of MTP resources converting from A to U. is
>>> there a way to use a uniform codec in CUCM 8.5.
>>>
>>> Many thanks
>>> --
>>> @bbas..
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> [email protected]
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>> --
>> @bbas..
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
--
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/3f14d82f/attachment-0001.html>
------------------------------
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
End of cisco-voip Digest, Vol 109, Issue 16
*******************************************
