FXS, 1IND: Реализовать overlap dialing через IP

[alx]

По опыту замены нашей аппаратурой старых координатных АТС с использованием сигнализации индуктивным кодом операторами отмечалось, что время соединения становится больше. Это объясняется тем, что старые координатные АТС, приняв первую цифру номера, сразу занимали соединительную линию и начинали трансляцию последующих цифр в эту соединительную линию в процессе набора номера абонентом. В отличие от этого, плата VE-01 сначала накапливает у себя полный номер, и только после окончания набора номера вызывающим абонентом занимает соединительную линию и начинает передавать туда номер. Как результат, суммарное время набора увеличивается.

Предлагается реализовать функцию overlap dialing через SIP примерно по следующему сценарию:

1. Абонент FXS снимает трубку и начинает набирать номер.
2. Как только абонент набрал первые цифры, достаточные для определения направления (допустим, это "12"), канальное окончание FXS отправляет INVITE c этими двумя цифрами (12@…).
3. INVITE принимается канальным окончанием 1IND, который занимает соединиртельную линию и начинает передавать в нее цифры "1" и "2" обычным образом.
4. Абонент канального окончания FXS продолжает набор - и набирает третью цифру. Пусть это будет цифра "3". Канальное окончание FXS отправляет в сеть новое сообщение INVITE, на этот раз на URI 123@…, содержащее поле Replaces с указанием реквизитов ранее установленного диалога.
5. Канальное окончание 1IND, уже занятое предыдущим вызовом, принимает новый, убирает из "123" уже переданные цифры "1" и "2" и передает в СЛ цифру "3". На ранее принятый INVITE канальное окончание отвечает "484 Address Incomplete".
6. Так повторяется, пока абонент FXS продолжает набор.
7. Когда из СЛ придет ответ, канальное окончание 1IND даст ответ "200 OK", и соединение перейдет в состояние разговора.

Насколько я понимаю, для работы такого сценария требуется, чтобы цифр номера в самом первом INVITE было достаточно для правильной маршрутизации вызова, так как, один раз послав INVITE одному окончанию, мы вряд ли сможем потом "передумать" и работать с другим (а если первое сразу ответит "Busy"?). Поэтому предлагается конфигурационный параметр, устанавливающий минимальную длину префикса, после набота которого разрешается overlap dialing (в приведенном выше примере это 2).

Прошу комментировать и критиковать.

[san]

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

[alx]

Replying to san:

А можно использовать существующий механизм на основе параметра "Регулярное выражение набора" для отправки первого INVITE ?

Навреное можно... Не вижу причины, по которой было бы нельзя. :)

[alx]

Оказывается, ​RFC:3891 допускает прием INVITE с Replaces только если заменяемая сессия инициирована UAS, получившим INVITE. В нашем же случае для UAS, получившего INVITE, это входящая сессия, инициированная не им, поэтому INVITE с таким Replaces должны отвергаться.

Можно попробовать реализовать тот же механизм с помощью UPDATE или INFO в рамках того же диалога, что и первоначчальный INVITE.

[alx]

Replying to alx:

Можно попробовать реализовать тот же механизм с помощью UPDATE или INFO в рамках того же диалога, что и первоначчальный INVITE.

Только в этом случае возникает вопрос к аккаунт-коллектору: он зафиксирует вызываемый номер из начального INVITE, и этот неполный номер в итоге попадет в CDR. Чтобы этого избежать, придется дорабатывать аккаунт-коллектор так, чтобы он, получив INFO с дополнительными цифрами номера, тоже добавлял их к уже имеющемуся номеру.

[alx]

В качеcтве рабочего варианта предлагается реализовать ​это:

[alx]

Похоже, что для сигнализаций, использующих тональные сигналы (особенно декадно-импульсный набор и без подтверждений) функция нормально работать не будет. При вызове со стороны TDM канальное окончание отправляет INVITE, после чего продолжает прием номера из канала TDM. Но в ответ на INVITE возможно получение ответа 1xx с SDP, что приводит к активации медиапотока. Как показали эксперименты, активация медиапотока нарушает прием тональных сигналов (проверялось, на канальном окончании SL: сразу после активации медиапотока отправкой VCEOPT канал на долю секунды перестает принимать частоту 2100 Гц, этого достаточно для пропуска цифры набираемого номера). Не активировать медиапоток тоже нельзя, так как тогда вызывающий не будет слышать КПВ и речевые информационные сигналы, передаваемые до ответа.

Как результат, не удается добиться надежной работы канальных окончаний АДАСЭ и SL в режиме Overlap Dialing. Видимо, придется ограничиться поддержкой этой функции лишь некоторыми типами канальных окончаний.