[orca]

Нигде немогу найти информацию как перевести вызов на этом шлюзе. В описании на сайте написано что он это умеет, но как непонятно.

[Mikler]

Если в документации на шлюз этого нет значит этого нет. Для SIP эти фичи называются Call transfer. На сайте D-Link черным по белому написано что модель снята с производства т.е. ждать от неё дополнительных сервисов не стоит.

[orca]

Но вот тут http://www.dlink.ru/products/prodview.php?type=19&id=499 написано:

"Функции вызова

Перенаправление вызова (Call Transfer)

Удержание вызова (Call Hold)

Ожидание вызова (Call Waiting)

Отображение идентификатора вызывающего абонента (Callre ID display) "

 

Вопрос в том как этим пользоваться?

[Mikler]

Но вот тут http://www.dlink.ru/products/prodview.php?type=19&id=499 написано:

"Функции вызова

Перенаправление вызова (Call Transfer)

Удержание вызова (Call Hold)

Ожидание вызова (Call Waiting)

Отображение идентификатора вызывающего абонента (Callre ID display) "

 

Вопрос в том как этим пользоваться?

А настройки какие есть?

Вообще телефон должен быть с flash. Нажал flash поставил на удержание. Начал набирать номер перешел в режим call transfer, положил трубку до ответа набранного абонента это Transfer Unattended. соответственно поговорил с вторым абонентом положил трубку это Transfer Attended.

 

[ram_scan]

Длинковцы как всегда жгут напалмом. Перенаправление вызова это call forwarding. Нужно читать оригинальную документацию хотя-бы (по аглицки). Иначе нихрена не понятно что они там имеют в виду. Большинство дешевых девайсов трансфера не умеет. Потому-как больно через (_._) оно там в сипе реализуется.

[netch]

Длинковцы как всегда жгут напалмом. Перенаправление вызова это call forwarding. Нужно читать оригинальную документацию хотя-бы (по аглицки). Иначе нихрена не понятно что они там имеют в виду. Большинство дешевых девайсов трансфера не умеет. Потому-как больно через (_._) оно там в сипе реализуется.

А может быть расскажете конкретно, чем Вам не по вкусу методы трансферов SIP? (последняя надежда;))

 

 

[netch]

Нигде немогу найти информацию как перевести вызов на этом шлюзе. В описании на сайте написано что он это умеет, но как непонятно.

Раз это аташка (телефон подключается) - попробуйте перебрать вертикальные коды (звёздочка и две цифры) по какому-то из известных стандартов (обычный Centrex, ATA186, что-то иное). И всё-таки - речь про call forwarding или call transfer?

 

[ram_scan]

Тем что проключение плеча A-C вызывает (инициирует и выполняет сводя оба конца) абонент B, при этом если хотя-бы один из абонентов (хоть A хоть C, подразумеваем что у B все хорошо) не умеет правильно обработать метод refer (просто не поддерживает, или поддерживает неправильно, что щаще всего бывает) то соединение в лучшем случае не устанавливается, в худшем рассыпается, а люлей за это прописывают оператору. А коробочку которая не умеет трансфера в магазине выбирал пользователь сам, причем вовсе не тот кто трансфером хочет пользоваться и услугу эту оплатил. И потом начинаются предьявы "почему у меня входящий звонок срывается" или "почему я звонок трансферю а оно не отрабатывает я за это денег заплатил". И не обьяснишь что это какой-то совершенно левый чудак на букву м купил себе элитный девайс от дядюшки ляо сэкономив копеечку.

 

И сделать в рамках сипа по другому это дело крайне тяжело, если вообще возможно на разномастном парке оборудования. Кроме того остро встает проблема с MOH. Так что зря иронизируете.

[netch]

Тем что проключение плеча A-C вызывает (инициирует и выполняет сводя оба конца) абонент B, при этом если хотя-бы один из абонентов (хоть A хоть C, подразумеваем что у B все хорошо) не умеет правильно обработать метод refer (просто не поддерживает, или поддерживает неправильно, что щаще всего бывает) то соединение в лучшем случае не устанавливается, в худшем рассыпается, а люлей за это прописывают оператору. А коробочку в магазине выбирал пользователь сам, причем вовсе не тот кто трансфером хочет пользоваться и услугу эту оплатил.

Вот потому REFER должен отрабатывать свитч оператора. Что и делаем.

 

И сделать в рамках сипа по другому это дело крайне тяжело, если вообще возможно на разномастном парке оборудования. Кроме того остро встает проблема с MOH. Так что зря иронизируете.

Ну после того как я писал реализацию трансферов обоих основных видов в свиче - может, и могу иронизировать?;))

 

С MOH как раз проблем практически нет - его можно (при разумном ограничении по поддерживаемым кодекам) сделать на весь трансфер, или до того, как вызываемый начал отдавать ringback, или ещё как-то похоже. Из наблюдаемых - основные проблемы вызывает call leg recombination в случае зрячего трансфера, когда стороны изначально договорились на совсем разные кодеки. Вот тут приходится извращаться - заставлять их передоговариваться, и если некоторые не умеют (или вообще дропают звонок нафиг по re-INVITE) - суши вёсла. Но это как бы обоснованный риск.

 

Вы слишком пессимистичны и, судя по всему, работали с самым паршивым оборудованием, какое только досталось:) По моему впечатлению, чем больше производитель кичится своим брэндом - тем паршивее у него реализация. Сколько ещё это будет продолжаться - не знаю, но не один год.

 

[ram_scan]

Вы слишком пессимистичны и, судя по всему, работали с самым паршивым оборудованием, какое только досталось:) По моему впечатлению, чем больше производитель кичится своим брэндом - тем паршивее у него реализация. Сколько ещё это будет продолжаться - не знаю, но не один год.

На не то чтобы пессимистичен, реалистичен. Кривого оборудования - каждая первая железка... А клиент себе норовит купить всегда покривее, потому-что подешевше. Из недавних примеров. Шлюз тайнет-венус. Ну кто его просит отдавать ptime=0 при реинвайте ? И сиди кури, или городить под это дело в свитче воркэраунд, или сиди без голоса. Аддпак до сих пор при зрячем рефере искейпинг лега неправильно делает (в официально релиженом софте), плюс там непобедимые грабли с rfc2833 в виде dtmf stuck. Половина девайсов мьютить корректно не умеют, на холд звонок ставят, а в поле контакт себя оставляют. А сами ессно мох не дают. Это ладно если оператор сам же и девелопер своего свитча, тогда по юзерагенту можно сделать костыль чтобы оно мох играло в таких случаях, а если нет ?

 

А уж про то что девайс на реинвайт говорит в 200 что работает 711 кодеком, а rtp стартует 729-м я вообще молчу (у длинков сплошь и рядом было). Да еще два метода обновления сессии, причем ни один поддерживать необязательно... Нет коллега, это ментальный онанизм а не технология.И все грабли заключаются потом в том, как бы наипать децентрализованую технологию, чтобы все-таки ее централизовать, и воркэраундов в центре натыкать. Заставить работать конечно можно, но это надо быть вьюношей бледным со взором горящим, стар я уже для этого. Я хочу чтобы включил - и работает, у всех и одинаково.

 

Мне иногда того пассажира который сип в массы двинул расстрелять хочется. А потом второй раз посмертно. С более серьезными вещами то головняков по пояс... Про механизм рутинга так я вообще промолчу, с конференциями жопа полнейшая...

[netch]

Вы слишком пессимистичны и, судя по всему, работали с самым паршивым оборудованием, какое только досталось:) По моему впечатлению, чем больше производитель кичится своим брэндом - тем паршивее у него реализация. Сколько ещё это будет продолжаться - не знаю, но не один год.

На не то чтобы пессимистичен, реалистичен. Кривого оборудования - каждая первая железка... А клиент себе норовит купить всегда покривее, потому-что подешевше.

Это да. Но тем не менее ситуация уже значительно лучше, чем была года три назад. И вообще такая ситуация с любой технологией. С email было когда-то не лучше.;) Тем более что для SIP очень много делается для исправления - см. хотя бы RFC по torture tests, а также конференции SipIT, на которых проводятся живые тесты совместимости.

 

Из недавних примеров. Шлюз тайнет-венус. Ну кто его просит отдавать ptime=0 при реинвайте ? И сиди кури, или городить под это дело в свитче воркэраунд, или сиди без голоса.

Знаю, встречали, но с audiocodes MP-202. Более того, оно рядом написало "a=ptime:20" и "a=ptime:0", и сиди понимай как хочешь. Пришлось в конфиге его заменить, благо там был SER и это решалось тривиально.

 

Аддпак до сих пор при зрячем рефере искейпинг лега неправильно делает (в официально релиженом софте),

Да, это часто. Сегодня вот лог от snom320 подсунули - там в таком же месте URL не в <>, синтаксический разборщик это не всосал ибо не должен.

 

плюс там непобедимые грабли с rfc2833 в виде dtmf stuck. Половина девайсов мьютить корректно не умеют, на холд звонок ставят, а в поле контакт себя оставляют.

А почему Вы считаете, что это неправильно (я про mute)? По-моему, это единственный нормальный вариант. Из контакта вообще-то себя нельзя убирать в принципе. Если устройство не умеет свой MOH, значит, оно должно просто показать холд (любым из методов - a=sendonly, a=inactive, c=0.0.0.0), а дальше дело свича это отработать. В случае PSTN АТС ведь MOH генерирует станция? Так пусть свич это и делает, незачем на телефон сваливать, у него и так проблем достаточно.

 

А сами ессно мох не дают. Это ладно если оператор сам же и девелопер своего свитча, тогда по юзерагенту можно сделать костыль чтобы оно мох играло в таких случаях, а если нет ?

А зачем быть девелопером своего свича-то? Вот ставим операторам, те могут загрузить по вкусу MOH для юзеров и дальше он будет играть - тот, который назначен для того, что на холд поставили. Они сами в основном ничего не девелопят, только используют:)

 

А уж про то что девайс на реинвайт говорит в 200 что работает 711 кодеком, а rtp стартует 729-м я вообще молчу (у длинков сплошь и рядом было).

Да еще два метода обновления сессии, причем ни один поддерживать необязательно...

Это какие два метода? re-INVITE + UPDATE? второй да, необязателен, а первый вполне обязателен (см. RFC3264). Но UPDATE имеет смысл только при PRACK, а сам по себе PRACK это всё-таки достаточно угловой (jIMHO) случай.

 

Нет коллега, это ментальный онанизм а не технология.И все грабли заключаются потом в том, как бы наипать децентрализованую технологию, чтобы все-таки ее централизовать, и воркэраундов в центре натыкать. Заставить работать конечно можно, но это надо быть вьюношей бледным со взором горящим, стар я уже для этого. Я хочу чтобы включил - и работает, у всех и одинаково.

Вот именно что Вы пессимист. Стар или нет, но этот стакан у Вас уже всегда наполовину пуст. Я тоже уже далеко не вьюноша, но вижу, что 1) процессы таки идут, и на улучшение, 2) есть давление рынка, которое всё-таки приведёт всех ко вполне вменяемому результату. SIP безусловно не идеал (и граблей в нём дофига), но он перспективен, и сейчас это важнее. (В отличие от, например, IPv6, который и слишком крив, и бесперспективен.)

 

Я уже четыре года вожусь с SIP. Раньше было хуже. Раньше, например, кроме Sipura вменяемых юзерских UA не было в принципе. Сейчас и та Sipura в виде Linksys деградировала, и конкуренты подросли, так что есть что выбирать.

 

Мне иногда того пассажира который сип в массы двинул расстрелять хочется. А потом второй раз посмертно.

Нет никакого "пассажира" который это сделал сам по себе. Есть требования времени:

1. Должен быть стандарт IP-телефонии для Internet как единственного общего транспорта.

2. IETF должен его поддерживать и направлять.

3. Это не может быть H.323 из-за его закрытости и недоговорённости (есть масса проблем совместимости из-за недосказанностей и особенно из-за нечеловеческого стиля описания).

4. IAX ещё не было. MGCP слаб и не очень расширяем.

Что остаётся?

 

Вот выбор HTTP в качестве стилевой базы - мягко говоря, не лучшее решение. Но это IETF, и он иначе пойти (к сожалению) не мог. Расстреляете весь IETF?

 

С более серьезными вещами то головняков по пояс... Про механизм рутинга так я вообще промолчу, с конференциями жопа полнейшая...

Про конференции промолчу, не возился. А про рутинг - я в соседней ветке высказался предметно, Вы так и не сказали, что именно не нравится.

 

[ram_scan]

А почему Вы считаете, что это неправильно (я про mute)? По-моему, это единственный нормальный вариант. Из контакта вообще-то себя нельзя убирать в принципе. Если устройство не умеет свой MOH, значит, оно должно просто показать холд (любым из методов - a=sendonly, a=inactive, c=0.0.0.0), а дальше дело свича это отработать. В случае PSTN АТС ведь MOH генерирует станция? Так пусть свич это и делает, незачем на телефон сваливать, у него и так проблем достаточно.

Да фишка в том что если мне не отбило мой склероз до конца, то кроме a=sendrecv шлюз никера поддерживать не обязан, поэтому он замутиться может только отсылая свой контакт с нулевым адресом. А он не смотря на то что не умеет мох, отсылает свой. Так делали например натексы, если мне опять-же мой склероз не отшибло.

 

Коллега, фишка в том что вы имеете техническую возможность поставить воркэраунд на софтсвитч потому-что у вас есть исходники. Это хорошо. А у меня вот нет исходников, а вендор меня с инициативами накер шлет. И что мне делать. Равно как и остальным ? Не, базару нет, если ваш свитч имеет документы все нужные и разумный ценник я первый с челобитной прийду...

 

Это какие два метода? re-INVITE + UPDATE? второй да, необязателен, а первый вполне обязателен (см. RFC3264). Но UPDATE имеет смысл только при PRACK, а сам по себе PRACK это всё-таки достаточно угловой (jIMHO) случай.

Не, реинвайт он конечно "какбе" обязателен, но вовсе не факт что он отработает. Девайс обязан по стандарту если он "не может" не менять параметров сессии, и это единственная вещь которую девайсы достаточно исправно выполняют (хотя мне попадались уроды которые с 488 ошибкой дропались, причем что-то из рапространенного).

 

С организацией трансфера системой реинвайтов-реферов есть еще одна грабля. Чтобы замкнуть трафик для ртп проксирования (бфывет необходимо) на свитч надо городить "динамический ендпоинт", чтобы этот трафик в рамках рефера замкнуть обратно на себя (как это в референсном стеке сделано). Только вот я не видел ни одного свитча который этот финт понимает. 404 и досвидания. Например попробуйте opensbc таким образом взвести с чем-либо.

 

То есть все вроде оно хорошо и решаемо в теории. А на практике получается анекдот "в теории разници между теории и практикой нет никакой, а на практике разница между теорией и практикой..." Причем практика как правило наступает уже после того когда ты по крайней мере на двух вендоров залочился.

 

4. IAX ещё не было. MGCP слаб и не очень расширяем.

Что остаётся?

MEGACO/H.248. Там вроде всего хватает. Плюс, что важно, это жестко централизованый протокол. И всеми важными делами там занимается свитч. А не как в сипе, сначала придумали одноранговую фактически систему, а потом стали изобретать методы как в рамках стандарта от этого избавиться...

 

Про конференции промолчу, не возился. А про рутинг - я в соседней ветке высказался предметно, Вы так и не сказали, что именно не нравится.

Честно говоря не углядел там мессагу... Если вкратце, то одна кривая обработка rr по дороге и приплываем так что мало не покажется. Плюс принципиальное отсутствие хантинга из-за чего звонок "размножается" по всем доступным направлениям, а на стыке с ТСОП не факт что "дубликаты" отобьются с правильным cause code, чтобы их в узле где их форкнуло корректно пришибло. Кроме того поддержка rr опять же штука опциональная... То есть в стандарте написано вроде что "должен, но если не умеешь то ничо тебе не будет".

[Mikler]

Ну вот если отмазываем SIP подгадим на MGCP ; Просвитете меня гражданин чего нет в MGCP ?

[netch]

А почему Вы считаете, что это неправильно (я про mute)? По-моему, это единственный нормальный вариант. Из контакта вообще-то себя нельзя убирать в принципе. Если устройство не умеет свой MOH, значит, оно должно просто показать холд (любым из методов - a=sendonly, a=inactive, c=0.0.0.0), а дальше дело свича это отработать. В случае PSTN АТС ведь MOH генерирует станция? Так пусть свич это и делает, незачем на телефон сваливать, у него и так проблем достаточно.

Да фишка в том что если мне не отбило мой склероз до конца, то кроме a=sendrecv шлюз никера поддерживать не обязан, поэтому он замутиться может только отсылая свой контакт с нулевым адресом.

Читаю RFC3264 - насколько я его понимаю, sendrecv, sendonly и inactive входят в обязательный набор.

 

А он не смотря на то что не умеет мох, отсылает свой. Так делали например натексы, если мне опять-же мой склероз не отшибло.

С устройствами, которые начали разрабатывать ещё во времена SIP1, действительно, может быть дохрена проблем странной совместимости.

 

Коллега, фишка в том что вы имеете техническую возможность поставить воркэраунд на софтсвитч потому-что у вас есть исходники. Это хорошо. А у меня вот нет исходников, а вендор меня с инициативами накер шлет. И что мне делать. Равно как и остальным ? Не, базару нет, если ваш свитч имеет документы все нужные и разумный ценник я первый с челобитной прийду...

Документы - это сертификация? Увы, не занимаемся таким, AFAIR. Но если кто-то возьмётся помочь с этим - думаю, вполне можно договориться... по крайней мере я сброшу начальству все предложения такого рода.

 

Это какие два метода? re-INVITE + UPDATE? второй да, необязателен, а первый вполне обязателен (см. RFC3264). Но UPDATE имеет смысл только при PRACK, а сам по себе PRACK это всё-таки достаточно угловой (jIMHO) случай.

Не, реинвайт он конечно "какбе" обязателен, но вовсе не факт что он отработает. Девайс обязан по стандарту если он "не может" не менять параметров сессии, и это единственная вещь которую девайсы достаточно исправно выполняют (хотя мне попадались уроды которые с 488 ошибкой дропались, причем что-то из рапространенного).

Может не менять, действительно. "An offered stream MAY be rejected in the answer, for any reason." Хотя в нашей практике я мало видел тех, кто действительно так делает (вот из свежих жалоб - ругались про NexTone). Циска ведёт себя своеобразно - если не послал хоть что-то с нового адреса, может не принять его замену.

 

С организацией трансфера системой реинвайтов-реферов есть еще одна грабля. Чтобы замкнуть трафик для ртп проксирования (бфывет необходимо) на свитч надо городить "динамический ендпоинт", чтобы этот трафик в рамках рефера замкнуть обратно на себя (как это в референсном стеке сделано). Только вот я не видел ни одного свитча который этот финт понимает. 404 и досвидания. Например попробуйте opensbc таким образом взвести с чем-либо.

Что такое "референсный стек"? По-моему, такого нет в принципе. А что за финт, я, извините, таки не понял. Можно пример SDP?

 

4. IAX ещё не было. MGCP слаб и не очень расширяем.

Что остаётся?

MEGACO/H.248. Там вроде всего хватает. Плюс, что важно, это жестко централизованый протокол. И всеми важными делами там занимается свитч. А не как в сипе, сначала придумали одноранговую фактически систему, а потом стали изобретать методы как в рамках стандарта от этого избавиться...

Там не надо ни от чего избавляться, достаточно просто плюнуть на домены.:))

 

Про конференции промолчу, не возился. А про рутинг - я в соседней ветке высказался предметно, Вы так и не сказали, что именно не нравится.

Честно говоря не углядел там мессагу... Если вкратце, то одна кривая обработка rr по дороге и приплываем так что мало не покажется. Плюс принципиальное отсутствие хантинга из-за чего звонок "размножается" по всем доступным направлениям, а на стыке с ТСОП не факт что "дубликаты" отобьются с правильным cause code, чтобы их в узле где их форкнуло корректно пришибло. Кроме того поддержка rr опять же штука опциональная... То есть в стандарте написано вроде что "должен, но если не умеешь то ничо тебе не будет".

Умный хантинг предполагает ещё много чего такого, что не совместимо с идеей прокси. Для этого есть B2BUA.

"rr" - это что? Ваши сокращения мне всё-таки в заметной мере непонятны.