Hi
вот не об этом ли идет речь? :)
Но тут все проще - эта железка приходит в DSLAM (причем только алкателевский
и далеко не любой, под нее плату отдельную надо) и выходит с него сразу в PSTN.
Best regards,
Alexey Sorokin
On Sat, 18 Aug 2001, Vladimir Litovka wrote:
> Hi,
>
> Есть такая задача (в некоторой степени академическая, потому что я
> примеров оборудования не знаю, но допускаю, что оно существует :) но
> допустим, что есть клиентское DSL устройство (CPE) с несколькими
> голосовыми портами, не понимающее при этой VoIP, а только VoATM. DSLAM, в
> который этот CPE воткнут, просвитчит мне VC с голосом куда-то, где я его
> должен обработать. И при отсутствии ATM сети я что-то никакой другой
> обработки кроме как тупо сбросить вызов в PSTN, не вижу. Вот тут-то и
> возникает несколько странных желаний :)
>
> Существует-ли механизм проксирования (типа NAT :) вызовов, при котором
> происходит замена транспортного протокола, например ATM в IP:
>
> . входящий voice собирается из ATM cells в свой оригинальный вид;
> . упаковывается в IP (с прописыванием заголовков как-бы от себя)
> . и отправляется дальше по сети IP
> . ответная часть проходит обратную процедуру
>
> по логике, сложного здесь нет ничего - кодировать/декодировать голос не
> нужно, обработка только сетевой части. Или это мне только кажется? :)
>
> Попутно вопрос по VoIP Tandem Switching - допустим "A" звонит к "B",
> используя "S" в качестве свича. Кому будет отвечать "B" - прямо к "A" или
> опять же через "S"? И как будет работать более сложный механизм - если
> вдруг "S" потребуется выяснить у Gatekeeper'а адрес вызываемой стороны? Он
> будет работать от своего имени, выступая в качестве прокси для "A" или это
> будет выглядеть по другому?
>
> И для обоих случаев была бы полезна такая еще возможность (но
> реализуема-ли она?) - можно-ли сменить кодек на лету? Фишка в том, что
> CPE, не испытывая нужды в емкости, применяет кодеки G.711 (64Kbps) и G.726
> (32Kbps). В случае немедленного сброса вызова в PSTN это не имеет
> значения, в случае же дальнейшей oтправки его по IP хотелось бы сжать его
> сильнее :) Соответственно, нужна перепаковка. Минусы этого подходя
> очевидны - качество от двойного сжатия/распаковки страдает, время
> прохождения пакетов увеличивается (особенно при использовании high
> complexity кодеков), на транзитном устройстве требуется установка DSP для
> перепаковки. Плюсы - экономия bandwidth'а; вероятно даже, что качество
> получится не хуже, чем если проталкивать этот вызов через IP сеть в
> формате g.711 :)
>
> Существуют ли на сей счет стандарты и/или оборудование, поддерживающее эти
> фичи?
>
> А вообще - кто использует DSL решения промышленно - какие и почему именно
> эти?
>
> Спасибо :)
>
> --
> Vladimir Litovka <doka@kiev.sovam.com> | "I've seen the future and it's
> . Phone/Fax: +380 44 4900111 | Cisco switches!"
> . ICQ/private, talk/none ;) | Cat Alyst
>
>
> =============================================================================
> "inet-admins" Internet access mailing list. Maintained by East Connection ISP.
> Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
> Archive is accessible on
>
=============================================================================
"inet-admins" Internet access mailing list. Maintained by East Connection ISP.
Mail "unsubscribe inet-admins" to Majordomo@info.east.ru if you want to quit.
Archive is accessible on
