http://forum.bandwidth.com/ Thu, 28 Aug 2008 14:44:24 +0000 MyBB http://forum.bandwidth.com/showthread.php?tid=98 Thu, 17 Apr 2008 18:23:36 +0000 http://forum.bandwidth.com/showthread.php?tid=98 http://forum.bandwidth.com/showthread.php?tid=97 Wed, 19 Mar 2008 14:35:17 +0000 http://forum.bandwidth.com/showthread.php?tid=97 http://forum.bandwidth.com/showthread.php?tid=74 Mon, 07 Jan 2008 22:15:39 +0000 http://forum.bandwidth.com/showthread.php?tid=74
Note: Compatible with SIP Protocol ONLY will NOT work with MGCP

911 Redirect will work with SIP phones or Analog phones that are connected directly to one of the EdgeMarc's FXS ports.[/b]

If you are a Bandwidth.com customer please contact Bandwidth.com support if you are having any issues at 800-808-5150 or customercare@bandwidth.com]]>
Note: Compatible with SIP Protocol ONLY will NOT work with MGCP

911 Redirect will work with SIP phones or Analog phones that are connected directly to one of the EdgeMarc's FXS ports.[/b]

If you are a Bandwidth.com customer please contact Bandwidth.com support if you are having any issues at 800-808-5150 or customercare@bandwidth.com]]> http://forum.bandwidth.com/showthread.php?tid=72 Wed, 19 Dec 2007 16:21:08 +0000 http://forum.bandwidth.com/showthread.php?tid=72 http://forum.bandwidth.com/showthread.php?tid=71 Wed, 19 Dec 2007 16:20:43 +0000 http://forum.bandwidth.com/showthread.php?tid=71 http://forum.bandwidth.com/showthread.php?tid=70 Wed, 19 Dec 2007 15:28:08 +0000 http://forum.bandwidth.com/showthread.php?tid=70
1. The number you are sending in the "From" field of the SIP header does not come with a local calling plan. IE an LI (Local Inbound) Number.
2. You are sending an 8XX number in your "From" Header.
3. There is No Number in the "From" Header.
3. You have purchased a One-way Outbound only trunk.

Call Rating and Additional Minute Charges
Call Rating: Bandwidth.com Outbound Only SIP Trunks only provide intrastate,
interstate and international long distance. No outbound
local calling or inbound calling service is provided. The distinction
and jurisdiction of inter versus intrastate versus international long
distance will be determined based on the Originating Automatic Number
Identification (ANI) and Terminating ANI provided in the call signaling.
Bandwidth.com utilizes the value in the 'FROM' field in the SIP header
as the Originating ANI for establishing the jurisdiction of the call
(i.e. interstate versus intrastate versus international). However, in
the event a value is present in any of the SIP header fields used for
caller id (e.g. Remote Party ID, P-Assert-Identity), Bandwidth.com may
use this in lieu of the "FROM" field as the Originating ANI to determine
the jurisdiction of a call. If Bandwidth.com cannot accurately rate a
call due to an invalid or omitted Originating ANI, and its rating
jurisdiction is not international, Bandwidth.com will default to rating
the call at the prevailing Intrastate long distance rate. Bandwidth.com
will determine the terminating carrier by evaluating the Terminating ANI
down to the NPA-NXX-X level.]]>
1. The number you are sending in the "From" field of the SIP header does not come with a local calling plan. IE an LI (Local Inbound) Number.
2. You are sending an 8XX number in your "From" Header.
3. There is No Number in the "From" Header.
3. You have purchased a One-way Outbound only trunk.

Call Rating and Additional Minute Charges
Call Rating: Bandwidth.com Outbound Only SIP Trunks only provide intrastate,
interstate and international long distance. No outbound
local calling or inbound calling service is provided. The distinction
and jurisdiction of inter versus intrastate versus international long
distance will be determined based on the Originating Automatic Number
Identification (ANI) and Terminating ANI provided in the call signaling.
Bandwidth.com utilizes the value in the 'FROM' field in the SIP header
as the Originating ANI for establishing the jurisdiction of the call
(i.e. interstate versus intrastate versus international). However, in
the event a value is present in any of the SIP header fields used for
caller id (e.g. Remote Party ID, P-Assert-Identity), Bandwidth.com may
use this in lieu of the "FROM" field as the Originating ANI to determine
the jurisdiction of a call. If Bandwidth.com cannot accurately rate a
call due to an invalid or omitted Originating ANI, and its rating
jurisdiction is not international, Bandwidth.com will default to rating
the call at the prevailing Intrastate long distance rate. Bandwidth.com
will determine the terminating carrier by evaluating the Terminating ANI
down to the NPA-NXX-X level.]]> http://forum.bandwidth.com/showthread.php?tid=69 Wed, 19 Dec 2007 15:22:13 +0000 http://forum.bandwidth.com/showthread.php?tid=69 http://forum.bandwidth.com/showthread.php?tid=68 Tue, 18 Dec 2007 19:49:01 +0000 http://forum.bandwidth.com/showthread.php?tid=68
Part 1:
http://www.edgeblog.net/2007/its-still-t...cy-stupid/

Part 2:

http://www.edgeblog.net/2007/its-still-t...tupid-pt2/]]>
Part 1:
http://www.edgeblog.net/2007/its-still-t...cy-stupid/

Part 2:

http://www.edgeblog.net/2007/its-still-t...tupid-pt2/]]> http://forum.bandwidth.com/showthread.php?tid=59 Tue, 27 Nov 2007 13:54:26 +0000 http://forum.bandwidth.com/showthread.php?tid=59
However, if the calling party waits the call will connect once the called party picks up or the call goes to voicemail.

There are currently two Ingate patches available to fix this issue, they are attached to this post.

These patches will be implemented in the 4.6.1 release. This patch
only works with 4.5.2.]]>
However, if the calling party waits the call will connect once the called party picks up or the call goes to voicemail.

There are currently two Ingate patches available to fix this issue, they are attached to this post.

These patches will be implemented in the 4.6.1 release. This patch
only works with 4.5.2.]]> http://forum.bandwidth.com/showthread.php?tid=58 Tue, 27 Nov 2007 13:36:53 +0000 http://forum.bandwidth.com/showthread.php?tid=58
This has been reproduced and identified as an issue with the Ingate Siparator. A patch is scheduled for release in version 4.6.1, due first half of January 2008.

A work around for this problem is to route the call through the auto attendant prior to transferring to the hunt group.]]>
This has been reproduced and identified as an issue with the Ingate Siparator. A patch is scheduled for release in version 4.6.1, due first half of January 2008.

A work around for this problem is to route the call through the auto attendant prior to transferring to the hunt group.]]> http://forum.bandwidth.com/showthread.php?tid=50 Thu, 01 Nov 2007 16:35:07 +0000 http://forum.bandwidth.com/showthread.php?tid=50
I am having real basic problems setting up the networking required to get my trixbox visible by bandwidth.com and my Polycom phones.

How can I setup the server and phones behind the Covad/Siemens router supplied by bandwidth.com so the phones can access the server and the server can be seen on the required ip by bandwidth?]]>
I am having real basic problems setting up the networking required to get my trixbox visible by bandwidth.com and my Polycom phones.

How can I setup the server and phones behind the Covad/Siemens router supplied by bandwidth.com so the phones can access the server and the server can be seen on the required ip by bandwidth?]]> http://forum.bandwidth.com/showthread.php?tid=49 Mon, 29 Oct 2007 19:46:22 +0000 http://forum.bandwidth.com/showthread.php?tid=49 http://forum.bandwidth.com/showthread.php?tid=48 Mon, 29 Oct 2007 19:44:42 +0000 http://forum.bandwidth.com/showthread.php?tid=48 http://forum.bandwidth.com/showthread.php?tid=47 Mon, 29 Oct 2007 19:42:59 +0000 http://forum.bandwidth.com/showthread.php?tid=47 http://forum.bandwidth.com/showthread.php?tid=46 Mon, 29 Oct 2007 18:23:04 +0000 http://forum.bandwidth.com/showthread.php?tid=46
Please note that Edgemarc has an integrated firewall should you choose to use it, which simplifies deployment.]]>
Please note that Edgemarc has an integrated firewall should you choose to use it, which simplifies deployment.]]> http://forum.bandwidth.com/showthread.php?tid=75 Fri, 26 Oct 2007 16:48:56 +0000 http://forum.bandwidth.com/showthread.php?tid=75 • This is the default queuing option.
• Recommended if you don’t need to prioritize one type of traffic over another.
• Available with Private Port and Enhanced Port, all access types (Table 2).
• Available with SmartPVC (Table 3).
This option is FIFO—no specialized queuing. Packets are simply sent in the order they are received.
Refer to template 0 (P1=0, P2=5, P3=0, P4=95).
Note: A small amount of bandwidth is reserved for network control traffic, even though there is no
customer-directed queuing.

Queuing Option B – unlimited P1 bandwidth
• Recommended only if you have a sophisticated understanding of your traffic types and flows and
the implications of queue starvation that may occur.
• Available with Private Port and Enhanced Port, all access types (Table 2).
• Available with SmartPVC (Table 3)
This option always services the P1 queue first until it is empty, at the expense of the other queues,
regardless of the percentage value assigned to the P1 queue.

This means you can completely starve your other three queues by marking too much traffic with
IPP=5. The exception is that with DIPA access, packets are serviced alternately in P1 and P2, so P2
will not be starved. Queues P2, P3 and P4 are serviced if the P1 queue is empty, and are serviced in
a deficit-weighted round-robin fashion.

Queuing Option C – P1 low latency
• Recommended if you are using voice or video, but also have a need to guarantee availability of
some minimum amount of bandwidth to other applications. This option should be considered the
standard option if you have voice or video traffic and DIPA local loops.
• Available with Private Port, DIPA only (Table 2).
Option C is similar to Option B. The difference is this option limits the amount of bandwidth the P1
queue can consume to the percentage assigned to P1.

Queuing Option D – No special P1 queue treatment
• Recommended for general use if you have Frame Relay and/or ATM access, including voice
and/or video traffic. It is also recommended for use with DIPA where P1 should be allowed to
burst to port speed.
• Available with Private Port and Enhanced Port, all access types (Table 2).
• Available with SmartPVC]]> • This is the default queuing option.
• Recommended if you don’t need to prioritize one type of traffic over another.
• Available with Private Port and Enhanced Port, all access types (Table 2).
• Available with SmartPVC (Table 3).
This option is FIFO—no specialized queuing. Packets are simply sent in the order they are received.
Refer to template 0 (P1=0, P2=5, P3=0, P4=95).
Note: A small amount of bandwidth is reserved for network control traffic, even though there is no
customer-directed queuing.

Queuing Option B – unlimited P1 bandwidth
• Recommended only if you have a sophisticated understanding of your traffic types and flows and
the implications of queue starvation that may occur.
• Available with Private Port and Enhanced Port, all access types (Table 2).
• Available with SmartPVC (Table 3)
This option always services the P1 queue first until it is empty, at the expense of the other queues,
regardless of the percentage value assigned to the P1 queue.

This means you can completely starve your other three queues by marking too much traffic with
IPP=5. The exception is that with DIPA access, packets are serviced alternately in P1 and P2, so P2
will not be starved. Queues P2, P3 and P4 are serviced if the P1 queue is empty, and are serviced in
a deficit-weighted round-robin fashion.

Queuing Option C – P1 low latency
• Recommended if you are using voice or video, but also have a need to guarantee availability of
some minimum amount of bandwidth to other applications. This option should be considered the
standard option if you have voice or video traffic and DIPA local loops.
• Available with Private Port, DIPA only (Table 2).
Option C is similar to Option B. The difference is this option limits the amount of bandwidth the P1
queue can consume to the percentage assigned to P1.

Queuing Option D – No special P1 queue treatment
• Recommended for general use if you have Frame Relay and/or ATM access, including voice
and/or video traffic. It is also recommended for use with DIPA where P1 should be allowed to
burst to port speed.
• Available with Private Port and Enhanced Port, all access types (Table 2).
• Available with SmartPVC]]> http://forum.bandwidth.com/showthread.php?tid=78 Fri, 26 Oct 2007 16:38:27 +0000 http://forum.bandwidth.com/showthread.php?tid=78 Definition: Provides WAN connectivity between locations. Security
between locations is provided using private Solutions. Private Port
includes template-based quality of service (QoS) traffic prioritization.
For details contact your Qwest account team.

Enhanced Port:
Definition: Provides all the functionality of a Private Port plus
Internet access on a single interface. On the private portion of
Enhanced Port template-based QoS traffic prioritization is available.]]> Definition: Provides WAN connectivity between locations. Security
between locations is provided using private Solutions. Private Port
includes template-based quality of service (QoS) traffic prioritization.
For details contact your Qwest account team.

Enhanced Port:
Definition: Provides all the functionality of a Private Port plus
Internet access on a single interface. On the private portion of
Enhanced Port template-based QoS traffic prioritization is available.]]> http://forum.bandwidth.com/showthread.php?tid=76 Fri, 26 Oct 2007 16:36:02 +0000 http://forum.bandwidth.com/showthread.php?tid=76
For Example: If I ordered an MPLS T1 (1.544Mbps), I could allocate 20% to the private side and 80% to the data side. This would give me roughly 307Kbps for the private side and 1.230Mpbs for Internet access.]]>
For Example: If I ordered an MPLS T1 (1.544Mbps), I could allocate 20% to the private side and 80% to the data side. This would give me roughly 307Kbps for the private side and 1.230Mpbs for Internet access.]]> http://forum.bandwidth.com/showthread.php?tid=77 Fri, 26 Oct 2007 15:52:09 +0000 http://forum.bandwidth.com/showthread.php?tid=77 Qwest IP MPLS service supports four quality of service (QoS) queues allowing you full control to prioritize
your applications into different priority classes based on IP precedence (IPP) bits. For example, you can
set priorities so real-time applications, such as interactive voice and video, get priority over applications
that do not require real-time handling. The IPP bits are the first three bits of the type-of-service byte within
the IP packet header.

Recommended process
First, classify your traffic based on performance requirements. That classification determines which of the
four queues each type of traffic uses. Mark the traffic classification using IPP; packets are then queued
according to your assigned IPP classification. This classification designation determines how you use the
four available queues.

Qwest recommends you:
• Minimize the number of queues you use
• Lump traffic with similar jitter and latency requirements together; simplifying queue management
• Place real-time traffic into one the top two queues, P1 and P2

Suggested prioritization
If both voice and video are present, place voice into P1 and video into P2. If only video is present, it
should go into P1. Place traffic with more liberal latency and jitter requirements into the P3 and/or P4
queues. Note: P2 automatically includes network control traffic, so it is essential that this queue not be
oversubscribed.

Queues and IPP Values:



Queue
IPP Value


Priority 1 (P1)
5


Priority 2 (P2)
4,6,7*


Priority 3 (P3)
2,3


Priority 4 (P4)
0,1



*
Some “network control” traffic also uses the Priority 2 queue. Specifically, OSPF, LDP (hello), RSVP, PIM, ISIS
and L2 keepalives are designated to use this queue if they are present. Of those, only the L2 keepalives are
actually running on the CE-PE link.

If you have any questions, or you want further guidance on the best option to use, contact your Sales Engineer.]]> Qwest IP MPLS service supports four quality of service (QoS) queues allowing you full control to prioritize
your applications into different priority classes based on IP precedence (IPP) bits. For example, you can
set priorities so real-time applications, such as interactive voice and video, get priority over applications
that do not require real-time handling. The IPP bits are the first three bits of the type-of-service byte within
the IP packet header.

Recommended process
First, classify your traffic based on performance requirements. That classification determines which of the
four queues each type of traffic uses. Mark the traffic classification using IPP; packets are then queued
according to your assigned IPP classification. This classification designation determines how you use the
four available queues.

Qwest recommends you:
• Minimize the number of queues you use
• Lump traffic with similar jitter and latency requirements together; simplifying queue management
• Place real-time traffic into one the top two queues, P1 and P2

Suggested prioritization
If both voice and video are present, place voice into P1 and video into P2. If only video is present, it
should go into P1. Place traffic with more liberal latency and jitter requirements into the P3 and/or P4
queues. Note: P2 automatically includes network control traffic, so it is essential that this queue not be
oversubscribed.

Queues and IPP Values:



Queue
IPP Value


Priority 1 (P1)
5


Priority 2 (P2)
4,6,7*


Priority 3 (P3)
2,3


Priority 4 (P4)
0,1



*
Some “network control” traffic also uses the Priority 2 queue. Specifically, OSPF, LDP (hello), RSVP, PIM, ISIS
and L2 keepalives are designated to use this queue if they are present. Of those, only the L2 keepalives are
actually running on the CE-PE link.

If you have any questions, or you want further guidance on the best option to use, contact your Sales Engineer.]]> http://forum.bandwidth.com/showthread.php?tid=41 Tue, 23 Oct 2007 21:46:55 +0000 http://forum.bandwidth.com/showthread.php?tid=41
Please make sure to setup all of the local functionality of the CME before trying to setup the SIP Trunks.

When you are ready to setup the SIP trunks, the first thing you wll need to do is setup a translation rule. The translation rule will help you structure how outbound calls are dialed and sent to Bandwidth.com.

Translation Rule:
voice translation-rule 2
rule 1 /^9\(.......\)$/ /+1714\1/ Local Calling "714" is the local area code
rule 2 /^9\(..........\)$/ /+1\1/ 10 Digit Calling adds "+1"
rule 3 /^9\(.*\)$/ /+\1/ 11 Digit Dialing adds "+"
rule 4 /^9\(...........\)$/ /+\1/ Catch-all
rule 5 /^9011\(.*\)$/ /+\1/ International Dialing strips the "011" and adds "+"

The Dial-Peer is next. It is where the acctual trunk information is setup.

Dial-Peer:
dial-peer voice 101 voip
description ** Outgoinging call to SIP trunk **
translation-profile outgoing SIPCALL
destination-pattern 9[2-9]......T
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target ipv4:216.82.224.202 This can be either Bandwidth.com's proxy address or if you are using a proxy like the EdgeMarc or InGate, it would be their LAN IP
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
clid network-number 7144245151 This is how you setup for a global outbound callerID
no vad

Now here is a sample of how to configure a user phone:

ephone-dn 2 dual-line
number 1720 secondary +17144245151 Make sure you insert the "+1" into the number in order to recognize inbound calls.
label 7144245151
description Temp User
name Temp User
call-forward noan 917144245152 timeout 10 This is to call FWD no Answer to VM
corlist incoming user900-international



I hope this helps Cisco Partners with Bandwidth.com SIP trunking. If you have any sugestions or comments, give me a shout.]]>
Please make sure to setup all of the local functionality of the CME before trying to setup the SIP Trunks.

When you are ready to setup the SIP trunks, the first thing you wll need to do is setup a translation rule. The translation rule will help you structure how outbound calls are dialed and sent to Bandwidth.com.

Translation Rule:
voice translation-rule 2
rule 1 /^9\(.......\)$/ /+1714\1/ Local Calling "714" is the local area code
rule 2 /^9\(..........\)$/ /+1\1/ 10 Digit Calling adds "+1"
rule 3 /^9\(.*\)$/ /+\1/ 11 Digit Dialing adds "+"
rule 4 /^9\(...........\)$/ /+\1/ Catch-all
rule 5 /^9011\(.*\)$/ /+\1/ International Dialing strips the "011" and adds "+"

The Dial-Peer is next. It is where the acctual trunk information is setup.

Dial-Peer:
dial-peer voice 101 voip
description ** Outgoinging call to SIP trunk **
translation-profile outgoing SIPCALL
destination-pattern 9[2-9]......T
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target ipv4:216.82.224.202 This can be either Bandwidth.com's proxy address or if you are using a proxy like the EdgeMarc or InGate, it would be their LAN IP
dtmf-relay rtp-nte
ip qos dscp cs5 media
ip qos dscp cs4 signaling
clid network-number 7144245151 This is how you setup for a global outbound callerID
no vad

Now here is a sample of how to configure a user phone:

ephone-dn 2 dual-line
number 1720 secondary +17144245151 Make sure you insert the "+1" into the number in order to recognize inbound calls.
label 7144245151
description Temp User
name Temp User
call-forward noan 917144245152 timeout 10 This is to call FWD no Answer to VM
corlist incoming user900-international



I hope this helps Cisco Partners with Bandwidth.com SIP trunking. If you have any sugestions or comments, give me a shout.]]>