вывод о элементарности я сделал основываясь на:
- здравом смысле
- теории программирования
- логики работы протокола

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

если есть серьезные аргументы, то выкладывайте, нечего про "права" рассуждать. Может эта фича и будет для меня поводом начать возню с исходниками астера.

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

Ну и утверждать что вы "как минимум представляете как это сделать" есть изначально несколько некорректно. Чтобы знать как поддержать множественные регистрации требуется знать в каких структурах chan_sip хранит данные о пирах, из каких функций и как он их ищет, как происходит регистрация сейчас и прочее. Что подразумевает если не интимное то хотя бы поверхностное знакомство с кодом chna_sip :) А из вашего поста следует что это знакомство пока не состоялось. А это значит что вы пока просто имеете представление что вы будете делать чтобы поиметь представление о том как это заиплементить :) То есть на один шажок дальше.

Там нет ничего сверхъестественного, в конце концов это просто код. Но я уверен что это сложнее чем вам сейчас кажется. Присоединяйтесь к девелопменту и докажете мне обратное убив при этом еще десяток другой зайцев - в итоге в выйгрыше будут все :)

Парни, а может "игра не стоит свеч"? Ну да, приятно писать Dial(SIP/${EXTEN}), и это работает в большинстве случаев. Звонить на 2 регистрации с разных очень похоже на звонок в разные каналы, как заметил dimas. Поэтому, когда важно дать пользователям возможность принимать звонок на разные SIP девайсы, надо уходить от логики Dial(SIP/${EXTEN}), и переходить к реализации своей бизнес логики, по которой номер отвязан от пиров. Пример: абонент (номер) = экаунт, и позволять ему самому создавать себе пиры в IAX2/SIP (через realtime, например). При звонке на номер искать, какому абоненту он принадлежит, и если такой найден, искать, какие пиры он себе насоздавал, и строить строку вызова Dial(SIP/vasea1&SIP/vasea2&IAX2/vasea3).
Мне нравится minimalistic approach, когда инструмент дает минимум необходимого, и не мешает стоить сложные вещи :-)

litnimax, согласен, нужно отходить от этого, но заказчикам иногда трудно объяснить почему так нельзя сделать. В общем случае фича из разряда "если совсем нечего делать, то сделаю".

dimas, вы так и не привели ни одного аргумента, кроме моего незнания сути вопроса.
мне нет необходимости разбираться в тонкостях конкретной реализации, я знаю протокол и умею думать. заменить одну переменную массивом и перебирать в цикле - думаю это элементарно.
возможно придется повозицца.

Итог: все это ложь, пи$%еж и провокация. нефиг по этому поводу ссорицца, ибо оно того не стоит.
Хотя если бы dimas рассказал что-нить интересное про код chan_sip, думаю всем было бы полезно.

switch, calm down. dimas знает, о чем говорит, это точно. Смотри bugs.digium.com karma of flame, или как она там называется...
Я обдумывал тему, и пришел к выводу, что добавление этой фичи противоречит принципу KISS (Keep It Simple, Stupid). Больше сложностей - больше кривостей и багов.
Я бы закрыл на этом тему, спасибо всем за комментарии.

чиста поржать - если вам чего-то не хватает в регистрации SIP, может, выставить к астериску другой backend? openser, например (вроде он сейчас по-другому называется)

и как ты это видишь? Или просто так предложил? :-)

да именно как и предложил - выносим регистрацию на опенсер. чтобы логины/пароли хранились на нем и он же был сип-прокси для телефонов.
на * реализовывать только медиа-шлюзы в другие технологии + его собственные чудеса типа ИВР-а, войсмейла и проч. а астер бы на него звонил SIP/openser-ip/${EXTEN}. а сколько под этим самым экстеном агентов зарегистрировано - не его дело.

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

По мне так в системе должно быть два понятия: user и device.
User описывает именно юзера - его extension, логин, пароль, разрешенные фичи и тд.
Device - это просто оконечное оборудование (терминал) через которое user может собственно инициировать и принимать звонки. Это может быть SIP, IAX, H323 и тд. Также это содержит device id, device password и другую свазанную с устройством инфу.

Каждый device может быть связан с юзером.
Тоесть например переехал на другое рабочее место на работе а там например другой телефон на столе стоит - в PBX достаточно просто связать юзера с другим девайсом и все.

А кому-то это не подходит! Текущая реализация полностью отвязывает extension от пира, и это здорово! А твой подход уже навязывает твое видение! Даешь minimalistic approach!