![]() |
VoIP question
Is it possible to assign different level of service for a higher
paying customer in a VoIP post paid scenario, based on the caller's telephone number. The end point telephones are regular POTS lines. Intent is to give different quality and service to subscribers based on the perminute charges they pay. If yes please explain how it is done.. |
Re: VoIP question
Humm. Interesting one. If the endpoints are POTS phones do they connect to an Ethernet/IP network through some sort of terminal adapter, like an ATA186? I'll assume they do. You could set different 802.1p COS values for different customers and different IP precedence or diffserv code point values simultaneously at the terminal adapter for out bound calls. Your ingress Ethernet switch will need to be able to honor, enforce and remark the above markings. Also any other electronics in the path of the traffic will also need to respond to these markings appropriately. And of course inbound traffic, from the network core to the terminal adapater attached phone will need to be marked at it's source. gmcleveney wrote: > Is it possible to assign different level of service for a higher > paying customer in a VoIP post paid scenario, based on the caller's > telephone number. > The end point telephones are regular POTS lines. > Intent is to give different quality and service to subscribers based > on the perminute charges they pay. > If yes please explain how it is done.. |
Re: VoIP question
On Thu, 01 Apr 2004 20:36:05 -0500, SPD <blairsp@dca.net> wrote:
> Humm. Interesting one. If the endpoints are POTS phones >do they connect to an Ethernet/IP network through some >sort of terminal adapter, like an ATA186? I'll assume >they do. > > You could set different 802.1p COS values for different >customers and different IP precedence or diffserv code >point values simultaneously at the terminal adapter for >out bound calls. >.... Or you could allow those paying the highest rate to use G.711, and force those paying the lowest rate to use G.723.1 or some worse codec. |
Re: VoIP question
Hank Karl wrote:
> On Thu, 01 Apr 2004 20:36:05 -0500, SPD <blairsp@dca.net> wrote: > >> Humm. Interesting one. If the endpoints are POTS phones >>do they connect to an Ethernet/IP network through some >>sort of terminal adapter, like an ATA186? I'll assume >>they do. >> >> You could set different 802.1p COS values for different >>customers and different IP precedence or diffserv code >>point values simultaneously at the terminal adapter for >>out bound calls. >>.... > > Or you could allow those paying the highest rate to use G.711, and > force those paying the lowest rate to use G.723.1 or some worse codec. True although I assumed the author was concerned about variability on the IP network affecting call quality. The codec selection helps but may or may not provide the consistent user experience associated with a given fee level. COS,IP Prec & DiffServ may not either but in my experience this approach is more consistent. We have many different pieces of hardware, OS's and loads on the processor/memory on desktop devices. The encoding and decoding delay associated with some codecs combined with network congestion has created quality issues for users where other users of the same codec do not have problem (The other users have different hardware on their desktop) That's been my experience for what it's worth :-) |
Re: VoIP question
On Fri, 02 Apr 2004 20:21:52 -0500, SPD <blairsp@dca.net> wrote:
>Hank Karl wrote: >> On Thu, 01 Apr 2004 20:36:05 -0500, SPD <blairsp@dca.net> wrote: >> >>> Humm. Interesting one. If the endpoints are POTS phones >>>do they connect to an Ethernet/IP network through some >>>sort of terminal adapter, like an ATA186? I'll assume >>>they do. >>> >>> You could set different 802.1p COS values for different >>>customers and different IP precedence or diffserv code >>>point values simultaneously at the terminal adapter for >>>out bound calls. >>>.... >> >> Or you could allow those paying the highest rate to use G.711, and >> force those paying the lowest rate to use G.723.1 or some worse codec. > >True although I assumed the author was concerned about >variability on the IP network affecting call quality. >The codec selection helps but may or may not provide the >consistent user experience associated with a given >fee level. COS,IP Prec & DiffServ may not either but >in my experience this approach is more consistent. > I read it a different way: the author wanted to connect two analog phones, so his service would be doing the codec. Codec selection absolutely affects call quality. See the MOS table at http://www.cisco.com/warp/public/788...omplexity.html Cisco claims their gear has: G.711 has a MOS of 4.1 (other estimates place it at 4.2 or 4.4) and compression delay of .75 mSec. G.723.1 at 5.3K has a MOS of 3.65 and compression delay of 30 mSec. You'll also have some delay in collecting the samples, which varies with codec and is sometimes a user-specifiable option. Delay affects perceived voice quality, and often a delay of under 100 milliseconds is the goal for toll-quality VoIP. So G.711 sounds better and may have a lower delay, assuming no jitter or packet loss, and equal network delays between the two endpoints. >We have many different pieces of hardware, OS's and >loads on the processor/memory on desktop devices. The >encoding and decoding delay associated with some codecs >combined with network congestion has created quality >issues for users where other users of the same codec >do not have problem (The other users have different >hardware on their desktop) > >That's been my experience for what it's worth :-) I agree, but will add that the network congestion causes packet loss, and excess jitter (which leads to packets being discarded by the jitter buffer). Packet loss and discard affect different codecs in different ways. It's unclear how much control over his network the author had. If you own the network, you can manage it so that jitter and loss are not problems. |
| All times are GMT. The time now is 09:43 AM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.