Правильно описать входящий Trunk для разных линий с одного IP

это всее работает исключительо изза крутизны вашего провайдера. iptables НЕ подменяет внутри пакета адреса. а сип базируется не на адресе откуда пришел, а на самом пакете обычно. вобщем не рекомендую так делать

Провайдер самый обычный. Провайдер этой подмены вообще не видит, всё происходит внутри стека сервера телефонии. Попробуйте у себя, поделитесь.

угу. у меня то опыта совсем нету, это я так,фигней маюсь. еще раз. iptables не менет пакеты. только заголовки

Я рад, что Вы фигнёй занимаетесь, но так-то тут люди для работы обычно пишут, про проблемы. Не мешайте.

да не вопрос. работайте.

все ответы в других темах будут удалены. ибо подход неверный.

Я просто хочу помочь всем, кто столкнулся с этой проблемой, разве это плохо? Пусть берут и пользуются. Никакого другого решения я больше не видел, да и судя по ответам авторов, они просто слили этот вопрос или забили на него. Что не так то?

да. плохо. ибо ваше решение некорректно и работает в очень малом количестве случаев. вы даже похоже не понимаете ПОЧЕМУ некоректно.

Если Вы считаете, что моё решение некорректно - объясните почему.

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

я вам обьяснил почему. по rfc необходимо брать информацию для авторизации из пакета,а не из адреса откуда занатилося. информация в пакете НЕ МЕНЯЕТСЯ в вашем "решении". потому это решение с точки зрения СТАНДАРТА протокола некорректно. иногда может работать. на тех провайдерах которых такие умные уже достали и они сделали на этот случай хак.

а. вы еще и contrack_sip включили. ну тогда вообще в пакете может быть что угодно.

Давайте я с Вами соглашусь. Это - неправильный подход, когда авторизация идёт по ip адресу, хотя она и предусмотрена в астериске. Правильный подход - авторизация по invite. Мультифон в инвайте мне шлёт в поле FROM: адрес звонящего. Есть адрес который можно использовать для авторизации в поле TO: - там указан телефон, куда идёт звонок. Собственно вопрос: каким образом сделать авторизацию корректной? match auth username = yes

asterisk разрабатывалься как ДЕШЕВАЯ замена офисным PBX. никого вообще не волнует ваш случай, ибо он СИЛЬНО усложняет ядро сип стека и отладку и КРАЙНЕ редко используется.

У меня вот такие условия - астериск используется как шлюз звонков для службы такси, у меня руки связаны - я не могу убрать астериск, вся логика программы на этом висит. Один сип-провайдер даёт мне 2 транка, но у него 1 ip. В зависимости от того на какую линию пришёл звонок - должен включаться разный класс услуг в программе такси, это аксиомы под которые я должен подстроить астериск и программу такси. Да, я с Вами согласен, что неправильно авторизоваться по "подставленному" IP (и вообще авторизоваться по IP), но я вообще никак иначе авторизоваться при INVITE не могу, астериск не позволяет сделать это на тех условиях, в которых провайдер предоставляет телефонию - даже не используя iptables и conntrack - у меня в поле FROM телефон звонящего. Вы меня критикуете за "несоотвествие стандарту", но Вы вообще не предлагаете альтернативного варианта в этих условиях, это неконструктивный диалог.

Два дня просматриваю логи по вечерам, вижу - провайдер в принципе не передаёт авторизацию в процессе передачи звонка (invite от сервера к asterisk, invite от asterisk к серверу, ack от сервера к астериску и тишина), и наконец меня озарило. Это же паранойя. Asterisk с точки зрения провайдера - это очередной СИП-телефон. Серверу СИП-провайдера слать пакеты с авторизацией на сип-телефон, который перед этим регался на сервере - абсурд. Всё правильно, type=peer - самое нужное тут. Если же очень сильно хочется всё-таки проверять, соответствует ли звонок регистрации, то можно назначить экстенжн с невероятным сложным именем, и проверять его во входящих.