В комментарии к статье "Основы CAMEL" меня попросили добавить трейс. Трейс я добавил, однако хотел бы подробнее описать что там и к чему.
Для начала откройте трейс CAMEL с помощью Wireshark (если у Вас есть другая любимая программа - просьба сообщить в комментарии). Данный трейс взят с живой системы, но все важные адреса заменены на вымышленные. И кстати, при осуществлении этого вызова ни одно животное не пострадало.
Обмен сообщениями происходит между поинт кодом 1 и 2 (разверните поле MTP3 в Wireshark). На уровне SCCP диалог происходит между 111111111111 и 222222222222.
111111111111 это Global Title (GT) коммутатора, а точнее SSP (service switching point), который инициирует запрос в SCP (service control point) с GT=222222222222. Для этого создаётся TCAP транзакция с номером 11111111 (в HEX). Внутри этой транзакции находится т.н. application-context-name: 0.4.0.0.1.0.50.1 (CAP-v2-gsmSSF-to-gsmSCF-AC). Т.е. это CAMEL версии 2, диалог между SSF и SCF (Service Switching и Control Function, соответственно).
Если Wireshark не декодирует сообщение дальше SCCP, то надо ему явно указать что SSN=146 это протокол CAMEL.
Для этого в меню "Edit" выбрать "Preferences". Перейти к последнему пункту "Protocols", развернуть список и начать набирать CAMEL.
При этом отобразятся свойства протокола такого вида:
В поле TCAP SSNs надо через запятую указать значения 146 и 12. нажать ОК и теперь всё будет отображаться корректно.
Если Wireshark не декодирует сообщение дальше SCCP, то надо ему явно указать что SSN=146 это протокол CAMEL.
Для этого в меню "Edit" выбрать "Preferences". Перейти к последнему пункту "Protocols", развернуть список и начать набирать CAMEL.
При этом отобразятся свойства протокола такого вида:
В поле TCAP SSNs надо через запятую указать значения 146 и 12. нажать ОК и теперь всё будет отображаться корректно.
Перейдём непосредственно в сам запрос. Первое, на что стоит обратить внимание, это opcode - InitialDP. Если Вы внимательно читали статью "Основы CAMEL", то должны знать что такой запрос посылается при срабатывании триггера. В данном случае это был триггер на "eventTypeBCSM: collectedInfo (2)" - исходящий вызов абонента. В отичии от Вас, SCP также "обратит" внимание на значение поля serviceKey, т.к. оно отвечает за выбор логики внутри SCP.
Теперь поля, которые имеют отношение непосредственно к вызову:
- Calling Party Number: 38067220XXXX. Это вызывающий номер - т.н. А-номер.
- Location number: 111111111111. Адрес коммутатора, с которого происходит вызов. Очень важное поле с точки зрения тарификации абонентов в роуминге.
- vlr-number и mscAddress. Тут я думаю, что всё понятно.
- calledPartyBCDNumber - а это номер вызываемого абонента, т.н. Б-номер. Новый Wireshark уже декодирует это поле из формата BCD в "человеческий", поэтому если Вы видите что-то отличное от номера 380674660466, то обновляйте Wireshark.
В ответ на InitialDP SCP отправляет сообщение applyCharging. Посмотрите сперва на TCAP часть. Это сообщение является продолжением уже начатой TCAP транзакции (11111111), со стороны SCP ей присваивается номер 22222222.
Механизм ApplyCharging/ApplyChargingReport (AC/ACR) используется как для тарификации, так и для ограничения длительности вызова. SCP, после получения InitialDP, может расчитать максимальную длительность вызова (на основании текущего балланса абонента и его местоположения) и тем самым указать коммутатору (SSP) разорвать вызов при достижении этого значения.
Однако есть SCP, которые ведут статистику на основании событий oAnswer и oDisconnect. Время между этими событиями и будет занесено в биллинговую систему. В случае необходимости SCP использует сообщение ReleaseCall чтобы прервать вызов.
Таким образом существует 2 метода подсчёта длительности вызова - на основании AC/ACR и на основании CAMEL событий.
Следующее сообщение это RequestReportBCSM и Connect в одном TCAP-сообщении. С помощью RRB активируются триггеры, о срабатывании которых необходимо уведомить SCP. Сообщение Connect информирует коммутатор о том, что соединение необходимо установить на другой номер - 380674660467.
Как только вызов был установлен - SSP отправляет нотификацию об этом (eventTypeBCSM: oAnswer).
Через некоторое время (44 сек), вызов прекращается и SSP информирует об этом SCP (eventTypeBCSM: oDisconnect). Также передаётся сообщение ApplyChargingReport с длительностью вызова. В данном случае это был простой вызов - без переподключений к автоинформаторам и пр. Поэтому внутри ACR содержится параметр timeIfNoTariffSwitch с длительностью вызова (описание полей в 09.78). Я не нашёл описания в стандарте, но почему-то значение параметра timeIfNoTariffSwitch в 10 раз больше актуальной длительности вызова.
И последнее сообщение - TCAP End для транзакции 11111111. На этом всё - вызов успешно завершён и обслужен.
Если есть вопросы - задавайте.
