<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Thanks for confirming this Wes. I had my fingers crossed, but
had a feeling it was inbound only.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>We don't have a problem with sending out the main number, we
do so with route patterns (we have two main numbers depending on the user) - it
works fine. The only problem is that in Canada, things are done a little
differently (from what we've been told) and Canada doesn't do the SS7 look up
and sends the name along with the call. So for calls within Canada, we have
<STRONG>no</STRONG> name attached to our outbound calls with no option to enable
it.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>What's worse, is that it seems your allowed to register a
business name with the same number more than once. As a result the SS7
database look up is no longer accurate/consistent. We had a few franchises add
their name to our local phone book listing and use our main number. Now when we
call into the states, our calls sometimes come up as "Harvey's" as opposed to
"University of Guelph". We haven't had any reports of this for a while, so I'm
not sure what's happened, but if it happens again, we'll have to consider asking
all organizations on campus to advertise only a DID number and not our main
number.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Any idea how long it takes for the database updates to take
place?</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=wsisk@cisco.com href="mailto:wsisk@cisco.com">Wes Sisk</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=lelio@uoguelph.ca
href="mailto:lelio@uoguelph.ca">Lelio Fulgenzi</A> ; <A
title=cisco-voip@puck.nether.net
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, July 26, 2004 9:57 AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: [cisco-voip] Unknown
CallerID System Parameters</DIV>
<DIV><BR></DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2>Lelio,</FONT></SPAN></DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2>UnknownCallerId - this is when a call arrives inbound to CM without any
calling party name or number (inbound through an MGCP FXO or through a t1-cas
link), what number should be displayed on the ipphone. the other
Unknown* params address this same situation.</FONT></SPAN></DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2>UserUserIEStatus - I have never seen callerID information passed in
user-user IE. This is typically for vendor extensions such as how CM instructs
h323 gateways to provide ringback tone during a transfer.</FONT></SPAN></DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff size=2>You
can use the "<FONT face="Times New Roman" color=#000000 size=3>Caller ID DN"
field on the gateway configuration page overwrite the calling pary number on
outbound calls. Using this parameter will cause the calling party name
to be blanked out. </FONT></FONT></SPAN></DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff size=2>When
the call is routed over the PSTN, the final PSTN switch before hopoff to
the destination CPE will perform a name lookup via the SS7 cloud on the
calling party number to determine what calling party name to send to the
destination CPE. If you choose your "main number" and register it with
your telco in the ss7 name database, then when you use the "caller id dn"
field on the gateway to overwrite calling party name with your "main number"
all PSTN destinations should receive the correct calling party
name.</FONT></SPAN></DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff size=2>As
far as overwriting calling party name when we're just connected CCM---PBX,
well, I haven't found a way to do that yet.</FONT></SPAN></DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=520323313-26072004><FONT face=Arial color=#0000ff
size=2>/Wes</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B>
cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net]<B>On Behalf Of </B>Lelio
Fulgenzi<BR><B>Sent:</B> Thursday, July 22, 2004 6:52 PM<BR><B>To:</B>
cisco-voip@puck.nether.net<BR><B>Subject:</B> [cisco-voip] Unknown CallerID
System Parameters<BR><BR></FONT></DIV>
<DIV><FONT face=Arial size=2>Just wondering if anyone has successfully used
the following system parameters for
manipulating <STRONG>outbound</STRONG> callerID information. The
description is not all to clear to me, and I'm not sure if these
parameters modify the unknown callerID information that leaves the call
manager out to our PSTN trunks, or the other way around. Currently,
our PSTN service (Bell Canada Megalink PRI DMS-100) does not support
service level text entry, and opening a case with the TAC said the only
way we could get this working would be to enable the display of the
individual line's caller information field, but then were told this is not
compatible with DMS-100, either way, it's not what we want. We'd like to get
all calls to display one name to outbound calls, i.e. "University of
Guelph". I came across this in the forums and am hoping this will do
what we want.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><STRONG>UnknownCallerId: </STRONG></FONT><FONT
face=Arial size=2>The directory number to be displayed. Valid value is any
numeric value representing a general number for your system (if you wish to
provide caller ID functionality to called parties). Valid value is any valid
telephone number.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2><STRONG></STRONG></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2><STRONG>UnknownCallerIdFlag:</STRONG>
This parameter is related to the Unknown CallerId field. We strongly
recommend using the default setting since this can now be configured using
Cisco CallManager Administration. <U><EM>Default:
T</EM> <BR></U></FONT></DIV>
<DIV dir=ltr><FONT face=Arial
size=2><STRONG>UnknownCallerIdText:</STRONG> The text to be displayed
to called parties having caller ID capability. The first line is 20
characters and the second line is 14 characters. Try to get a saying which
looks OK in the display when broken into two lines having the specified
number of characters per line. <EM><U>Default: Unknown</U></EM></FONT></DIV>
<DIV dir=ltr><FONT face=Arial
size=2><EM></EM><EM></EM><EM></EM><BR><STRONG>UserUserIEStatus:</STRONG>
If the user to user information element (UUIE) is passed in the system,
enabling UUIE status allows ISDN PRI messages to include them outbound PRI
calls. <EM><U>Default: F<BR></U></EM> <BR></DIV></FONT>
<DIV>-----
-----<BR>Lelio Fulgenzi,
B.A.
<A href="mailto:lelio@uoguelph.ca.eh">lelio@uoguelph.ca.eh</A><BR>Network
Analyst (CCS)<BR>University of
Guelph
FAX:(519) 767-1060 JNHN<BR>Guelph, Ontario N1G
2W1
TEL:(519) 824-4120
x56354<BR>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<BR>
remove the 1st letter of the canadian alphabet from my email, eh!</DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=wsisk@cisco.com href="mailto:wsisk@cisco.com">Wes Sisk</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
title=vandy.hamidi@markettools.com
href="mailto:vandy.hamidi@markettools.com">Vandy Hamidi</A> ; <A
title=cisco-voip@puck.nether.net
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, July 22, 2004 5:52
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: [cisco-voip] Weird
Conference Voice Quality</DIV>
<DIV><BR></DIV>Vandy,<BR><BR>This looks mostly correct - just a cpl
questions-<BR><BR>Can we see the rest of the config for the route-map on
the FastE<BR>"ip policy route-map SET-IP-QOS" This may be re-marking
your VOIP traffic<BR>so it does not match your outbound QOS policy, which
identifies VOIP bearer<BR>traffic based on:<BR><BR>ip access-list extended
VOIP-Classify-Voice<BR> permit ip any any precedence
critical<BR> permit ip any any dscp ef<BR><BR><BR>Also, your
QOS-POLICY appears to allocate 650kbps, this ususally should only<BR>be
75% of available bw, so do your links offer 650/0.75= 866kbps at
least?<BR><BR>This is discussed in the QOS srnd at <A
href="http://www.cisco.com/go/srnd">http://www.cisco.com/go/srnd</A> if
you'd<BR>like to read more.<BR><BR>/Wes<BR><BR><BR><BR>> -----Original
Message-----<BR>> From: Vandy Hamidi
[mailto:vandy.hamidi@markettools.com]<BR>> Sent: Thursday, July 22,
2004 5:27 PM<BR>> To: Wes Sisk; <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>
Subject: RE: [cisco-voip] Weird Conference Voice
Quality<BR>><BR>><BR>> Thanks Wes, that explains a lot and
confirms a hunch I had. It looks<BR>> like the 6608 waiting for a
jittery stream will cause choppiness for all<BR>> participants.
That's a real great design...<BR>><BR>> Because conference voice
quality is always GOOD when data isn't<BR>> competing, the QOS
classifying and policing must not be setup right. We<BR>> had
outside consultants install our base system and I've been using<BR>>
their QOS to stamp out other remote sites.<BR>> Something must be
misconfigured.<BR>><BR>> Can anyone just give it a once over.
I cut and paste just the pertinent<BR>> parts of my 2651XM config
below.<BR>><BR>> If anyone could email me their QOS setup, I would
be extremely grateful.<BR>> This problem is high priority and high
visibility and I've be very<BR>> thankful.<BR>> Thank you in
advanced,<BR>><BR>> -=Vandy-=<BR>><BR>> class-map match-all
VOIP-VOICE_CONTROL<BR>> match access-group name
VOIP-Classify-Control<BR>> class-map match-all VOIP-VOICE<BR>>
match access-group name VOIP-Classify-Voice<BR>> !<BR>>
!<BR>> policy-map QOS-POLICY<BR>> class VOIP-VOICE<BR>>
priority 600<BR>> class VOIP-VOICE_CONTROL<BR>>
bandwidth 50<BR>> class class-default<BR>>
fair-queue<BR>> !<BR>> interface Multilink1<BR>>
description Market Tools PL431562<BR>> ip address 172.16.16.70
255.255.255.252<BR>> service-policy output QOS-POLICY<BR>>
load-interval 30<BR>> no peer neighbor-route<BR>> no cdp
enable<BR>> ppp multilink<BR>> ppp multilink fragment delay
20<BR>> ppp multilink interleave<BR>> ppp multilink group 1<BR>>
!<BR>> interface FastEthernet0/0<BR>> description User/Server
VLAN<BR>> encapsulation dot1Q 1 native<BR>> ip address 10.21.0.1
255.255.255.0<BR>> ip policy route-map SET-IP-QOS<BR>> !<BR>>
interface FastEthernet0/1<BR>> description VOIP Phone VLAN<BR>>
encapsulation dot1Q 4<BR>> ip address 10.21.4.1 255.255.252.0<BR>>
ip policy route-map SET-IP-QOS<BR>> !<BR>> ip access-list extended
VOIP-Classify-Control<BR>> permit ip any any precedence flash<BR>>
permit ip any any dscp af31<BR>> ip access-list extended
VOIP-Classify-Voice<BR>> permit ip any any precedence critical<BR>>
permit ip any any dscp ef<BR>> ip access-list extended
VOIP-Control<BR>> permit tcp any any range 2000 2002<BR>> permit tcp
any any eq 1720<BR>> permit tcp any any range 11000 11999<BR>>
permit udp any any eq 2427<BR>> ip access-list extended
VOIP-Routine<BR>> permit ip any any<BR>> ip access-list extended
VOIP-Voice<BR>> permit udp any any range 16384
32767<BR>><BR>><BR>> -----Original Message-----<BR>> From: Wes
Sisk [mailto:wsisk@cisco.com]<BR>> Sent: Thursday, July 22, 2004 6:07
AM<BR>> To: Vandy Hamidi; <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>
Subject: RE: [cisco-voip] Weird Conference Voice Quality<BR>><BR>>
Vandy,<BR>><BR>> If audio coming from the source device to the
conference device has<BR>> large,<BR>> irregular jitter, then
everyone listening to the conference will be<BR>>
affected.<BR>><BR>> Simple way to test this out:<BR>> setup
conference with remote users and 1 central user.<BR>> have all remote
users go on "mute" (no RTP stream generated on mute)<BR>> have central
user speak.<BR>> How is voice quality?<BR>><BR>> Now, have
everyone except 1 remote user go on mute.<BR>> How is voice
quality?<BR>><BR>> We need to make sure those streams coming from
the remote sites are<BR>> "good"<BR>> with very low jitter as the
6608 uses a static dejitter buffer in<BR>> contrast<BR>> with most
ipphones and gateways which use dynamic jitter buffers. This<BR>>
makes fragmentation critical on the WAN links.<BR>><BR>> CSCdx78486
6608 configured as CFB has a static jitter buffer, needs<BR>>
adaptive<BR>> Problem Description: Voice quality suffers with
choppiness when<BR>> conference<BR>> particants are located across
low speed links and the device providing<BR>> for<BR>> conferencing
is the 6608.<BR>><BR>> Workaround: None<BR>><BR>>
/Wes<BR>><BR>> > -----Original Message-----<BR>> > From: <A
href="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A><BR>>
> [mailto:cisco-voip-bounces@puck.nether.net]On Behalf Of Vandy
Hamidi<BR>> > Sent: Wednesday, July 21, 2004 11:30 PM<BR>> >
To: <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>
> Subject: [cisco-voip] Weird Conference Voice Quality<BR>>
><BR>> ><BR>> > Hey guys,<BR>> > I'm having a weird
problem that isn't making sense<BR>> ><BR>> > I have a 6608-T1
blade in my main office performing conferencing for<BR>> > most of
the remote offices in the company. I know, not recommended,<BR>>
but<BR>> > read on.<BR>> ><BR>> > All the offices are
connected Hub/Spoke to the main office and I have<BR>> > QOS setup
(supposedly correctly) on my wan links and call quality is<BR>> >
great. I've tested the QOS by maxing out the line during voice
calls.<BR>> ><BR>> > We've been receiving user complaints of
voice quality problems.<BR>> Cutting<BR>> > out, delays, overall
chopping communication. All these complaints are<BR>> > when
they are on conference calls.<BR>> ><BR>> > We've performed
testing and during high wan usage the conference call<BR>> > quality
becomes horrible to/from the remote sites and sometimes for<BR>>
all<BR>> > users for example I'll have a hard time understanding a
conference<BR>> > attendee in my own office.<BR>> > We're able
to reproduce with windows copies during conference calls.<BR>>
><BR>> > 1) Why is the voice quality ok with phone to phone
calls, but become<BR>> > horrible during a conference call.<BR>>
> 2) Does the 6608-T1 blade change/alter the QOS/TOS bits on
the<BR>> packets?<BR>> > 3) Why would this issue affect local
attendee conference quality when<BR>> > everyone is connected to the
same switch where the 6608 blade is.<BR>> ><BR>> >
TIA,<BR>> ><BR>> > -=Vandy=-<BR>> ><BR>> ><BR>>
> _______________________________________________<BR>> >
cisco-voip mailing list<BR>> > <A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>
> <A
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>><BR><BR>_______________________________________________<BR>cisco-voip
mailing list<BR><A
href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A
href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>