Читатели спрашивают (оставляйте вопросы по GSM здесь): как реализовать проигрывание голосового сообщения при звонке на CAMEL-абонента. Вызов при этом не должен быть полностью установлен (не должно быть тарификации А-абонента). После проигрывания сообщения вызов нужно прекратить.
Я вижу 3 варианта реализации. В любом из случаев предполагается, что в профиле абонента (T-CSI) указан "наш" SCP.
Вариант 1.
Ответить CAP RequestReportBCSM + Connect. Внутри Connect содержится номер IVR с которым надо установить соединение и не установлен параметр oCSIApplicable. Об этом IVR ниже.
Далее подождать некоторое время и отправить CAP releaseCall. Ожидается, что IVR не будет отвечать на вызов, поэтому никаких событий от SSP (MSC) не будет. Но на всякий случай лучше предусмотреть логику отправки releaseCall на события типа tAnswer.
Что касается IVR, то это должно быть устройство с голосовыми потоками и подключением по ISUP. Как только приходит ISUP IAM, логика IVR должна проверить А и Б номера и подготовить голосовой канал. Номер этого канала (CIC) приходит в сообщении IAM. Как только ISUP модуль отвечает ACM, можно начинать проигрывать запись в голосовом канале. Т.к. мы не будем отправлять ANM по ISUP, то и тарификации не будет.
Что касается диалога между SCP и SSP (MSC), то в RequestReportBCSM нужно активировать нотификацию на событие tNoAnswer и прерывание вызова (interrupted) для tAnswer. В случае получения ответа от нашего IVR вызов нужно завершить с помощью releaseCall.
Вариант 2.
На любой InitialDP отвечать releaseCall с release cause code, который точно на сети не используется. Далее, насколько мне известно, на MSC можно указать какой локальный автоответчик будет проигрываться при том или ином коде. Хотя согласно спецификации (для CAMELv2 - ETSI 03.78) коммутатор не должен ничего проигрывать, а только разорвать вызов и передать по ISUP на коммутатор абонента А сообщение REL с неким кодом (маппинг между кодами в CAMEL и ISUP не определён).
Только в этом варианте для всех абонентов получаем одинаковый автоинформатор (или очень ограниченное их число). Хочу сразу сказать, что я не сильно уверен в этом варианте - далёк от коммутаторов.
Вариант 3.
Использовать CAP "Connect to resource". Так делают Prepaid системы, когда перед вызовом необходимо проиграть системное сообщение типа "у Вас скоро закончатся все-все деньги". Callflow при этом такой:
Вариант 1.
Ответить CAP RequestReportBCSM + Connect. Внутри Connect содержится номер IVR с которым надо установить соединение и не установлен параметр oCSIApplicable. Об этом IVR ниже.
Далее подождать некоторое время и отправить CAP releaseCall. Ожидается, что IVR не будет отвечать на вызов, поэтому никаких событий от SSP (MSC) не будет. Но на всякий случай лучше предусмотреть логику отправки releaseCall на события типа tAnswer.
Что касается IVR, то это должно быть устройство с голосовыми потоками и подключением по ISUP. Как только приходит ISUP IAM, логика IVR должна проверить А и Б номера и подготовить голосовой канал. Номер этого канала (CIC) приходит в сообщении IAM. Как только ISUP модуль отвечает ACM, можно начинать проигрывать запись в голосовом канале. Т.к. мы не будем отправлять ANM по ISUP, то и тарификации не будет.
Что касается диалога между SCP и SSP (MSC), то в RequestReportBCSM нужно активировать нотификацию на событие tNoAnswer и прерывание вызова (interrupted) для tAnswer. В случае получения ответа от нашего IVR вызов нужно завершить с помощью releaseCall.
Вариант 2.
На любой InitialDP отвечать releaseCall с release cause code, который точно на сети не используется. Далее, насколько мне известно, на MSC можно указать какой локальный автоответчик будет проигрываться при том или ином коде. Хотя согласно спецификации (для CAMELv2 - ETSI 03.78) коммутатор не должен ничего проигрывать, а только разорвать вызов и передать по ISUP на коммутатор абонента А сообщение REL с неким кодом (маппинг между кодами в CAMEL и ISUP не определён).
Только в этом варианте для всех абонентов получаем одинаковый автоинформатор (или очень ограниченное их число). Хочу сразу сказать, что я не сильно уверен в этом варианте - далёк от коммутаторов.
Вариант 3.
Использовать CAP "Connect to resource". Так делают Prepaid системы, когда перед вызовом необходимо проиграть системное сообщение типа "у Вас скоро закончатся все-все деньги". Callflow при этом такой:
-> IntialDP
<- RequestReportBCSMEvent + ConnectToResource + PlayAnnouncement
играет запись
-> Specialized Resource Report
<- DisconnectForwardConnection + ReleaseCall
Только для такого варианта нужен "умный" IVR, который будет выступать в роли Intelligent Peripheral.
<- RequestReportBCSMEvent + ConnectToResource + PlayAnnouncement
играет запись
-> Specialized Resource Report
<- DisconnectForwardConnection + ReleaseCall
Только для такого варианта нужен "умный" IVR, который будет выступать в роли Intelligent Peripheral.
