Способ выполнения защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений и межсетевой шлюз мультимедийных сообщений
Данное изобретение относится к области взаимодействия мультимедийных сообщений в телекомуникационной отрасли. Технический результат заключается в обеспечении защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений. Такой технический результат достигается за счет того, что определяется, нужно ли обратно передавать сообщение о подтверждении в соответствии с разной величиной поля запроса о подтверждении в сигнале запроса. С применением кода состояния взаимодействия SMTP в сигнале запроса как критерия, когда величина поля запроса о подтверждении установлена как «НЕТ», то не требуется обратно передавать сообщение; а когда величина поля запроса о подтверждении установлена как «ДА», то требуется обратно передавать сообщение. По ответному состоянию сигнала о подтверждении определяется, получен ли код состояния передачи SMTP, обратно отправляющийся сигналом о подтверждении. 2 н. и 7 з.п. ф-лы, 4 ил.
Область техники
Данное изобретение относится к области взаимодействия мультимедийных сообщений в телекоммуникационной отрасли, в частности к способу выполнения защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений и межсетевому шлюзу мультимедийных сообщений.
Уровень техники
В настоящее время китайские операторы «China Mobile», «China Unicom» и другие уделяют большое внимание созданию центров мультимедийных сообщений (MMSC, Multimedia Messaging Service Center), на платформе которых осуществляется служба мультимедийного сообщения. Сейчас служба мультимедийного сообщения является одной из технологий высшего уровня по развитию службы коротких сообщений, характеризующаяся особенно тем, что она поддерживает множество мультимедийных функций и применяет технологии EDGE (Enhanced Data rates for GSM Evolution) и GPRS, передавая видеофрагменты, картинки, звуки и тексты с помощью WAP; к тому же передача мультимедийных сообщений реализуется не только между сотовыми телефонами, но и между сотовыми телефонами и компьютерами. Для взаимодействия мультимедийных сообщений (MMS, Multimedia Messaging Service) между разными операторами, в соответствии с требованиями к осуществлению взаимодействия мультимедийных сообщений, предоставленными Министерством промышленности и информатизации КНР, китайские операторы мобильной связи как «China Mobile», «China Unicom» должны создать специальные межсетевые шлюзы мультимедийных сообщений (MMSIG, Multimedia Messaging Service Interworking Gateway) для поддержки взаимодействия мультимедийных сообщений.
В процессе осуществления взаимодействия отсутствует режим синхронизации, когда межсетевой шлюз между двумя операторами определяет состояние доставки сообщений, что приводит к повторной передаче одного и того же сообщения и снижению восприятия пользователя.
Для отправителя переадресация считается завершенной только с ожиданием следующего сигнала ответа после получения отклика, см. Фиг.1. При этом вследствие передачи в разных цепях также должно проводиться кэширование сообщений, и в случае отсутствия сигнала о подтверждении сообщения о переадресации выполняется повторная отправка кэшированного содержимого. В результате получается низкий коэффициент успешности отправки, и в определенных процедурах имеется большая временная задержка; для получателя после ответа на отклик переадресация не сразу проводится, не ожидая пока отправится удачно сигнал о подтверждении сообщения о переадресации; при неудачной отправке сигнала о подтверждении сообщения о переадресации сигнал запроса сообщения о переадресации будет отброшен, иначе происходит несогласие между состояниями сообщений MMSIG обеих сторон. Тем самым, отправитель-MMSIG считает данную отправку сообщения неудачной, а на самом деле получатель-MMSIG получает сообщение удачно. Это приводит к повторной передаче данного сообщения, а также к многократному биллингу для отправителя-пользователя, что оказывает влияние на восприятие пользователя, к тому же вызывает его жалобы. Таким образом, способ на основе нынешней технологии должен быть усовершенствован.
Раскрытие изобретения
Цель настоящего изобретения заключается в том, что по отношению к вышеуказанным недостаткам при нынешнем уровне техники предлагает операторам способ для решения проблемы с повторной передачей и многократным биллингом и при отправке сообщений типа single link и dual link применяет специальный код состояния взаимодействия SMTP как критерий, тем самым реализуется защита от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений.
Технический проект данного изобретения заключается в следующем.
Предлагается способ выполнения защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений, в частности, содержащий следующие шаги, на которых:
А. межсетевой отправитель-шлюз мультимедийных сообщений (далее отправитель-шлюз) отправляет межсетевому получателю-шлюзу мультимедийных сообщений (далее получателю-шлюзу) сообщение, представляющее собой запрос на сообщение о переадресации;
В. в соответствии с установленным состоянием сигнала запроса отправителя-шлюза указанный получатель-шлюз определяет тип передачи цепи и определяет, удачно ли получение сообщений по идентификатору состояния, обратно отсылающемуся сигналом запроса или сигналом о подтверждении, если «ДА», то осуществляется переход к шагу С, иначе возврат к шагу А; и
С. полученное сообщение в нормальном состоянии передается к центру мультимедийных сообщений.
Вышеизложенный способ, в частности, содержит следующее: при определении отправителем-шлюзом передачи сообщений в одной цепи (single link) получатель-шлюз определяет состояние получения сообщений по идентификатору состояния, обратно отсылающемуся сигналом запроса.
Вышеизложенный способ, в частности, содержит следующее: передача сообщений в одной цепи проводится таким образом, что величина поля запроса о подтверждении в вышеуказанном сигнале запроса установлена как «НЕТ», требуя не передавать сигнал о подтверждении, и применяется код состояния взаимодействия SMTP сигнала запроса как отклик о состоянии обработки сообщений.
Вышеизложенный способ, в частности, содержит следующее: вышеуказанный код состояния взаимодействия SMTP является кодом 250 ОК.
Вышеизложенный способ, в частности, содержит следующее: когда сигнал запроса отправителя-шлюза и сигнал о подтверждении получателя-шлюза передаются в двух цепях (dual link), получатель-шлюз определяет состояние получения сообщения по идентификатору состояния, обратно отсылающемуся сигналом о подтверждении.
Вышеизложенный способ, в частности, содержит следующее: передача сообщений в двух цепях (single link) проводится таким образом, что величина поля запроса о подтверждении в вышеуказанном сигнале запроса установлена как «ДА», требуя обратно передавать сигнал о подтверждении, и применяется код состояния взаимодействия SMTP сигнала запроса как отклик о состоянии обработки сообщений.
Вышеизложенный способ, в частности, содержит следующее: код состояния взаимодействия сигнала о подтверждении является кодом 250 ОК.
Предлагается система защиты от дублирования сообщении о переадресации при взаимодействии мультимедийных сообщений, причем данная система содержит отправитель-шлюз, получатель-шлюз и соответствующие центры мультимедийных сообщений; вышеуказанный отправитель-шлюз и получатель-шлюз соединяются со своими центрами мультимедийных сообщений соответственно; отправитель-шлюз предназначен для передачи получателю-шлюзу сообщений, представляющих собой запросы на сообщение о переадресации; получатель-шлюз устанавливает соответствующие состояния в соответствии с сигналом запроса от отправителя-шлюза и определяет тип передачи цепи отправителя-шлюза и состояние получения сообщений по идентификатору состояния, обратно отсылающемуся сигналом, а также передает полученные сообщения в нормальном состоянии к центру мультимедийных сообщений.
Вышеизложенная система, в частности, содержит также абонентский терминал, соединяющийся с соответствующим центром мультимедийных сообщений. Терминал предназначен для определения успешности прочтения сообщений у абонента, переданных центром мультимедийных сообщений, в соответствии с кодом состояния взаимодействия SMTP от пользователя.
Предлагается межсетевой шлюз мультимедийных сообщений, предназначенный для защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений. Данный шлюз может быть соединен с центром мультимедийных сообщений в качестве отправителя или получателя соответственно и выполняет следующие настройки:
в качестве отправителя указанный шлюз устанавливает состояние сигнала запроса и передает получателю-шлюзу сообщения, представляющие собой запросы на сообщение о переадресации, тем самым позволяет, что получатель-шлюз устанавливает состояние в соответствии с сигналом запроса от отправителя-шлюза и определяет тип передачи цепи отправителя-шлюза и состояния получения сообщений по идентификатору состояния, обратно отсылающемуся сигналом запроса или сигналом о подтверждении; если «ДА», то передавать полученные сообщения в нормальном состоянии к центру мультимедийных сообщений;
и в качестве получателя, указанный шлюз устанавливает состояние сигнала запроса и передает отправителю-шлюзу сообщения, представляющие собой запросы на сообщение о переадресации; устанавливает состояние в соответствии с сигналом запроса от отправителя-шлюза и определяет тип передачи цепи отправителя-шлюза и состояние получения сообщений по идентификатору состояния, обратно отсылающемуся сигналом запроса или сигналом о подтверждении; если «ДА», то передавать полученные сообщения в нормальном состоянии к центру мультимедийных сообщений.
Данное изобретение предлагает способ и систему выполнения защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений, и межсетевой шлюз мультимедийных сообщений. В соответствии с разной величиной поля запроса о подтверждении (Acknowledgement Request) сигнала запроса применяется код состояния взаимодействия SMTP как критерий для передачи сообщений на разных цепях. В результате это приводит к низким затратам энергии системы, отсутствию временной задержки и высокому коэффициенту успешности передачи, избегая ситуации, где при повторной передаче отправителем сообщений о подтверждении по причине своего ненормального получения снижается уровень довольства у абонентов; в то же время при производстве сообщения о переадресации шлюзом выполняется оптимизация процедуры запроса, избегая ситуации, где проводится многократная отправка из-за различий между состояниями во многих цепях.
Краткое описание чертежей
Фиг.1 - Схема взаимодействия мультимедийных сообщений при нынешнем уровне техники.
Фиг.2 - Структурная схема предложенной системы в данном изобретении.
Фиг.3 - Диаграмма процедуры взаимодействия мультимедийных сообщений без передачи сообщения о подтверждении в запросе по данному изобретению.
Фиг.4 - Диаграмма процедуры взаимодействия мультимедийных сообщений с передачей сообщения о подтверждении в запросе по данному изобретению.
Осуществление изобретения
Данное изобретение предлагает способ выполнения защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений и соответствующую систему. Ниже подробно описано данное изобретение со ссылкой на приложенные чертежи и примеры реализации для того, чтобы уточнять цель, технический проект и преимущества данного изобретения
Для решение такой проблемы, где временная задержка передачи и низкий коэффициент успешности передачи существуют из-за различия между отправителем-шлюзом (Original MMSIG) и получателем-шлюзом (Recipient MMSIG) при взаимодействии мультимедийных сообщений. Данное изобретение применяет систему и способ оптимизационной обработки стандартной процедуры передачи сообщений по теории синхронного управления. Ядро данного изобретения заключается в том, что в соответствии с разной величиной поля запроса о подтверждении (Acknowledgement Request) сигнала запроса определяется, нужно ли обратно передавать сообщение о подтверждении; когда величина поля запроса о подтверждении установлена как «нет», то требуется не обратно передавать сообщение о подтверждении, и применять код состояния взаимодействия SMTP сигнала запроса как критерий; Иначе требуется обратно передавать сообщение о подтверждении, и по состояниям ответа на сигнал о подтверждении определять успешность переадресации посредством получения отклика на код состояния передачи SMTP, и выполнить нормальную обработку операций и перейти к следующей переадресации. В том числе, данная система содержит, как показано на Фиг.2, центр мультимедийных сообщений (MMSC), отправитель-шлюз мультимедийных сообщений (MMSIG) и получатель-шлюз мультимедийных сообщений (MMSIG), а также абонентский терминал; отправитель-шлюз и получатель-шлюз соединяются с центрами мультимедийных сообщений соответственно. И отправитель-шлюз передает получателю-шлюзу сообщения, представляющие собой запросы на сообщение о переадресации; получатель-шлюз определяет тип передачи цепи отправителя-шлюза в соответствии с установленным состоянием сигнала запроса отправителя-шлюза. В том числе, когда величина поля запроса в сигнале запроса отправителя-шлюза установлена как «НЕТ», то выбран тип single link требуя не обратно передавать сигнал о подтверждении, применять код состояния взаимодействия SMTP сигнала запроса как обратная связь по состояниям обработки сообщений; когда величина поля запроса в сигнале запроса отправителя-шлюза установлена как «НЕТ», то выбран тип dual link, (значит, сигнал запроса и сигнал о подтверждении расположены не в одной цепи, обладая своим кодом состояния 250 OK соответственно), требуя обратно передавать сигнал о подтверждении, и по коду состояния передачи SMTP сигнала о подтверждении определять состояния получения и отправки, и передавать полученные сообщения в нормальном состоянии к центру мультимедийных сообщений; абонентские терминалы (включая абонентские терминалы получения/отправки, отправки/получения) соединяются с центрами мультимедийных сообщений соответственно, предназначены для определения того, что удачно ли прочтение сообщений у абонента, переданных центром мультимедийных сообщений, в соответствии с кодом состояния взаимодействия SMTP от пользователя.
В соответствии с данным изобретением предложенный способ в основном содержит следующее: На первом шагу межсетевой отправитель-шлюз мультимедийных сообщений (Original MMSIG) посредством установки величины поля Acknowledgement Request в сигнале запроса как «НЕТ», требуя не обратно передавать сигнал о подтверждении, и применяет код состояния взаимодействия SMTP сигнала запроса как отклик на состояние обработки сообщений. Где код 250 OK обозначает удачную отправку, а иной код (а не код 250 OK) обозначает неудачную отправку; потом по виду кодов ошибок определяется необходимость запуска повторной передачи по причине передачи в одной цепи, имеется код состояния взаимодействия как отклик на состояние обработки сообщений при отправке сигнала запроса, и определяется успешность отправки по получению данного кода состояния взаимодействия как критерию, что приводит к отсутствию временной задержки и своевременной передаче. Подробно описаны шаги данного изобретения со ссылкой на Фиг.3. На Фиг.3 величина запроса о подтверждении в сигнале запроса интерфейса ММ установлена как «НЕТ», требуя не обратно передавать сигнал о подтверждении. Данная процедура представляет собой:
Шаг 1. Отправитель-шлюз передает получателю-шлюзу запрос на сообщение о переадресации;
Шаг 2. Получатель-шлюз получает запрос на сообщение о переадресации, применяет код состояния взаимодействия SMTP вышесказанного запроса как оклик на состояние обработки сообщений, где код 250 OK обозначает удачную отправку; после получения данного кода состояние сообщения переключается в состояние ожидания доставки, и данное мультимедийное сообщение передается к центру мультимедийных сообщений получателя; а если получен иной код (а не код 250 OK), то передача считается неудачной, потом по виду кодов ошибок определяется необходимость запуска повторной передачи, и вернуться к Шагу 1;
Шаг 3. При удачной отправке запроса на сообщение о переадресации получатель-шлюз передает отправителю-шлюзу запрос на отчет о доставке, применяет код состояния взаимодействия SMTP запроса на отчет о доставке как отклик на состояние обработки сообщений, где код 250 OK обозначает удачную отправку; после получения данного кода данное мультимедийное сообщение передается к центру мультимедийных сообщений получателя; а если получен иной код (а не код 250 OK), то передача считается неудачной, потом по виду кодов ошибок определяется необходимость запуска повторной передачи;
Шаг 4. После удачной отправки отчета о доставке получатель-шлюз передает отправителю-шлюзу запрос на отчет о прочтении; и определяется код состояния взаимодействия SMTP в соответствии с фактом прочтения пользователем данного запроса, где код 250 OK обозначает удачную отправку; после получения данного кода к центру мультимедийных сообщений передается сообщение о удачном прочтении пользователем данного отчета; а если получен иной код (а не код 250 OK), то передача считается неудачной, потом по виду кодов ошибок определяется необходимость запуска повторной передачи.
На Фиг.3 интерфейс ММ4 имеет три группы сигналов: сообщение о переадресации, отчет о доставке и отчет о прочтении, чьи процедура и состояние передачи сообщений одинаковы. По сравнению с сигналом запроса на сообщение о переадресации отчет о доставке и отчет о прочтении обладают одинаковым режимом управления, направленным противоположно; в данном примере величины запросов о подтверждении (Acknowledgement Request) трех групп сигналов настроены на «НЕТ», но должно поддерживать варианты реализации, допускаемые правилами, т.е. должно приспособляться к такому случаю, когда величина запроса о подтверждении (Acknowledgement Request) установлена как «ДА». Таким образом, здесь необходимо приспособляться к разным форматам запроса отправителя и окончательно решить проблему, касающуюся повторной передачи сообщений; в данном изобретении дается предложение, что отправитель-шлюз MMSIG применяет способ без требования запроса о подтверждении.
На втором шагу получатель-шлюз (Recipient MMSIG) определяет состояние сообщений потому, что отправитель-шлюз (Original MMSIG) оформляет ли запрос отклика на подтверждение, в том числе, для сообщения без запроса отклика на подтверждение, то есть когда величина поля сообщения сигнала запроса Acknowledgement Request установлена как «НЕТ», сообщения передаются в одинаковой цепи; при отправке сигнала запроса имеется код состояния взаимодействия SMTP 250 OK в качестве отклика состояния обработки сообщений, получаются сообщения в нормальном состоянии, и обратно отправляется SMTP 250 OK, потом данное мультимедийное сообщение нормально передается к центру мультимедийных сообщений (MMSC), как показано на Фиг.3; а для сообщения с запросом отклика на подтверждение, то есть когда величина поля сообщения сигнала запроса Acknowledgement Request установлена как «ДА», сообщения передаются в разных цепях; проводится обработка по коду состояния взаимодействия SMTP отклика на подтверждение, где код 250 OK обозначает удачную отправку, а другой код обозначает неудачную. При неудачной отправке первоначальное сообщение запроса будет отбросано; а при удачной отправке вышеуказанный запрос продолжительно распределяется к последующей процедуре. Потому что два сигнала расположены не в одной цепи TCP, и каждый из них содержит код 250 OK для обозначения удачной передачи (имеются много кодов состояния, среди которых 250 обозначает удачную передачу, и другой код как 421, 553 обозначает неудачную), а именно код 250 OK и сигнал запроса или сигнал о подтверждении находятся в одинаковой цепи TCP; то, что получается код состояния взаимодействия SMTP 250 OK, обратно отсылающийся сигналом о подтверждении, обозначает удачную отправку. Таким образом, решены проблема с повторным получением сообщений абонентом и проблема с повторным биллингом отправителя. Описаны шаги в данном изобретении, на которых требуется отклик на подтверждение, со ссылкой на фиг.4. На Фиг.4, величина поля запроса о подтверждении Acknowledgement Request трех групп сигналов, содержащихся среди сообщения о переадресации, отчета о доставке и отчета о прочтении, установлена как «ДА», и каждая группа сигналов является сообщением, передающимся в двух цепях, включая REQ (запрос) и RES (отклик), т.е. с передачей запроса требуется отклик на подтверждение, в том числе сообщение RES среди трех групп сигналов как сообщения о переадресации, отчета о доставке и отчета о прочтении является альтернативным, а не обязательным. Данная процедура представляет собой:
Шаг 1. Отправитель-шлюз передает получателю-шлюзу запрос на сообщение о переадресации;
Шаг 2. Отправитель-шлюз требует от получателя-шлюза обратно передавать сообщение о переадресации. После получения запроса на сообщение о переадресации получатель-шлюз определяет состояние отклика на сообщение о переадресации и подтверждает о получении отправителем-шлюзом сообщения отклика на сообщение о переадресации, в то же время обратно передает состояние удачной отправки 250 ОК. При этом состояние сообщения переключается к состоянию ожидания отчета о доставке, и получатель-шлюз проводит нормальную обработку операций, передает данное мультимедийное сообщение к центру мультимедийных сообщений и продолжительно его отправляет. При неудачной отправке отклика на сообщение о переадресации или при получении отправителем иного кода (а не 250 OK) отправка считается неудачной и получатель будет отбрасывать первоначальное сообщение о переадресации и ожидает переотправки, вернуться к Шагу 1;
Шаг 3. После удачной отправки запроса на сообщение о переадресации получатель-шлюз передает отправителю-шлюзу запрос на отчет о доставке, определяет состояние отклика на отчет о доставке и подтверждает о получении отправителем-шлюзом сообщения отклика на отчет о доставке, в то же время обратно передает код состояния удачной отправки 250 OK и распределяет данное мультимедийное сообщение к центру мультимедийных сообщений. При неудачной отправке отклика на отчет о доставке или при получении отправителем иного кода (а не 250 OK) отправка считается неудачной и получатель будет отбрасывать первоначальный отчет о доставке и ожидает переотправки получателем-шлюзом.
Шаг 4. После удачной отправки отчета о доставке получатель-шлюз передает отправителю-шлюзу запрос на отчет о прочтении, и определяет состояние отклика на отчет о прочтении, и подтверждает о получении отправителем-шлюзом сообщения отклика на отчет о доставке, обратно передавая состояние удачной отправки 250 OK, и распределяет данное мультимедийное сообщение к центру мультимедийных сообщений. При неудачной отправке отклика на отчет о прочтении или при получении отправителем иного кода (а не 250 OK) отправка считается неудачной и получатель будет отбрасывать первоначальный отчет о прочтении и ожидает переотправку получателем-шлюзом.
Ниже подробно описано данное изобретение по направлению сообщений со ссылкой на Фиг.3 и Фиг.4 соответственно:
(i) Процедура IО (Interworking Gateway Originated)
Взять пару сигналов MM4_forward.REQ/MM4_forward.RES (запрос на сообщение о переадресации / отклик на сообщение о переадресации) к примеру. Во избежание неудачной передачи сообщения, возникающей по причине неудовлетворительного состояния сети при возврате получателем отклика на сообщение о переадресации, данный отправитель-шлюз MMSIG пытается снижать различия между состояниями сообщений, передающихся в разных цепях, и передавать сообщения в одной цепи. Таким образом, для альтернативного сообщения MM4_forward.RES (отклик на сообщение о переадресации) не требуется возврат запроса, и поле запроса о подтверждении в сигнале MM4_forward.REQ (запрос на сообщение о переадресации) установлено как «НЕТ». На основе этого в процессе взаимодействия протокола SMTP для передачи сигнала MM4_forward.REQ (запрос на сообщение о переадресации) определяется состояние доставки сообщения в соответствии с кодом состояния, обратно отсылающимся получателем-шлюзом (MMSIG). В том числе, когда получен код 250 OK, обозначающий удачную отправку, состояние сообщения переключается к состоянию ожидания отчета о доставке; а когда получен код состояния 4ХХ или 5ХХ, определяется необходимость повторной передачи в соответствии с кодами ошибок. При этом сообщение с требованием повторной передачи будет поставляться в очередь повторной передачи для ожидания следующей передачи; для сообщения без требования повторной передачи непосредственно появится диалог «неудачно» и прекращен журнал, что завершает вышесказанную процедуру.
С помощью регулирования принятой величины поля, допускаемой соответствующими правилами, эффективно улучшается синхронизация состояний, возникающая при передаче сообщений ММ4 с протоколом SMTP. В том числе отправитель-шлюз MMSIG может дать четкое требование не обратно отправлять сообщение MM4_forward.RES, а определяет состояние передачи сообщения по коду состояния взаимодействия SMTP MM4_forward.REQ; но получатель-шлюз MMSIG должен поддерживать разные случаи, когда отправителю-шлюзу требуется запроса на сообщение MM4_forward.RES. Исходя из вышесказанного, для отправителя-шлюза MMSIG дается предложение применять способ без запроса на сообщение MM4_forward.RES, и аналогично, отчет о доставке и отчет о прочтении передаются в одной цепи. См. конкретную процедуру на Фиг.3. Для отправителя получение SMTP 250 OK обозначает завершение передачи, не требуя ожидания сообщения RES; сообщения передаются в одной цепи, не требуя кэширования, что завершает процедуру, таким образом, передача проводится без временной задержки; а для получателя возврат SMTP 250 OK обозначает завершение получения, и можно проводить последующую передачу и другие, не требуя никакого взаимодействия с отправителем-шлюзом MMSIG. При этом благодаря отсутствию кэширования не требуется принимать алгоритм расчета вероятности попадания во внимание. В результате обработка становится проще и эффективнее и передача проводится без временной задержки.
(ii) Процедура IT (Interworking Gateway Terminated)
Исходя из вышеприведенного анализа процедуры IО, предлагается применять процесс взаимодействия сообщений без запроса на возврат сообщения MM4_forward.RES, но это только принимается как предложение. Получатель-шлюз MMSIG должен поддерживать варианты осуществления, допускаемые правилами, таким образом, необходимо адаптироваться к разным форматам запроса от отправителя, и решить проблему с повторной передачей сообщений. Взять пару сигналов MM4_forward.REQ/MM4_forward.RES к примеру. Для обеспечения неповторной обработки сообщения, при получении сообщения MM4_forward.REQ, сначала определяют величину поля Acknowledgement Request MM4_forward.REQ сигнала передачи, и в соответствии с разной величиной проводится обработка соответственно:
1. Величина установлена как «НЕТ», то не требуется обратно передавать сообщение MM4_forward.RES
Данный случай соответствует предложенному выше способу и является самым надежным и эффективным. По состоянию получения сообщения MM4_forward.REQ обратно отправляется код состояния: при нормальном случае обратно отправлять код 250 OK, а при ненормальном случае обратно отправлять код ошибок 4ХХ или 5ХХ. Отправитель-шлюз MMSIG принимает данный код состояния в качестве признака удачной передачи. Поэтому для сообщения с возвратом кода состояния удачи 250 OK получатель-шлюз MMSIG будет непосредственно заниматься обработкой операций и продолжительно передавать сообщения; для сообщения с возвратом кода ошибок получатель-шлюз MMSIG будет отбрасывать данное сообщение и отправитель-шлюз ММSIG будет управлять повторной передачей. Данный способ управления не приводит к появлению проблемы с многократной передачей и повторным биллингом. Процедура обработки сообщения показана на Фиг.3.
2. Величина установлена как «ДА», то требуется обратно передавать сообщение MM4_forward.RES. И подробное описание приведено на Фиг.4. Для данного случая отправителю-шлюзу MMSIG требуется обратно передавать сообщение о подтверждении MM4_forward.RES и принимать получение сообщения MM4_forward.RES как признак удачной передачи. Поэтому получатель-шлюз MMSIG должен определять состояние отклика на сообщение MM4_forward.RES и подтверждать успешность получения отправителем MMSIG данного сообщения, далее проводить следующую процедуру обработки; при определении получения отправителем сообщения MM4_forward.RES с возвратом состояния удачи 250 OK получатель-шлюз MMSIG проводит нормальную обработку операций и продолжительно передает сообщения; при неудачной отправке сообщения MM4_forward.RES или при неудачном получении отправителем-шлюзом MMSIG, получатель-шлюз MMSIG будет отбрасывать первоначальное сообщение MM4_forward.REQ и ожидает повторной передачи от отправителя-шлюза MMSIG.
В соответствии с вышеизложенным описан способ выполнения защиты от дублирования с точки зрения отправителя и получателя соответственно. С применением данного способа, применимым на практике, получена эффективность защиты проще и эффективнее.
Следует отметить, что приведенные выше описания представляют собой лишь предпочтительные варианты осуществления настоящего изобретения и не используются для ограничения настоящего изобретения. Специалист в данной области может сделать множество модификаций и изменений в настоящем изобретении. Любые модификации, эквивалентные замены, усовершенствования и т.д., выполненные без отклонения от сути и принципов настоящего изобретения, входят в объем правовой охраны настоящего изобретения.
Промышленная пригодность
Данное изобретение предлагает способ и систему выполнения защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений и межсетевой шлюз мультимедийных сообщений. В соответствии с разной величиной поля запроса о подтверждении (Acknowledgement Request) сигнала запроса применяется код состояния взаимодействия SMTP как критерий для передачи сообщений на разных цепях. В результате это приводит к низким затратам энергии системы, отсутствию временной задержки и высокому коэффициенту успешности передачи, избегая ситуации, где при повторной передаче отправителем сообщений о подтверждении по причине своего ненормального получения снижается уровень довольства у абонентов. В то же время при производстве сообщения о переадресации шлюзом выполняется оптимизация процедуры запроса, избегая ситуации, где проводится многократная отправка из-за различий между состояниями во многих цепях.
1. Способ выполнения защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений, содержащий следующие шаги:
А. межсетевой отправитель-шлюз мультимедийных сообщений (отправитель-шлюз) отправляет межсетевому получателю-шлюзу мультимедийных сообщений (получателю-шлюзу) сообщение, представляющее собой запрос на сообщение о переадресации;
В. в соответствии с установленным состоянием сигнала запроса отправителя-шлюза указанный получатель-шлюз определяет тип передачи цепи и определяет, удачно ли получение сообщений по идентификатору состояния, обратно отсылающемуся сигналом запроса или сигналом о подтверждении; если «ДА», то осуществляется переход к шагу С, иначе, то возврат к шагу А; и
С. полученные сообщения в нормальном состоянии раздаются к центру мультимедийных сообщений.
2. Способ по п.1, в котором при определении отправителем-шлюзом передачи сообщений в одной цепи (single link) получатель-шлюз определяет состояние получения сообщений по идентификатору состояния, обратно отсылающемуся сигналом запроса.
3. Способ по п.2, в котором передача сообщений в одной цепи проводится таким образом, что величина поля запроса о подтверждении в вышеуказанном сигнале запроса установлена как «НЕТ», требуя не передавать сигнал о подтверждении, и применяется код состояния взаимодействия SMTP сигнала запроса как отклик о состоянии обработки сообщений.
4. Способ по п.3, в котором указанный код состояния взаимодействия SMTP является кодом 250 ОК.
5. Способ по п.1, в котором, когда сигнал запроса отправителя-шлюза и сигнал о подтверждении получателя-шлюза передаются в двух цепях (dual link), получатель-шлюз определяет состояние получения сообщения по идентификатору состояния, обратно отсылающемуся сигналом о подтверждении.
6. Способ по п.5, в котором передача сообщений в двух цепях (single link) проводится таким образом, что величина поля запроса о подтверждении в указанном сигнале запроса установлена как «ДА», требуя обратно передавать сигнал о подтверждении, и применяется код состояния взаимодействия SMTP сигнала запроса как отклик о состоянии обработки сообщений.
7. Способ по п.6, в котором код состояния взаимодействия сигнала о подтверждении является кодом 250 ОК.
8. Межсетевой шлюз мультимедийных сообщений, предназначенный для защиты от дублирования сообщений о переадресации при взаимодействии мультимедийных сообщений, причем указанный шлюз может быть соединен с центром мультимедийных сообщений в качестве отправителя или получателя соответственно и выполняет следующие настройки:
в качестве отправителя указанный шлюз устанавливает состояние сигнала запроса и передает получателю-шлюзу сообщения, представляющие собой запросы на сообщение о переадресации, тем самым позволяет, что получатель-шлюз устанавливает состояние в соответствии с сигналом запроса от отправителя-шлюза, и определяет тип передачи цепи отправителя-шлюза, и состояния получения сообщений по идентификатору состояния, обратно отсылающемуся сигналом запроса или сигналом о подтверждении; если «ДА», то передавать полученные сообщения в нормальном состоянии к центру мультимедийных сообщений; и
в качестве получателя указанный шлюз устанавливает состояние сигнала запроса и передает отправителю-шлюзу сообщения, представляющие собой запросы на сообщение о переадресации; устанавливает состояние в соответствии с сигналом запроса от отправителя-шлюза, и определяет тип передачи цепи отправителя-шлюза, и состояние получения сообщений по идентификатору состояния, обратно отсылающемуся сигналом запроса или сигналом о подтверждении; если «ДА», то передавать полученные сообщения в нормальном состоянии к центру мультимедийных сообщений.
9. Межсетевой шлюз мультимедийных сообщений по п.8, причем указанный центр мультимедийных сообщений соединяется также с абонентским терминалом; и указанный шлюз предназначен для определения успешности прочтения сообщений у абонента, переданных центром мультимедийных сообщений, в соответствии с кодом состояния взаимодействия SMTP от пользователя.
