Transit sip trunk to sip trunk TDE,NCP

[НачШтаба]

Миш, ты прав, инкапсулирован, естественно, Q-sig .. это что-то у меня переклинило, вспомнилось обязательное "деление" по два канала.
Модель самсунга в Питере не знаю (видимо, что-то из OS7ххх), но в Москве TDE. И CT и CF работают. Прекрасно наблюдается погасание DSS-кнопок на системнике при "возвращении" вызова через приблизительно 3-4 секунды и просто короткое загорание при включенной переадресации при "обратном" направлении. Что касается LG, то тоже не могу посмотреть, она в Киеве. Кнопки не видел, но вроде бы всё тоже вполне работает, сужу по тому, что каналов всего 4, а поток вызовов бывал вполне ощутимым.... К тому клиенту давно не езжу (обидели они меня немного), поэтому именно про него могу утверждать только с достоверностью 75-85%.

[Mike_K]

Миш, ты прав, инкапсулирован, естественно, Q-sig .. это что-то у меня переклинило, вспомнилось обязательное "деление" по два канала.
Модель самсунга в Питере не знаю (видимо, что-то из OS7ххх), но в Москве TDE. И CT и CF работают. Прекрасно наблюдается погасание DSS-кнопок на системнике при "возвращении" вызова через приблизительно 3-4 секунды и просто короткое загорание при включенной переадресации при "обратном" направлении. Что касается LG, то тоже не могу посмотреть, она в Киеве. Кнопки не видел, но вроде бы всё тоже вполне работает, сужу по тому, что каналов всего 4, а поток вызовов бывал вполне ощутимым.... К тому клиенту давно не езжу (обидели они меня немного), поэтому именно про него могу утверждать только с достоверностью 75-85%.

НачШтаба = СКАЗОЧНИК -> Ганс Христиан Андерсен, прочтите Q38913.
Читать нужно только "Решение от Panasonic" начиная со слов
По настройкам:
Меню "[1-1] Slot—Shelf Property - Virtual IP Gateway"

Более детально раскладывать по полочкам Q-Sig от производителя на открытом форуме, уверен, не следует. Если внимательно перечитаете Базу знаний по этому вопросу, найдёте массу подтверждений особеностям реализации некоторых supplementary services в Q-sig от Panasonic.

[НачШтаба]

А знаете что, Михаил... может быть я и сказочник, только у меня эти сервисы работали очень даже неплохо при упомянутой Вами "собственности". Я постараюсь найти того человека в Питере, который настраивал Самсунг, он подтвердит. То, что "собственными" являются информация NDSS, "дополнительности" про COS и прочее, я не оспариваю. Но CT и CF - это вполне СТАНДАРТНЫЕ процедуры, и поддержка их оборудованием других вендоров вполне ожидаема. Не забывайте про наличие ключевого слова в той фразе, которую Вы постеснялись цитировать:

..поскольку это часть собственного протокола..

Часть - не есть целое. Сальник от коробки передач Хонды у меня прекрасно стоит и работает в стиральной машинке Занусси. Задача сальника и в автомобиле, и в стиральной машинке - защищать подшипник от попадания посторонней влаги. И там, и там он работает одинаково успешно.

[Mike_K]

....Но CT и CF - это вполне СТАНДАРТНЫЕ процедуры, и поддержка их оборудованием других вендоров вполне ожидаема...

С чего это Вы взяли, что CT и СF СТАНДАРТНЫЕ? Дайте пожалуйста ссылку на документ, типа ITU-T или ETSI, где описана их реализация и обязательна для исполнения всеми производителями. Признаюсь много лет ищу эту инфу.
Далее, просто умалчиваю о том, с чего начался разговор. Если Вы помните это были CT-Q.Sig и CF-Q.Sig от Panasonic.

[НачШтаба]

ETSI ETS 300 257, ETSI ETS 300 261.. Речь об этом? Или о ISO/IEC 11582 и ISO/IEC 11582?.. Я не знаю иностранных языков, поэтому не хочу читать и переводить даже со словарём. Соответственно, поиск документа, написанного на непонятном мне языке тоже очень осложнён.

[Mike_K]

Спасибо НачШтаба, хорошая шутка, оценил.

[Mike_K]

Хотел добавить ссылку в свой предыдущий пост, но редактирование уже не возможно.
Так вот, по поводу написанного ниже:

....Но CT и CF - это вполне СТАНДАРТНЫЕ процедуры, и поддержка их оборудованием других вендоров вполне ожидаема...

С чего это Вы взяли, что CT и СF СТАНДАРТНЫЕ? Дайте пожалуйста ссылку на документ, типа ITU-T или ETSI, где описана их реализация и обязательна для исполнения всеми производителями. Признаюсь много лет ищу эту инфу.
Далее, просто умалчиваю о том, с чего начался разговор. Если Вы помните это были CT-Q.Sig и CF-Q.Sig от Panasonic.

НачШтаба, специально для Вас, информация на сегодняшний день. Не утруждайте себя поиском и дальнейшими длительными, изнурительными переводами с неизвестного языка, ссылка по поводу реализации supplementary services CT с официального сайта ITU-T http://www.itu.int/rec/T-REC-Q.82.1/en
Перевести нужно будет чуть более десятка слов, чтоб понять как обстоят дела с этим вопросом.
По поводу supplementary services CF, так же могу поделиться инфой как обстоят дела с этим вопросом на сегодня, но читать на английском нужно будет уже десятки страниц.

[НачШтаба]

ссылка по поводу реализации supplementary services CT с официального сайта ITU-T http://www.itu.int/rec/T-REC-Q.82.1/en

не понял ничего. Перевести смог только слово "This".

[bovt]

А почему нельзя вызовы между астером и панасом гонять по Н-323-му? Там ведь можно даже получить "экономию" по одновременно занимаемым транкам, ведь на 323-м есть поддержка CT и CF.

Да по 323 самый лучший вариант. Но у астера как вы нач штаба знаете 323 - неполноценный. Имена не ходят . А вот по сипу всё пучком. Поэтому входящие звонки на астер через панас транзитом я запускал через 323(имена из города все ровно не приходят). А вот из астера в панас на внутренние звонок у меня возвращался по сипу и паносониковские абоненты видят кто им из астера звонит-переводит звонок.

[switch]

При всём коленопреклоненном уважении к НачШтаба, в вопросе с CT и CF, он что то попутал.
Могу сказать со 99% уверенностью по поводу лыжи - там самопровозглашённая реализация H.450, которая не совместима даже с просто H.450, не говоря уж про инкапсуляцию Q-SIG, да ещё наверняка со своим диалектом, которую использует панас.