Mailing List Archive

Lelio,

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.

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.

You can use the "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.

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.

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.

/Wes
-----Original Message-----
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net]On Behalf Of Lelio Fulgenzi
Sent: Thursday, July 22, 2004 6:52 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Unknown CallerID System Parameters


Just wondering if anyone has successfully used the following system
parameters for manipulating outbound 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.

UnknownCallerId: 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.

UnknownCallerIdFlag: 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. Default: T

UnknownCallerIdText: 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. Default:
Unknown

UserUserIEStatus: 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. Default: F


----- -----
Lelio Fulgenzi, B.A. lelio@uoguelph.ca.eh
Network Analyst (CCS)
University of Guelph FAX:(519) 767-1060 JNHN
Guelph, Ontario N1G 2W1 TEL:(519) 824-4120 x56354
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
remove the 1st letter of the canadian alphabet from my email, eh!
----- Original Message -----
From: Wes Sisk
To: Vandy Hamidi ; cisco-voip@puck.nether.net
Sent: Thursday, July 22, 2004 5:52 PM
Subject: RE: [cisco-voip] Weird Conference Voice Quality


Vandy,

This looks mostly correct - just a cpl questions-

Can we see the rest of the config for the route-map on the FastE
"ip policy route-map SET-IP-QOS" This may be re-marking your VOIP
traffic
so it does not match your outbound QOS policy, which identifies VOIP
bearer
traffic based on:

ip access-list extended VOIP-Classify-Voice
permit ip any any precedence critical
permit ip any any dscp ef


Also, your QOS-POLICY appears to allocate 650kbps, this ususally should
only
be 75% of available bw, so do your links offer 650/0.75= 866kbps at
least?

This is discussed in the QOS srnd at http://www.cisco.com/go/srnd if
you'd
like to read more.

/Wes



> -----Original Message-----
> From: Vandy Hamidi [mailto:vandy.hamidi@markettools.com]
> Sent: Thursday, July 22, 2004 5:27 PM
> To: Wes Sisk; cisco-voip@puck.nether.net
> Subject: RE: [cisco-voip] Weird Conference Voice Quality
>
>
> Thanks Wes, that explains a lot and confirms a hunch I had. It looks
> like the 6608 waiting for a jittery stream will cause choppiness for
all
> participants. That's a real great design...
>
> Because conference voice quality is always GOOD when data isn't
> competing, the QOS classifying and policing must not be setup right.
We
> had outside consultants install our base system and I've been using
> their QOS to stamp out other remote sites.
> Something must be misconfigured.
>
> Can anyone just give it a once over. I cut and paste just the
pertinent
> parts of my 2651XM config below.
>
> If anyone could email me their QOS setup, I would be extremely
grateful.
> This problem is high priority and high visibility and I've be very
> thankful.
> Thank you in advanced,
>
> -=Vandy-=
>
> class-map match-all VOIP-VOICE_CONTROL
> match access-group name VOIP-Classify-Control
> class-map match-all VOIP-VOICE
> match access-group name VOIP-Classify-Voice
> !
> !
> policy-map QOS-POLICY
> class VOIP-VOICE
> priority 600
> class VOIP-VOICE_CONTROL
> bandwidth 50
> class class-default
> fair-queue
> !
> interface Multilink1
> description Market Tools PL431562
> ip address 172.16.16.70 255.255.255.252
> service-policy output QOS-POLICY
> load-interval 30
> no peer neighbor-route
> no cdp enable
> ppp multilink
> ppp multilink fragment delay 20
> ppp multilink interleave
> ppp multilink group 1
> !
> interface FastEthernet0/0
> description User/Server VLAN
> encapsulation dot1Q 1 native
> ip address 10.21.0.1 255.255.255.0
> ip policy route-map SET-IP-QOS
> !
> interface FastEthernet0/1
> description VOIP Phone VLAN
> encapsulation dot1Q 4
> ip address 10.21.4.1 255.255.252.0
> ip policy route-map SET-IP-QOS
> !
> ip access-list extended VOIP-Classify-Control
> permit ip any any precedence flash
> permit ip any any dscp af31
> ip access-list extended VOIP-Classify-Voice
> permit ip any any precedence critical
> permit ip any any dscp ef
> ip access-list extended VOIP-Control
> permit tcp any any range 2000 2002
> permit tcp any any eq 1720
> permit tcp any any range 11000 11999
> permit udp any any eq 2427
> ip access-list extended VOIP-Routine
> permit ip any any
> ip access-list extended VOIP-Voice
> permit udp any any range 16384 32767
>
>
> -----Original Message-----
> From: Wes Sisk [mailto:wsisk@cisco.com]
> Sent: Thursday, July 22, 2004 6:07 AM
> To: Vandy Hamidi; cisco-voip@puck.nether.net
> Subject: RE: [cisco-voip] Weird Conference Voice Quality
>
> Vandy,
>
> If audio coming from the source device to the conference device has
> large,
> irregular jitter, then everyone listening to the conference will be
> affected.
>
> Simple way to test this out:
> setup conference with remote users and 1 central user.
> have all remote users go on "mute" (no RTP stream generated on mute)
> have central user speak.
> How is voice quality?
>
> Now, have everyone except 1 remote user go on mute.
> How is voice quality?
>
> We need to make sure those streams coming from the remote sites are
> "good"
> with very low jitter as the 6608 uses a static dejitter buffer in
> contrast
> with most ipphones and gateways which use dynamic jitter buffers.
This
> makes fragmentation critical on the WAN links.
>
> CSCdx78486 6608 configured as CFB has a static jitter buffer, needs
> adaptive
> Problem Description: Voice quality suffers with choppiness when
> conference
> particants are located across low speed links and the device providing
> for
> conferencing is the 6608.
>
> Workaround: None
>
> /Wes
>
> > -----Original Message-----
> > From: cisco-voip-bounces@puck.nether.net
> > [mailto:cisco-voip-bounces@puck.nether.net]On Behalf Of Vandy Hamidi
> > Sent: Wednesday, July 21, 2004 11:30 PM
> > To: cisco-voip@puck.nether.net
> > Subject: [cisco-voip] Weird Conference Voice Quality
> >
> >
> > Hey guys,
> > I'm having a weird problem that isn't making sense
> >
> > I have a 6608-T1 blade in my main office performing conferencing for
> > most of the remote offices in the company. I know, not recommended,
> but
> > read on.
> >
> > All the offices are connected Hub/Spoke to the main office and I
have
> > QOS setup (supposedly correctly) on my wan links and call quality is
> > great. I've tested the QOS by maxing out the line during voice
calls.
> >
> > We've been receiving user complaints of voice quality problems.
> Cutting
> > out, delays, overall chopping communication. All these complaints
are
> > when they are on conference calls.
> >
> > We've performed testing and during high wan usage the conference
call
> > quality becomes horrible to/from the remote sites and sometimes for
> all
> > users for example I'll have a hard time understanding a conference
> > attendee in my own office.
> > We're able to reproduce with windows copies during conference calls.
> >
> > 1) Why is the voice quality ok with phone to phone calls, but become
> > horrible during a conference call.
> > 2) Does the 6608-T1 blade change/alter the QOS/TOS bits on the
> packets?
> > 3) Why would this issue affect local attendee conference quality
when
> > everyone is connected to the same switch where the 6608 blade is.
> >
> > TIA,
> >
> > -=Vandy=-
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Thanks for confirming this Wes. I had my fingers crossed, but had a feeling it was inbound only.

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 no name attached to our outbound calls with no option to enable it.

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.

Any idea how long it takes for the database updates to take place?

----- Original Message -----
From: Wes Sisk
To: Lelio Fulgenzi ; cisco-voip@puck.nether.net
Sent: Monday, July 26, 2004 9:57 AM
Subject: RE: [cisco-voip] Unknown CallerID System Parameters


Lelio,

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.

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.

You can use the "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.

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.

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.

/Wes
-----Original Message-----
From: cisco-voip-bounces@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net]On Behalf Of Lelio Fulgenzi
Sent: Thursday, July 22, 2004 6:52 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Unknown CallerID System Parameters


Just wondering if anyone has successfully used the following system parameters for manipulating outbound 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.

UnknownCallerId: 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.

UnknownCallerIdFlag: 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. Default: T

UnknownCallerIdText: 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. Default: Unknown

UserUserIEStatus: 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. Default: F


----- -----
Lelio Fulgenzi, B.A. lelio@uoguelph.ca.eh
Network Analyst (CCS)
University of Guelph FAX:(519) 767-1060 JNHN
Guelph, Ontario N1G 2W1 TEL:(519) 824-4120 x56354
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
remove the 1st letter of the canadian alphabet from my email, eh!
----- Original Message -----
From: Wes Sisk
To: Vandy Hamidi ; cisco-voip@puck.nether.net
Sent: Thursday, July 22, 2004 5:52 PM
Subject: RE: [cisco-voip] Weird Conference Voice Quality


Vandy,

This looks mostly correct - just a cpl questions-

Can we see the rest of the config for the route-map on the FastE
"ip policy route-map SET-IP-QOS" This may be re-marking your VOIP traffic
so it does not match your outbound QOS policy, which identifies VOIP bearer
traffic based on:

ip access-list extended VOIP-Classify-Voice
permit ip any any precedence critical
permit ip any any dscp ef


Also, your QOS-POLICY appears to allocate 650kbps, this ususally should only
be 75% of available bw, so do your links offer 650/0.75= 866kbps at least?

This is discussed in the QOS srnd at http://www.cisco.com/go/srnd if you'd
like to read more.

/Wes



> -----Original Message-----
> From: Vandy Hamidi [mailto:vandy.hamidi@markettools.com]
> Sent: Thursday, July 22, 2004 5:27 PM
> To: Wes Sisk; cisco-voip@puck.nether.net
> Subject: RE: [cisco-voip] Weird Conference Voice Quality
>
>
> Thanks Wes, that explains a lot and confirms a hunch I had. It looks
> like the 6608 waiting for a jittery stream will cause choppiness for all
> participants. That's a real great design...
>
> Because conference voice quality is always GOOD when data isn't
> competing, the QOS classifying and policing must not be setup right. We
> had outside consultants install our base system and I've been using
> their QOS to stamp out other remote sites.
> Something must be misconfigured.
>
> Can anyone just give it a once over. I cut and paste just the pertinent
> parts of my 2651XM config below.
>
> If anyone could email me their QOS setup, I would be extremely grateful.
> This problem is high priority and high visibility and I've be very
> thankful.
> Thank you in advanced,
>
> -=Vandy-=
>
> class-map match-all VOIP-VOICE_CONTROL
> match access-group name VOIP-Classify-Control
> class-map match-all VOIP-VOICE
> match access-group name VOIP-Classify-Voice
> !
> !
> policy-map QOS-POLICY
> class VOIP-VOICE
> priority 600
> class VOIP-VOICE_CONTROL
> bandwidth 50
> class class-default
> fair-queue
> !
> interface Multilink1
> description Market Tools PL431562
> ip address 172.16.16.70 255.255.255.252
> service-policy output QOS-POLICY
> load-interval 30
> no peer neighbor-route
> no cdp enable
> ppp multilink
> ppp multilink fragment delay 20
> ppp multilink interleave
> ppp multilink group 1
> !
> interface FastEthernet0/0
> description User/Server VLAN
> encapsulation dot1Q 1 native
> ip address 10.21.0.1 255.255.255.0
> ip policy route-map SET-IP-QOS
> !
> interface FastEthernet0/1
> description VOIP Phone VLAN
> encapsulation dot1Q 4
> ip address 10.21.4.1 255.255.252.0
> ip policy route-map SET-IP-QOS
> !
> ip access-list extended VOIP-Classify-Control
> permit ip any any precedence flash
> permit ip any any dscp af31
> ip access-list extended VOIP-Classify-Voice
> permit ip any any precedence critical
> permit ip any any dscp ef
> ip access-list extended VOIP-Control
> permit tcp any any range 2000 2002
> permit tcp any any eq 1720
> permit tcp any any range 11000 11999
> permit udp any any eq 2427
> ip access-list extended VOIP-Routine
> permit ip any any
> ip access-list extended VOIP-Voice
> permit udp any any range 16384 32767
>
>
> -----Original Message-----
> From: Wes Sisk [mailto:wsisk@cisco.com]
> Sent: Thursday, July 22, 2004 6:07 AM
> To: Vandy Hamidi; cisco-voip@puck.nether.net
> Subject: RE: [cisco-voip] Weird Conference Voice Quality
>
> Vandy,
>
> If audio coming from the source device to the conference device has
> large,
> irregular jitter, then everyone listening to the conference will be
> affected.
>
> Simple way to test this out:
> setup conference with remote users and 1 central user.
> have all remote users go on "mute" (no RTP stream generated on mute)
> have central user speak.
> How is voice quality?
>
> Now, have everyone except 1 remote user go on mute.
> How is voice quality?
>
> We need to make sure those streams coming from the remote sites are
> "good"
> with very low jitter as the 6608 uses a static dejitter buffer in
> contrast
> with most ipphones and gateways which use dynamic jitter buffers. This
> makes fragmentation critical on the WAN links.
>
> CSCdx78486 6608 configured as CFB has a static jitter buffer, needs
> adaptive
> Problem Description: Voice quality suffers with choppiness when
> conference
> particants are located across low speed links and the device providing
> for
> conferencing is the 6608.
>
> Workaround: None
>
> /Wes
>
> > -----Original Message-----
> > From: cisco-voip-bounces@puck.nether.net
> > [mailto:cisco-voip-bounces@puck.nether.net]On Behalf Of Vandy Hamidi
> > Sent: Wednesday, July 21, 2004 11:30 PM
> > To: cisco-voip@puck.nether.net
> > Subject: [cisco-voip] Weird Conference Voice Quality
> >
> >
> > Hey guys,
> > I'm having a weird problem that isn't making sense
> >
> > I have a 6608-T1 blade in my main office performing conferencing for
> > most of the remote offices in the company. I know, not recommended,
> but
> > read on.
> >
> > All the offices are connected Hub/Spoke to the main office and I have
> > QOS setup (supposedly correctly) on my wan links and call quality is
> > great. I've tested the QOS by maxing out the line during voice calls.
> >
> > We've been receiving user complaints of voice quality problems.
> Cutting
> > out, delays, overall chopping communication. All these complaints are
> > when they are on conference calls.
> >
> > We've performed testing and during high wan usage the conference call
> > quality becomes horrible to/from the remote sites and sometimes for
> all
> > users for example I'll have a hard time understanding a conference
> > attendee in my own office.
> > We're able to reproduce with windows copies during conference calls.
> >
> > 1) Why is the voice quality ok with phone to phone calls, but become
> > horrible during a conference call.
> > 2) Does the 6608-T1 blade change/alter the QOS/TOS bits on the
> packets?
> > 3) Why would this issue affect local attendee conference quality when
> > everyone is connected to the same switch where the 6608 blade is.
> >
> > TIA,
> >
> > -=Vandy=-
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip