Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Forced Gatekeeper
- Thread starter TBLuk
- Start date
whosrdaddy
Vendor
no you can't .
the only place where you can force gateway calls is with ip trunking.
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
the only place where you can force gateway calls is with ip trunking.
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
- Thread starter
- #3
I knew there wasn't an 'official' way of doing it, but I'm trying to figure out if there's a workaround, i.e. making endpoint codecs incompatible etc.
GW calls are much more tolerant of varying network conditions, and the VPU in the phone is not as good as the IPLU at handling excessive jitter - something which can be common on DSL connections used for voice and data at the same time.
GW calls are much more tolerant of varying network conditions, and the VPU in the phone is not as good as the IPLU at handling excessive jitter - something which can be common on DSL connections used for voice and data at the same time.
whosrdaddy
Vendor
then setup a TLU76 loop, if you have a MGW system, it's just a matter of a cross cable (and licenses offcourse)
If QoS is properly setup within the network you shouldn't have any problems.
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
If QoS is properly setup within the network you shouldn't have any problems.
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
- Thread starter
- #5
But that wouldn't prevent calls from IP phone at site A going direct to IP phones at site B.
RE: QoS... I knew someone would say that!
QoS is setup fine, we've found a potential anomoly on the performance of DSL ccts when heavily loaded in the up and downstreams at the same time.
QoS can work as hard as it wants, but at some point in time, data packets will need to be serviced, and that's when we're finding problems.
I'd be intrigued to know if anyone else has customer offices using a single low speed (512K) DSL link for both voice and data, and whether they have had problems?
RE: QoS... I knew someone would say that!
QoS is setup fine, we've found a potential anomoly on the performance of DSL ccts when heavily loaded in the up and downstreams at the same time.
QoS can work as hard as it wants, but at some point in time, data packets will need to be serviced, and that's when we're finding problems.
I'd be intrigued to know if anyone else has customer offices using a single low speed (512K) DSL link for both voice and data, and whether they have had problems?
whosrdaddy
Vendor
then increase the bandwith!
quality and bandwith are bonded...
you are sending data & voice on the same link?
what codec are you using?
it's all about proper network architecture...
/Daddy
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
quality and bandwith are bonded...
you are sending data & voice on the same link?
what codec are you using?
it's all about proper network architecture...
/Daddy
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
- Thread starter
- #7
I agree, it is all about proper network architecture, however throwing bandwidth at a problem is engineering around the problem.
For a bursty service like data, where the available bandwidth is more than adequate 95% of the time, it is wasteful to increase bandwidth.
Quality and bandwidth are not bonded when it comes to real time applications such as VoIP and video; quality and expediency of packet delivery are bonded.
We have some customers in remote locations where 512Kbit/s DSL is the only effective solution. The number of staff coupled with the difficulty in providing leased lines mean DSL 'should' be a perfect solution.
However, since the QoS appears to work effectively in our tests, either the modem or the DSL cct itself are holding up packet delivery to a level which the 442x devices cannot handle.
Calls via the IPLU such as PSTN breakout or incoming DDI, are fine. Traces show the delay and jitter remain high, but the IPLU seems to have a better in-built jitter buffer.
G.729a codec is in use with effective QoS to priority queue VoIP traffic.
We have numerous options:
1. Implement seperate DSL connections for voice and data
2. Force all calls to/from DSL sites to go via IPLU (possibly not an option)
3. Have Aastra investigate why the phone deals with jitter in a worse fashion than the 442x (already in progress, possible custom App FW)
4. Have BT/Cisco investigate why there appears to be an end to end delay
It's an interesting one from my perspective, hence why I wanted to pose the question and get some thoughts from people who haven't been involved!
For a bursty service like data, where the available bandwidth is more than adequate 95% of the time, it is wasteful to increase bandwidth.
Quality and bandwidth are not bonded when it comes to real time applications such as VoIP and video; quality and expediency of packet delivery are bonded.
We have some customers in remote locations where 512Kbit/s DSL is the only effective solution. The number of staff coupled with the difficulty in providing leased lines mean DSL 'should' be a perfect solution.
However, since the QoS appears to work effectively in our tests, either the modem or the DSL cct itself are holding up packet delivery to a level which the 442x devices cannot handle.
Calls via the IPLU such as PSTN breakout or incoming DDI, are fine. Traces show the delay and jitter remain high, but the IPLU seems to have a better in-built jitter buffer.
G.729a codec is in use with effective QoS to priority queue VoIP traffic.
We have numerous options:
1. Implement seperate DSL connections for voice and data
2. Force all calls to/from DSL sites to go via IPLU (possibly not an option)
3. Have Aastra investigate why the phone deals with jitter in a worse fashion than the 442x (already in progress, possible custom App FW)
4. Have BT/Cisco investigate why there appears to be an end to end delay
It's an interesting one from my perspective, hence why I wanted to pose the question and get some thoughts from people who haven't been involved!
"For a bursty service like data, where the available bandwidth is more than adequate 95% of the time, it is wasteful to increase bandwidth."
But you are not just using the links for simply bursty data anymore, you are now sending Voice packets over the links, bandwidth can be an issue here.
Do you get problems as number of calls increase, are you using CAC to limit RTP resources in the 512K connected sites?
best parnum
- Thread starter
- #9
I agree that bandwidth CAN be an issue in some circumstances guys, but what I am saying is that in this case it is most definitely not an issue.
CAC is in place to limit concurrent IP calls, and is in no danger of being breached.
I can replicate this problem by flooding the DSL connection using Ixia Chariot and then making just a single call.
I could thrown in a 8,192Kbit/s DSL connection and STILL replicate the problem.
I've tested this on DSL lines in our lab with pristene line statistics, and lines with downright borderline conditions - the problem persists.
Bandwidth is most definitately not the problem, and here is the final test I can explain which will prove it:
Lab setup with two back to back serial routers.
Serial connections rate limited to 256Kbit/s
Link flooded
IP to IP call made - no problems!
Problem is only via DSL, and proves that something in the underlying DSL technology (be it the router's modem or the DSLAM, or the BT ATM network), is holding up packets.
BT are a dog to get anything done, so whilst I'm chasing them, I'm also looking at workarounds in parallel, hence why I'm on here hoping you guys can scratch your brains too.
CAC is in place to limit concurrent IP calls, and is in no danger of being breached.
I can replicate this problem by flooding the DSL connection using Ixia Chariot and then making just a single call.
I could thrown in a 8,192Kbit/s DSL connection and STILL replicate the problem.
I've tested this on DSL lines in our lab with pristene line statistics, and lines with downright borderline conditions - the problem persists.
Bandwidth is most definitately not the problem, and here is the final test I can explain which will prove it:
Lab setup with two back to back serial routers.
Serial connections rate limited to 256Kbit/s
Link flooded
IP to IP call made - no problems!
Problem is only via DSL, and proves that something in the underlying DSL technology (be it the router's modem or the DSLAM, or the BT ATM network), is holding up packets.
BT are a dog to get anything done, so whilst I'm chasing them, I'm also looking at workarounds in parallel, hence why I'm on here hoping you guys can scratch your brains too.
whosrdaddy
Vendor
TBLuk, I can feel your pain.
Also had some problem customers on BT links, and it always ends with BT fixing the problem.
question, the DSL line you are talking about, is it SDSL or a plain DSL link? (like for a normal internet subscriber)
/Daddy
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
Also had some problem customers on BT links, and it always ends with BT fixing the problem.
question, the DSL line you are talking about, is it SDSL or a plain DSL link? (like for a normal internet subscriber)
/Daddy
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
- Thread starter
- #11
Hey,
It's standard 512down/256up ADSL. Potentially something like SDSL would solve the problems, but it's cost inhibitive, and doesn't work over very long lines.
I'm intrigues about the historical problems you've had with BT links; are you talking about VoIP issues over ADSL, or just BT in general?
The only alternative 'workaround' I can think of, albeit really rotten, is this:
For incoming calls to DSL sites:
Renumber the DSL sites extension ranges, replacing the OLD ranges with ABB going the DDI number of the new number. Meaning people reaching a DSL site, will go out and back in via TDM and thus will use IPLU
For outgoing calls from DSL sites:
Have them dial an access code that puts them round a TLU loop, or similar, again forcing them to go via the IPLU.
I will persist with BT, but again, comments appreciated.
It's standard 512down/256up ADSL. Potentially something like SDSL would solve the problems, but it's cost inhibitive, and doesn't work over very long lines.
I'm intrigues about the historical problems you've had with BT links; are you talking about VoIP issues over ADSL, or just BT in general?
The only alternative 'workaround' I can think of, albeit really rotten, is this:
For incoming calls to DSL sites:
Renumber the DSL sites extension ranges, replacing the OLD ranges with ABB going the DDI number of the new number. Meaning people reaching a DSL site, will go out and back in via TDM and thus will use IPLU
For outgoing calls from DSL sites:
Have them dial an access code that puts them round a TLU loop, or similar, again forcing them to go via the IPLU.
I will persist with BT, but again, comments appreciated.
whosrdaddy
Vendor
if you are using a plain dsl line then BT does not have to guarantee any level of service (like minimum bandwith) so you can't really blaim them. how many users do you have on a site like this?
anyway most likely, your "rotten" solution is the cheapest.
Like I said before, you get wat you paid for...
/Daddy
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
anyway most likely, your "rotten" solution is the cheapest.
Like I said before, you get wat you paid for...
/Daddy
-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!
- Thread starter
- #13
daddy, appreciate you taking the time to respond, but please be constructive.
I never said it was an ordinary contended dsl circuit, and it seems you aren't fully familiar with the options available on UK DSL.
BT provide a 1:1 contended connection with an in span hanover to our ATM network, so yes, bandwidth is as guaranteed as it can get (throughput however, is not)
Don't think of DSL as a cheap and nasty solution; it's only so if you buy a vanilla connection from an ISP.
I never said it was an ordinary contended dsl circuit, and it seems you aren't fully familiar with the options available on UK DSL.
BT provide a 1:1 contended connection with an in span hanover to our ATM network, so yes, bandwidth is as guaranteed as it can get (throughput however, is not)
Don't think of DSL as a cheap and nasty solution; it's only so if you buy a vanilla connection from an ISP.
- Status
Similar threads
- Locked
- Question
- Locked
- Question