Комментарии 37
Вы меня конечно извините, но, если это в качестве примера как можно, то зачем это здесь, это же могут увидеть "дети" и потом попробуй отучи их так делать.
А если серьезно:
- Каналы типа Local это зло, есть же куча способов завернуть звонок на контекст
- ChannelRedirect/MASTER_CHANNEL это ж ад адский
- Астериск уже давно готов к интеграционным решениям и выносу логики обработки звонков на сторонние сервисы и именно по этому данная задача кажется слегка надуманной
P.S. Еще раз убеждаюсь что PJSIP ведет нас всех куда то не туда, ну или не теми путями ...
Чем PJSIP плох?
Он не плох, он не так хорош как Вы ожидаете/хотите.
Судя по всему вы знаете как я ожидаю/хочу
Собственно давайте в конкретику лучше:
Куда не туда вас ведет PJSIP и какие не такие пути он вам дает?
- Корявый Realtime, еще хуже чем в сhan_sip
- Нагрузка, на рабочих стендах не держит объемы, там где chan_sip отрабатывал.
- Текёт, ой как текёт, там где chan_sip кряхтел но отрабатывал, pjsip отсылает к памяти.
Претензия же, по поводу не верного пути, больше относится к PJSIP_DIAL_CONTACTS. Почему не сделать Dial(PJSIP....) и сразу все звонят? Нет, я могу понять, что не всегда нужен вызов всех зарегистрированных под учеткой и кодовую базу приложения Dial не хочется менять, но тогда смысл во множественной регистрации, если обработку её выносим из канала. Как то не логично.
15 и 16 астериски в большом проде на pjsip отрабатывают вполне спокойно нагрузку, большую чем в chan_sip. Не в разы, но проценто это 12-15% прироста стабильно. Работает годами, не течёт. Я не спорю что у него есть проблемы, но их не меньше чем у chan_sip. Зато решать проще. Код понятнее, и в целом лучше. Да и не приходится таскаться с пачами. Залил а mainstream и его быстро приняли.
Отдельная функция PJSIP_DIAL_CONTACTS добавляет гибкости при реализации. Может у меня своя реализация DND которая на сервере, потому что нет её на окорочка в моем офисе, или я хочу её специфично отрабатывать, например, а может я очереди имплементировал через call forking? Не вижу в ней проблемы. Ну точнее она субъективна.
Работает годами, не течёт
16-й, я вас умоляю, видимо ваш "большой прод" большой только по вашим меркам. Вы же за конкретику, давайте цифры. Объёмы, окружение, организация учеток, тип трафика, количество и т.д. и т.п.
Без таких данных, это все пустые слова, не более.
Отдельная функция PJSIP_DIAL_CONTACTS добавляет гибкости
Пришли к тому с чего начали. Нужна мне в очереди фича вызова всех зареганных из под учетки — костыляем контексты и локал. Это не субъективно, а объективно, херь какая то.
Вы очень много объективности отдаёте своей субъективности. Я не говорил о фиче вызова в очереди всех зарегистрированных. Я как раз говорю об обратном: использовать встроенную возможность протокола. И да, добавление механизмов это гибкость. Обычно гибкость называют херью когда не умеют ею пользоваться.
16-й, я вас умоляю, видимо ваш "большой прод" большой только по вашим меркам.
Вы можете думать как вам угодно,
По цифрам: есть сервис где н несколько миллионов минут в день тут регистрации вынесены на proxy registrar.
Тип трафика: что именно интересует? Транспорт? TCP/UDP.
Есть танзит" и не "не транзит". RTP через asterisk. ARI как интерфейс взаимодействия с окружением.
Есть проекты где pjsip работает и как registrar. Там объёма трафика поменьше, - но нагруженность в целом не очень меньше: там больше сервисов задействовано Последний раз pjsip именно "тек" на 12 версии. У него есть болячки конечно, но не в утечке памяти они уже.
Несколько миллионов минут в день — это сколько, от X до Y? Сколько пиров льют эти несколько миллионов — 5k,100k? Proxy registar что то типа kamailio или такой же asterisk?
Вы меня извините, не хочу показаться занудой, сильно сладко получается по рассказам.
Такие объемы пускать(даже если пускается) на одном сервере не распределяя, сомнительно как то.
Так я не говорил про один сервер. Вопрос был в объёме трафика а не в количестве серверов. Конечно же это кластер.
Прокси регистрар - это kamailio. Asterisk это b2bua. Он не может быть прокси по определению.
Ответьте пожалуйста и на предыдущие?
del
Количество минут в день говорит только о размере сервиса и его общей нагрузке. Просто чтобы указать что это не 2.5 звонков в день. конкретные цифры говорить не буду. И права не имею и в целом это не будет каким либо показателем.
Мы же сравниваем производительность pjsip c chan_sip при одинаковой нагрузке на экземпляр поэтому размер кластера не имеет значения. Но если сильно интересно то это несколько десятков машин around the globe.
Характеристики машин разные в зависимости от локаций серверов и потребностей. В целом это 4 ядра и от 8 до 16 гб оперативки на машину.
Кластер так же динамический и умеет скалировться предиктивно исходя из прогнозируемой пиковой нагрузки. Ну я думаю это очевидно что никто в своем уме и здравой памяти не будет держать инфраструктуру под предельной нагрузкой.
После перехода на pjsip нам нужно чуть меньше экземпляров машин чтобы обслуживать тот же поток траффика.
В конкретно этом проекте пир всего один на машину и он ip2ip trunk до proxy/registrar
А не кажется вам, что ваш высоконагруженный сервис выдуманный?
> Мы же сравниваем производительность pjsip c chan_sip при одинаковой нагрузке на экземпляр поэтому размер кластера не имеет значения.
Как мы ее сравниваем если вы данные по нагрузке не даете.
А не кажется вам, что ваш высоконагруженный сервис выдуманный?
При желании легко гуглится где я работаю.
Как мы ее сравниваем если вы данные по нагрузке не даете.
Сделайте нагрузочный тест и сравните.
Но если сильно интересно то это несколько десятков машин
Несколько десятков машин, несколько миллионов в день…
Но это правда, мамой клянусь, есть такой сервис в природе.
Добро / зло, снова философия... все относительно.
А если серьёзно: буду признателен, если предложите способ решения поставленной задачи без local и redirect. Пока я убеждён, что описал наиболее оптимальный вариант реализации.
Бытует мнение, что философия, между прочим — это мать математики/физики.
Если уж на то пошло, то я не против Redirect'а, я против связки Redirect/MASTER_CHANNEL и мне кажется очевидным почему.
То, что касается способа решения, то вам как, как у вас или как надо? Если как у вас, то самый простой и красивый вариант, без лишних каналов и засирания CDR — это эмуляция peer'а
Action:Originate
Channel:SIP/201@127.0.0.1
Application:wait
Data:30
Callerid:203Естественно подгоняем контекс default(именно туда такой звонок и придет)
Если же вдруг с default проблемы то делаем пира, скажем local
[local]
type=peer
context=local
host=127.0.0.1
deny=0.0.0.0
permit=127.0.0.1
....И уже в контексте local делаем все безобразия которые нам нужны.
Вот как то так ....
И чем Ваш пример лучше того, что предложил автор?
Нет, серьёзно, пример автора мне самому не очень нравится, ни с технической, ни с эстетической точки зрения, просто возможно у них в freepbx/askozia/mikopbx нет другого выбора, так сказать окружение не позволяет.
Но, объективно, если нет ни какого профита то может и не стоит заморачиваться.
P.S. Сам нахожусь в состоянии мучительного выбора, ставить ли сборку aka freepbx и не придется ли, в последствии, заниматься «лапшекручением» в простых на первый взгляд задачах…
Я правильно понимаю, что wait указан для примера, а в реальности там должен быть контекст для второго плеча?
Нет, не правильно. Wait тут нужен лишь для originate, что бы он был доволен. Originate нужно второе плече, с таким же успехом мы можем задать:
...
Aplication:Wait
Data:0
...Вся магия в контексте default/local.
И чем Ваш пример лучше того, что предложил автор?
Да практически всем:
- нет "рысканья" по channel-space
- нет redirect'а по переменной с заворотом в контекст и что самое больное два раза, ибо local канал
- нет ненужного hangup'а, а без него уже типа грязный CDR
- и бог его знает еще чем
Зато в моем примере имеем чистый, линейный диалплан с синхронным выполнением и без кучи телодвижений.
В качестве примера и по мотивам автора:
[local]
exten => _.,1,Goto(local)
exten => _.,123(local),NoCDR()
exten => _.,n,Set(_CALLEE=${CALLERID(num)})
exten => _.,n,Dial(SIP/${EXTEN},30,G(cross^${EXTEN}^1))
exten => _.,n,Hangup()
exten => _[hit],1,NoOp()
[cross]
exten => _.,1,goto(caller)
exten => _.,2,goto(callee)
exten => _.,100(caller),Wait(1)
exten => _.,200(callee),Set(CALLERID(num)=${EXTEN})
exten => _.,n,Dial(SIP/${CALLEE},30,tT)
exten => _[hit],1,NoOp(=== SPAWN EXTENSION ===)
exten => _[hit],2,Verbose(=== SPAWN EXTENSION ===)А вообще, этот таск лучше реализовывать сооовсем по другому, причем кардинально ...
и как же?
Уже давно агитирую за упрощение процесса "пищеварения" для астера, астер уже не торт и с каждым новым релизом это проявляется все ярче и красочней.
Один из способов — это упростить астеру жизнь, сделать из него медиа-хаб, простые примитивы(answer/hangup/redirect/bridge/etc), а логику и телодвижения выносить на сторонние сервисы.
Астериск уже давно готов к интеграционным решениям, ARI/FastAGI/etc.
Такие вещи, как в посте, реализовываются при таком подходе вообще прозрачно и без каких нибудь умственных страданий.
Хорошо быть героем - приходишь в проект где уже все построено и такой- давайте все перепишем! А задуматься над тем насколько это выгодно финансово для проекта- вложить кучу человекочасов в то чтобы никто из клиентов ничего не заметил - это конечно не царское дело.
А Вы видимо агетирует за стагнацию, как было написанов 2000-ых так и шпарим дальше.
Без развития любой проект обречен в лучшем случае на безвестность. А развитие, в свою очередь, предполагает некоторое проектирование, а не тяп ляп и в продакшен.
Но кто я такой чтобы говорить об этом.
Я агитирую за здравый смысл. Мир не ограничивается двумя цветами.
Не все проекты готовы на миграцию на новое АПИ финансово и это нормально.
А еще нормально это понимать.
Если есть наработанная кодовая база на dialplan + AMI и она работает зачем все бросать и перепиливать все под чистую на ARI если этого не требует сервис?
Менять подход нужно тогда когда он перестает работать и когда с используемыми методами framework начинается борьба. А просто прийти и сказать со стороны "у вас тут все неправильно, вам нужно все начать сначала и написать с нуля" - не прагматичный подход.
Мир не ограничивается двумя цветами
Какие два цвета, о чем Вы...
Мне кажеться, что Вы путаете мягкое и теплое, в чем противоречия:
- Осмысленный подход к проектированию
- Интеграция уже имеющейся кодовой(диалплан/ami/agi) базы со сторонними сервисами
- Четкое понимание того, что гадить в диалплан нужно осмысленно, с понимание того что в итоге получиться
- Хоть какое то понимание о нагрузке/производительности в итоге
Вы считаете, что это НЕ нормально?
перепиливать все под чистую на ARI если этого не требует сервис
Такое впечатление, что Вы проецируете свои профессиональные комплексы прямо сюда. Ну не срастается у вас с ARI, так и черт с ним.
Прочитайте мой пост, я там более чем доходчиво высказал свое мнение про ARI и иже с ними.
А просто прийти и сказать со стороны у вас тут все неправильно
Откуда Вы вообще взяли все эти фантазии, где упоминалось об — "вам нужно все начать сначала и написать с нуля". И вообще, такое впечатление, что вы не слишком поняли то что я пытался донести своими коментариями.
Что ж, очень жаль
Я не считаю это не нормальным осмысленность в понимании того, чем сервис занимается и продумыванием архитектуры взаимодействия сервисов между собой, но я считаю, что проблемы нужно искать там, где они есть, а не придумывать и высказывать их из пальца.
Касаемо того, что я не слишком понял вас: сорян, как у вас написано- так и понял. "Такие вещи как в посте" реализуются вполне в диалплане без дополнительных сервисов. Это вполне простая работа.
Ваше предложение касаемо улучшения диалплана вполне обосновано, но "агитировать" выводить подобные вещи во внешний сервис когда обработка вполне базовая и делается 3-мя строками диалплана через стандартные команды набора - не находите, что это overkill?
Какой бонус от этого? Это не распределенная задача, здесь нет обработки 3-м сервисом доп данных. Подменить callerid на правильный и отключить CDR вполне себе задача астериска которая отлично делается "изнутри" . Зачем это делать через AGI/AMI/ARI? Какой от этого профит? Зачем тут привязывать эту "агитацию"?
Я повстречал и тех кто все лепит в диалплан, и тех кто ВСЕ выносит из диалплана просто потому, что не понимает как это работает. И именно поэтому у меня нет проблем с интерфейсами и API различных систем. Я знаю и умею их применять тогда когда то или иное API нужно.
И да, ваш пост я читал. Америку лично мне вы не открыли.
Ну и раз уж речь зашла: использовать однопоточный Lua как external сервис приложений ( вы же знаете что корутина блокирует выполнение других задач ) - сомнительная идея.
но я считаю, что проблемы нужно искать там, где они есть
Складывается такое впечатление, что где-то там в offline Вас насильно заставляют юзать интеграционные решения вместо теплого и уютного диалплана. А как же развитие?
сорян, как у вас написано-так и понял
Нет, вот именно, Вы поняли так как Вам хочется. Искусственно создали причину и пытаетесь в чем то меня переубедить. Вы думаете что я не понимаю целесообразность того или иного подхода? Ошибаетесь, именно потому, что предложил свои правки. Но, Вы как то узко зацепились за примитивную задачу и доказывает очевидное. Реальные системы не останавливаются на примитивах cid/cdr, есть связи с системами биллинга, статистики, мониторинга и т.д. и т.п. Сюрприз, сюрприз, иногда нужно межсистемные взоимодействия в обе стороны. В таких случаях продолжайте комуницировать как хотите, а я буду настаивать, что интеграция со сторонними сервисами(там где это уместно) пока наилучший вариант.
использовать однопоточный Lua как external сервис
Пока условный Вы будете возится с IPC, консистентностью и синхронизацией разделяемых данных в многопотоке, условный я будет просто обрабатывать звонки.
корутина блокирует выполнение других задач
Судя потому, что Вы это пишите, Вы не слишком понимаете в кооперации. Если это не так, то Вы должны были слышать о C10K и как проблема успешно решалась с использованием кооперативной многозадачности. Из примерно 10K условных соединений сдохнет скорее Астериск и pjsip в частности, а не external сервис на корутинах(при условии написания в кооперативном стиле).
Ваше принципиальное заблуждение — "корутина блокирует выполнение других задач", а смысл как раз противоположен. Корутина уступает контекст выполнения при простое/ожидании.
PreFork/etc в highload в 21-м году мало кто рассматривает, а вот асинхрон и событийный подход да, как Вы думаете почему?
Складывается такое впечатление
Оставим вашу впечатлительность с вами на едине.
Я понял так как написали:
Такие вещи, как в посте, реализовываются при таком подходе вообще прозрачно и без каких нибудь умственных страданий
Пока условный Вы будете возится с IPC, консистентностью и синхронизацией разделяемых данных в многопотоке, условный я будет просто обрабатывать звонки.
Мир не стоит на месте. С потоками давно уже все проще чем вы представляете. Особенно с подобными вашим задачам.
Ну и я не агитирую писать исключительно на форках/мультитредах. Я о другом: при всей моей любви к Lua брать его именно чистую имплементацию без обёртки в LVM менеджера - спорное решение хотя бы потому, что вы задействуете только 1 ядро вашего сервера. Такова изначальная природа Lua. Это встраиваемый язык.
Если уж сильно хочется Lua: напишите свой менеджер LVM тогжа уж или используйте OpenResty, что там ещё... HАproxy? Да можно даже камаилио использовать через evapi в качестве сервера TCP приложений и нормального LVM manager. Ну и если не ограничены в языках: есть Go с его Goroutines. Он быстро учится и легко пишется.
Сегодня у вас 1 астериск, завтра 10. Сегодня у вас все на одном сервере крутится, завтра приложение уйдёт в условный k8s.
Вы же за развитие и за продуманную архитектуру сервисов, пишите умные вещи и неплохие статьи, а стреляйте себе в ногу уже в самом начале... я думаю далее этот диалог ( именно касаемо lua ) если уж сильно хочется можно продолжить на asterconf.ru: обсуждение одного поста в другом мне кажется неправильным с точки зрения этого рессурса ( раз уж я это начал, я это и постараюсь завершить) Ну или можете в ваш следующий ответ касаемо lua линкануть с этим диалогом и продолжим под правильным постом.
можно продолжить на asterconf.ru
Это началось здесь и закончится должно тоже здесь. У Вас какая то каша, куча штампов и стереотипов. Но вы не переживайте я вам помогу разобраться.
Я понял так как написали
Чукча не читатель, чукча писатель…
Ещё раз, напишу по другому. Вы же должны понимать степень упрощения задачи. Возможно, где то и есть сервер, единственной задачей которого, является originate, без проверок и связей. Так вот, проецируйте мой пост для всех остальных случаев, там где есть хоть какой то бэкгроунд.
С потоками давно уже все проще чем вы представляете.
Да что Вы, правда. А ну ка, расскажите мне, как наши космические корабли бороздят просторы Вселенной… Что там существенно поменялось/упростилось. Если в вашем фрэймворке/либе(чё вы там используете) реализован слой абстракции, упрощающий написание мультипотокового приложения, то это мимо кассы. Под капотом то же IPC, блокировки и иже с ними.
Ещё раз — передача контекста выполнения в многопоточном приложении, в определенный момент, под нагрузкой, становится слишком дорогим и по*еру сколько у вас ядер.
брать его именно чистую имплементацию без обёртки в LVM менеджера — спорное решение хотя бы потому, что вы задействуете только 1 ядро вашего сервера. Такова изначальная природа Lua. Это встраиваемый язык.
Вы путаете причинно следственную связь. Lua и однопоток — это все следствие асинхронности она обязательное условие. Именно она дает значительный boost при работе с данными, общими. Openresty/Nginx, HAproxy да и Kamailio не дают сохранения состояния(разделение контекста/окружения между двумя параллельными вызовами) и общий доступ — это не то пальто. Юзать такие LVM, ради многопоточности, спорное решение.
При разработке ни одной ноги не пострадало, в продакшене это решение реализовано в окружении tarantool'а. А там(опять сюрприз) сервер приложений в одном потоке.
Да как же так то...
Чукча не читатель, чукча писатель…
Ещё раз, напишу по другому.
Вы пишите одно, а оказывается подразумеваете другое. Я не должен угадывать, что у вас там в голове и что вы имели ввиду. Сразу написали бы нормально и вопросов не было бы.
Юзать такие LVM, ради многопоточности, спорное решение.
Вот уж действительно. Наверное именно поэтому nginx ставят перед кластером nodejs, а не наоборот, исключительно чтобы укратить nodejs, а то ну слишком быстрый он. Именно поэтому kamailio c его fork на старте положить та ещё проблема. Все потому, что решения - полное г*но и спорные.
Openresty/Nginx, HAproxy да и Kamailio не дают сохранения состояния(разделение контекста/окружения между двумя параллельными вызовами) и общий доступ
Да и пусть не дают. А собственно почему это такой краеугольный камень? Каждый сопроцесс изолирован, получает задачу от роутера процессов. Да, стартует дольше и подключает либы каждый сам, да не шарит контекст, но все это решается или локализацией данных или прокидыванием через внешние источники типа shmem/redis/htable. Статику вычитываем при изменениии кэшируем. Done. Более того, это ещё ещё читать потом проще, нежели искать - а что тут контекстное, а что не контекстное.
Если данные динамические - пишем и читаем постоянно. Тут даже вас процитирую.
При разработке ни одной ноги не пострадало
И заодно отвечу: значит не требуются пока задачи по масштабированию. А тут как раз понадобится что то "с хреновой и слишком дорогой архитектурой" типа haproxy или какого нибудь другого прокси. Ведь окажется что вы утыкаетесь в производительность однопоточного сервиса гораздо раньше чем хотели бы этого. И станет ваш однопоточный сервис просто библиотекой многопоточного сервиса...
Ещё раз — передача контекста выполнения в многопоточном приложении, в определенный момент, под нагрузкой, становится слишком дорогим и по*еру сколько у вас ядер.
Действительно. Не буду тут писать ещё раз пример с openresty и kamailio.
Вы зачем-то так сильно завязываеьесь на контекст в своей аргументации что забываете о том, что им можно и не оперировать, особенно с таких прикладных задачах как ваша...
Что там существенно поменялось/упростилось.
Под копотом - ничего, но вы же аргументировали изначально это тем , что это долго и сложно:
Пока условный Вы будете возится с IPC, консистентностью и синхронизацией разделяемых данных в многопотоке, условный я будет просто обрабатывать звонки.
А теперь вдруг переобулись в то, что это неэффективно оказывается, что это просто блажь с которой вообще непонятно зачем возились и до сих пор возятся, а проекты, построенные на этих принципах как работали быстрее так и работают.
Вы скажете- это древнее г-но мамонта, которое уже никто не использует, но вдруг неожиданно мы видим JANUS sfu проект который написан в 21 веке и является одной из самых популярных и быстрых SFU которая использует preFork. Medooze: pthreads, mediasoup: pthreads. Посмотрим на тесты: https://webrtchacks.com/sfu-load-testing/...
Дальше сами...
Какой то бесконечно бессмысленный спор получается. Думаю, я на этой ноте оставлю вас на едине с собой. Побуду со своей кашей и стереотипов в голове наедине.
Вот уж действительно. Наверное именно поэтому nginx ставят перед кластером nodejs
А когда это в нашей дискуссии передергивание стало заходит как аргументация? Че так можно было…
Я вам про теплое, Вы мне про мягкое. Не зачет.
Да и пусть не дают.<...>Да, стартует дольше и подключает либы каждый сам, да не шарит контекст, но все это решается или локализацией данных или прокидыванием через внешние источники типа shmem/redis/htable.
Я Вас правильно понимаю, что агитация(то что вас и подорвало изначально) за AMI/AGI/ARI сервисы в простых задачах это зло, а то же самое но в вашей интерпретации это уже добро. Чет тут кто то сам себе противоречит.
Статику вычитываем при изменениии кэшируем. Done. Более того, это ещё ещё читать потом проще, нежели искать — а что тут контекстное, а что не контекстное.
В моем предложении, вот всего этого просто не нужно, данные, состояние, оно вот оно, перед вами. Нет необходимости в shmem/redis/htable, а с tarantool'ом мы еще и базу/умный кэш имеем.
Ведь окажется что вы утыкаетесь в производительность однопоточного сервиса гораздо раньше чем хотели бы этого
Вы не можете аргументированно спорить на эту тему, так как не понимаете/не вникали в архитектуру, это спор ради спора.
Вы же в курсе(я надеюсь), что ваша многозадачность — это псевдо многозадачность. Реальный параллелизм вы получите на многопроцессорной системе и только на ней. В таком контексте Ваше замечание про 1 ядро становится мягко говоря не состоятельным.
Что вам мешает запустить энное количество экземпляров на каждом ядре вашего сервера, возбуждаясь каждый раз от осознания того что оно многозадачное.
А теперь вдруг переобулись в то, что это неэффективно оказывается, что это просто блажь с которой вообще непонятно зачем возились
Опять двадцать пять — это ваши домыслы не более, весь тред перед вами, ткните где я однозначно высказался про ненужность. Есть такое понятие — целесообразность, вами же к стати предложенное.
В общем — слова как лава горячи, но смысла мало в них, увы.
Давайте притворимся, что я с вами согласен и действительно закончим на этом и по PJSIP то же!
Если уж на то пошло, то я не против Redirect'а, я против связки Redirect/MASTER_CHANNEL и мне кажется очевидным почему.
Явных проблем в конкретном случае я не вижу. В текущем примере MASTER_CHANNEL — это всегда Local канал. Local каналы всегда существуют парами.
Конечно, перед вызовом этой функции следует добавить проверку существования канала, это сделано в develop ветке Mikopbx, тут же примеры описаны упрощенно.
Опять же есть сомнения по поводу «красоты» и правильности итоговых данных в CDR.
Я попробую ваши примеры, но пока не вижу как в них решается задача с множественной регистрацией.
Явных проблем в конкретном случае я не вижу.
Почему то уверен, что вы их и не увидите, по крайней мере на нагрузке среднего/малого офиса. Но плохой стиль проектирования ни куда не денешь, в будущем аукнется.
Объективно, по возможным причинам будущих проблем выше отписался.
Опять же есть сомнения по поводу «красоты» и правильности итоговых данных в CDR.
Не сомневайтесь, все там как и требовалось, одна запись:
"SIP/201-00000033","SIP/203-00000034","Dial","SIP/203","2021-05-27 15:51:03","2021-05-27 15:51:16","2021-05-27 15:51:22",19,6,"ANSWERED","DOCUMENTATION"но пока не вижу как в них решается задача с множественной регистрацией.
Да абсолютно так же, меняем канал с chan_sip на pjsip и впихиваем PJSIP_DIAL_CONTACTS везде где нужно.
Asterisk. И снова AMI Originate