RU2374777C2 - Обработка начальных мультимедийных данных i - Google Patents

Обработка начальных мультимедийных данных i Download PDF

Info

Publication number
RU2374777C2
RU2374777C2 RU2006116572/09A RU2006116572A RU2374777C2 RU 2374777 C2 RU2374777 C2 RU 2374777C2 RU 2006116572/09 A RU2006116572/09 A RU 2006116572/09A RU 2006116572 A RU2006116572 A RU 2006116572A RU 2374777 C2 RU2374777 C2 RU 2374777C2
Authority
RU
Russia
Prior art keywords
call
user
data
port
sip
Prior art date
Application number
RU2006116572/09A
Other languages
English (en)
Other versions
RU2006116572A (ru
Inventor
Томас БЕЛЛИНГ (DE)
Томас Беллинг
Original Assignee
Сименс Акциенгезелльшафт
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Сименс Акциенгезелльшафт filed Critical Сименс Акциенгезелльшафт
Publication of RU2006116572A publication Critical patent/RU2006116572A/ru
Application granted granted Critical
Publication of RU2374777C2 publication Critical patent/RU2374777C2/ru

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/327Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the session layer [OSI layer 5]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Abstract

Изобретение относится к системам связи. Технический результат заключается в повышении эффективности выбора потоков полезных данных начальных мультимедийных данных и обеспечивается посредством способа выбора полезных данных (начальных мультимедийных данных 13/В; 14/В'), передаваемых перед завершением (20) установления соединения вызова (1-12; 15-19) между пользователем-инициатором установления соединения вызова (оконечное устройство А) и, по меньшей мере, одним пользователем-адресатом вызова (оконечное устройство В или оконечное устройство В') через, по меньшей мере, одну телекоммуникационную сеть (SIP-посредник), при котором пользователь-инициатор (А) установления соединения вызова в ответном сообщении (9, 10 от В или 11, 12 от В') применяет данные адреса приема (IP-B, Port-B оконечного устройства В или IP-B', Port-B' оконечного устройства В') пользователя-адресата вызова для, по меньшей мере, одного пользователя-адресата (В или В') вызова, чтобы пользователем-адресатом (В или В') вызова вместе с данными адреса передачи (IP-b, Port-b для В; IP-b', Port-b' для В') пользователя-адресата вызова выбрать посланные полезные данные (начальные мультимедийные данные 13 от В/14 от В'), при этом данные адреса приема (IP-B, Port-B устройства В) пользователя-адресата вызова для адресата (В) вызова также представляют данные адреса передачи (IP-b, Port-b) этого пользователя-адресата (В) вызова. 2 н. и 12 з.п. ф-лы, 1 ил.

Description

Изобретение относится к способам и устройствам для выбора полезных данных, передаваемых перед завершением установления вызова между пользовательским оконечным устройством-инициатором установления вызова и пользовательским оконечным устройством-адресатом вызова, определяемых как «начальные мультимедийные данные», по меньшей мере, по одной телекоммуникационной сети.
Так называемый «протокол инициирования сеанса» (SIP) представляет собой протокол сигнализации, который может применяться для так называемого «управления вызовом» (управления соединением), например, в случае телефонных разговоров. Протокол SIP стандартизован IEТF в документе REC 3261 и в более старой версии в документе RFC 2543. Протокол SIP использует для описания коммутируемого коммуникационного соединения так называемый «протокол описания сеанса» (SDP), стандартизованный в документе IETF RFC 2327, способом, описанным в документе IETF RFC 3264. Продвижение протокола SIP, так же, как и для согласованных сетевых соединений, обычно осуществляется по Интернет-протоколу. Протокол SIP находит применение описанным способом, например, в так называемой «мультимедийной подсистеме Интернета» (IMS) сети мобильной связи, стандартизованной посредством 3GPP и 3GPP2.
При установлении соединения вызова от оконечного устройства протокола SIP вызывающего абонента А к вызываемому пользователю В сигнализация протокола SIP может доставляться через коммутационные узлы, так называемые «посредники». При этом посредникам разрешается направлять входящее сообщение, которое указывает на то, что пользователю А желательно установить соединение с пользователем В (так называемый «INVITE request» (запрос приглашения)), к множеству других посредников или оконечных устройств протокола SIP одновременно или последовательно, например, чтобы отыскать пользователя В. Так как и последние названные посредники могут разветвить сообщение при дальнейшей пересылке, это может привести к древовидному разветвлению сообщения. Эта разветвленная дальнейшая пересылка сообщений в протоколе SIP обозначается как «Forking» (ветвление). Если сообщение «INVITE» приходит в оконечное устройство пользователя В, то это оконечное устройство может ответить так называемым сообщением «1хх Provisional Response» (промежуточный ответ), которое может служить, например, для того, чтобы согласовать применяемые при коммуникационных соединениях мультимедийные компоненты (например, речь, видео) и их кодирование, а также чтобы указать, что пользователь В уведомляется (например, посредством звонка его телефона с возможностями SIP-протокола). В случае ветвления может иметь место то, что несколько оконечных устройств пошлют такие промежуточные ответы, например, при одновременной генерации звонков таких SIP-телефонов. Для завершения установления коммуникационного соединения между оконечным устройством вызывающего абонента А и оконечным устройством вызываемого абонента В это оконечное устройство отвечает так называемым «2xx Final Response» (окончательным/заключительным ответом), например, если пользователь «снимает трубку» SIP-телефона. Несколько оконечных устройств пользователей В могут послать такие заключительные ответы, например, если сняты трубки нескольких звонящих SIP-телефонов. Соответственно, может произойти, что оконечное устройство пользователя А получает промежуточные ответы и/или окончательные ответы от пользователя В. Каждое оконечное устройство пользователя В снабжает все сообщения, которые оно посылает в качестве ответов пользователю А, одной и той же однозначно определенной идентификацией. Если в оконечное устройство пользователя А поступают сообщения SIP-ответов с новой идентификацией, то тем самым оконечное устройство пользователя А узнает о том, что оно осуществляет связь с новым оконечным узлом. В случае протокола SIP в этом случае говорят о том, что между оконечным устройством пользователя А и отвечающим оконечным устройством пользователя В существует так называемый «диалог». Прежде чем пользователь А (и/или, в необходимом случае, пользователь В) получит «заключительный ответ» для диалога, говорят о «начальном диалоге», а затем об «установившемся диалоге».
Может произойти так, что оконечные устройства пользователей А и В уже до окончания установления коммуникационного соединения обмениваются мультимедийными данными (полезными данными), которые обозначаются как «начальные мультимедийные данные». Так, могут, например, подобно случаю классической телефонной сети передаваться звонки (рингтоны) и передаваемые тексты, предпочтительно в направлении от пользователя В к пользователю А. Для телефонной сети с SIP-сигнализацией поддержка передачи начальных мультимедийных данных особенно важна, если сеть связывается с классической телефонной сетью.
В случае, если, при установлении коммуникационного соединения от пользователя А к пользователю В, наличие ветвления приводит к нескольким диалогам в (с) оконечном (ым) устройстве (ом) пользователя А, то пользователь А также может получать мультимедийные данные (полезные данные), в особенности, «начальные мультимедийные данные», от различных оконечных устройств В, В'. Оконечное устройство пользователя А должно подходящим образом представлять мультимедийные данные. Например, возможно, что различные входящие потоки видеоданных представляются на раздельных окнах экрана. Однако зачастую целесообразным является выбор одного входящего потока мультимедийных данных и игнорирование остальных потоков мультимедийных данных, например, потому, что экран в мобильном оконечном устройстве слишком мал для представления отдельных окон, или если наложение различных рингтонов или передаваемых текстов сделало бы содержание полностью непонятным.
Информация о соответствующих SIP-диалогах могла бы предоставить критерии, которые разрешают выбрать подходящий поток мультимедийных данных (поток полезных данных) для представления:
- Если посредством получения первого «заключительного ответа протокола SIP», «начальный диалог» становится «установленным диалогом», то целесообразно выбрать соответствующий поток мультимедийных данных.
- Может оказаться целесообразным выбрать «начальные мультимедийные данные», которые соответствуют последнему установленному «начальному диалогу». Это имеет место особенно в том случае, когда посредники вводят «ветвление» последовательным способом. Если оконечное устройство посылает отрицательный ответ или спустя некоторое время коммуникационное соединение с ним не устанавливается, например, ни один пользователь не «снял трубку», то посредник направляет запрос INVITE на другое оконечное устройство. В настоящее время рабочая группа IETF SIP WG определяет методы, которые позволят оконечному устройству А потребовать от посредника осуществлять только последовательный поиск (draft-ietf-sip-callerprefs).
- Оконечное устройство А может завершить диалог посредством SIP-сигнализации, например, если оно в состоянии поддерживать только ограниченное количество диалогов. Однако соответствующие мультимедийные данные, ввиду времени распространения сигнализации и мультимедийных данных в сети, могут еще приниматься в течение некоторого времени. Желательно подавлять прием мультимедийных данных в течение этого переходного периода времени.
При этом информация, содержащаяся в SIP и SDP, не всегда позволяет однозначно соотносить SIP-диалог с соответствующим потоком мультимедийных данных. В частности, оконечное устройство пользователя А выбирает IP-адрес и порт, например, UDP-порт (см. IETF RFC 768), для приема потоков мультимедийных данных, прежде чем оно пошлет запрос приглашения (INVITE), который содержит эти указания. Таким образом, все входящие мультимедийные данные принимаются по одному и тому же IP-адресу и на одном и том же порте. Они могут различаться посредством параметра “source IP Address” (IP-адрес источника) в IР-заголовке и параметра “source Port” (порт источника) в UDP-заголовке принимаемых пакетов, то есть IP-адреса и порта, с которых пакеты были посланы. Во всяком случае, в SIP/SDP, согласно RFC 3264, отсутствует информация об этих IP-адресе источника и порте источника, а имеются только так называемые IP-адрес «получателя» и порт «получателя», то есть IP-адрес и порт, на которые пакеты посылались.
При разработке концепции SIP-ветвления взаимодействие с «начальными мультимедийными данными» (Early Media) сначала не принималось во внимание, так как такие начальные мультимедийные данные в SIP-сети возникают лишь в особых случаях, например, при соединении с классической телефонной сетью.
Обработка «начальных мультимедийных данных» (полезных данных) в случае ветвления в настоящее время обсуждается рабочей группой IETF SIPPING. Проект “draft-camarillo-sipping-early-media” предлагает согласовать для полезных данных, представляющих собой начальные мультимедийные данные, собственные коммуникационные соединения посредством SIP, причем оконечное устройство В при коммуникационных соединениях для «начальных мультимедийных данных» выступает в качестве вызывающего абонента, если он получает вызов от пользователя А для собственно соединения для передачи полезных данных и в отношении этого вызова для соединения для передачи полезных данных сначала вступает с пользователем А в «начальный диалог». В любом случае это имеет недостаток, заключающийся в том, что необходимо бесполезным образом производить обмен множеством SIP-сообщений, что, особенно при передаче по интерфейсу радиосвязи с малой шириной полосы, приводит к задержке в установлении соединения вызова и высоким потребностям в ресурсах. Кроме того, возможно, потребовалось бы зарезервировать отдельные ресурсы передачи для «начальных мультимедийных данных» и для собственно соединения для передачи полезных данных.
Рабочая группа IETF MMUSIC предлагает в проекте “draft-ietf-mmusic-sip-srcfilter” ввести в SDP параметр, который позволяет явно выразить IP-адрес источника и UDP-порт источника, с которого приемник будет принимать пакеты. Эта информация используется для того, чтобы конфигурировать расположенные промежуточным образом так называемые «брандмауэры». Применение этого параметра, однако, до сих пор не описано в Н.248-сигнализации.
Задача настоящего изобретения заключается в том, чтобы обеспечить возможность SIP-оконечному устройству вызывающего абонента (пользовательскому оконечному устройству А установления вызова) выбрать наиболее эффективные потоки мультимедийных данных (полезные данные начальных мультимедийных данных). Эта задача решается, соответственно, признаками независимых пунктов.
SIP-оконечному устройству вызывающего абонента А обеспечивается возможность установить корреляцию между SIP-диалогами (ответами) и потоками мультимедийных данных (полезными данными начальных мультимедийных данных), чтобы выбрать подходящие потоки мультимедийных данных. Соответствующее изобретению применение адреса приема пользователя, являющегося адресатом вызова (IP-адрес/номер порта), который был передан от адресата (B/B') вызова, пользователю (А), являющемуся инициатором вызова, например, в SIP-сообщении промежуточного ответа или в SIP-сообщении заключительного ответа, для выбора из принятых пользователем (А), являющимся инициатором вызова (переданных пользователем (В), являющимся адресатом вызова), мультимедийных потоков данных (полезных данных начальных мультимедийных данных), - причем принимается, что переданный с помощью SIP-сигнализации (или с помощью транспортируемых посредством SIP протоколов, например, SDP) адрес приема пользователя-адресата вызова и указанный в принятых пользователем А пакетах мультимедийных потоков данных адрес передачи (IP-«адрес источника» и, например, UDP-«порт источника») адресата (В) вызова одинаковы, - обеспечивает простой и эффективный выбор потоков мультимедийных данных. Хотя теоретически возможно, что пользователь В применяет различные IP-адреса и/или различные порты для передачи и приема взаимосвязанных потоков мультимедийных данных, пользователь В, как показывает опыт, очень часто применяет для этого тот же самый IP-адрес и тот же самый порт. Соответствующее изобретению применение адреса приема пользователя-адресата вызова из SIP/SDP-сигнализации особенно полезно для того, чтобы выбирать потоки мультимедийных данных, которые должны подавляться. Тем самым предотвращается то, что пользователь А по ошибке подавляет потоки мультимедийных данных, если пользователь В для передачи и приема применяет различные IP-адреса и/или порты. В этом случае пользователь А, по меньшей мере, в состоянии представить «правильный» поток мультимедийных данных, если он принимается в качестве единственного. Например, пользователь А может, после получения заключительного SIP-ответа, в течение переходного периода времени принимать множество потоков мультимедийных потоков, но потоки мультимедийных данных, которые соответствуют оставшимся SIP-«начальным диалогам», как правило, спустя некоторое время закончатся.
В противоположность современному документу стандартизации IETF-SIPPING “draft-camarillo-sipping-early-media” (а именно, для согласования посредством SIP устанавливаемых для начальных мультимедийных данных собственных коммуникационных соединений) соответствующий изобретению способ действия является весьма эффективным в отношении количества подлежащих передаче по интерфейсу радиосвязи SIP-сообщений и меньших требуемых изменений оконечных устройств.
Данные адреса приема пользователя-адресата вызова, принимаемые во внимание при выборе, содержат, предпочтительным образом, IP-адрес и номер порта пользователя-адресата вызова (оконечного устройства В).
Сигнализируемые посредством SIP данные адреса приема пользователя-адресата вызова (IP-B, Port-B) для пользователя-адресат (В) вызова также могут представлять данные адреса передачи пользователя-адресата вызова (IP b, Port b) для этого пользователя-адресата (В) вызова, что, в частности, означает, что они одинаковы (IP-B=IP b, Port-B=Port b) или одинаковы с точностью до дополнения. Также может быть предпочтительным принимать во внимание только IP-адрес, но не порт, или даже принимать во внимание только префикс IРv6-адреса. Так, для мобильного 3GPP оконечного устройства (так называемого «пользовательского устройства» (UE) согласно 3GPP TS 23.060) гарантируется, что применяются только IP-адреса с тем же префиксом IРv6-адреса.
Другие признаки и преимущества изобретения вытекают из последующего описания примера осуществления со ссылками на чертеж, где схематично представлена сигнализация при установлении SIP-соединения и передаче потока мультимедийных данных в виде начальных мультимедийных данных.
Сотовые сети мобильной связи (такие как GSM, 3G, CDMA2000, TDSCDMA и т.д.) и стационарные сети, а также соответствующие оконечные устройства и способы сигнализации (SIP, SDP) известны специалисту в данной области техники (см., например, спецификации на www.3gpp.org).
На чертеже показан пользователь А, являющийся инициатором установления соединения вызова, который включает в себя часть соединения SIP-оконечного устройства А и часть сигнализации SIP-оконечного устройства А и который осуществляет связь через сеть мобильной связи (показанную здесь только в объеме необходимого для понимания изобретения SIP-посредника) с пользователем (=В), являющимся адресатом вызова и включающим в себя SIP-оконечное устройство В, и с пользователем (=В'), являющимся адресатом вызова и включающим в себя SIP-оконечное устройство В', по SIP-протоколу для установления соединения для передачи полезных данных. Например, часть соединения SIP-оконечного устройства А может представлять собой “IM-MGW”, часть сигнализации SIP-оконечного устройства А может представлять собой “MGCF”, SIP-посредник может представлять собой “S-CSCF”, и SIP-оконечное устройство В и В' может представлять собой “UE”. Для упрощения опущены некоторые SIP-сообщения, как, например, “100 Trying”, PRACK и 200 OK(PRACK). В показанном примере после сообщения 1 от части сигнализации SIP-оконечного устройства А к части соединения SIP-оконечного устройства А пытаются установить телекоммуникационное соединение (например, для речевого соединения или другого соединения для передачи полезных данных), причем до поднятия трубки (этап 15) вызываемым пользователем В на пользовательском оконечном устройстве-адресате В вызова, производится обмен сообщениями 3-7, 9, 10, 13 между пользователем-инициатором А установления соединения вызова и пользователем-адресатом В вызова (через сеть сигнализации через SIP-посредника). Часть соединения SIP-оконечного устройства А выбирает адрес (IP-адрес пользователя А (IP-A) и номер порта пользователя А (Port-A)), подлежащий применению для будущего приема SIP-оконечным устройством А, передает его на этапе 3 к части сигнализации SIP-оконечного устройства А, которая на этапе 4 посылает SIP-INVITE-сообщение с указанием адреса приема оконечного устройства А (IP-A, Port-A) SIP-посреднику телекоммуникационной сети (например, сотовой системы мобильной связи), который применяет SIP-ветвление и на этапе 5 или 6 это SIP-INVITE-сообщение передает на пользовательское оконечное устройство-адресат В вызова (SIP-оконечное устройство В) или на пользовательское оконечное устройство-адресат В' вызова (SIP-оконечное устройство В'), после чего на этапе 7 SIP-оконечное устройство В выбирает свой адрес приема пользователя-адресата вызова (IP В, Port В) и адрес передачи (IP b, Port b), в то время как на этапе 8 SIP-оконечное устройство В' выбирает свой адрес приема пользователя-адресата вызова (IP В', Port В') и адрес передачи (IP b', Port b'). На этапе 9 выбранный пользователем-адресатом В вызова адрес приема пользователя-адресата вызова (IP-В, Port В) вместе с однозначной идентификацией диалога В в сообщении промежуточного ответа SIP-181-Ringing («звонок») передается SIP-посреднику телекоммуникационной сети, которая на этапе 10 передает его вместе с адресом приема пользователя-адресата вызова (IP-В, Port В) пользователю-инициатору А установления соединения вызова. Кроме того, здесь на этапе 11, от другого пользователя-адресата В' вызова сообщение промежуточного ответа SIP 180 Session Progress («продолжение сессии») с адресом приема пользователя-адресата вызова (IP-В', Port-В') и идентификацией В' диалога передается SIP-посреднику и (на этапе 12) - SIP-оконечному устройству А (пользователю-инициатору А вызова).
Посредством получения сообщений 9 и 11 с различными идентификациями В и В' диалога часть соединения SIP-оконечного устройства А узнает, что имеет место сигнализация с двумя оконечными устройствами В и В' и что оба оконечных устройства, возможно, уже посылают данные к этому моменту времени (= начальные мультимедийные данные = потоки мультиимедийных данных) на (IP-A, Port-A), как на этапе 13 или 14 от SIP-оконечного устройства В или В' на оконечное устройство пользователя-инициатора А установления соединения вызова.
При этом SIP-оконечное устройство В (или другой адресат вызова и SIP-оконечное устройство В') дает адрес передачи IP b, Port b (или IP-b', Port-b') пользователя-адресата вызова, который указывает, откуда поступают данные, чтобы обеспечить возможность определения их происхождения у пользователя-инициатора А установления соединения вызова. Кроме того, переданные на этапах 13 или 14 начальные мультимедийные данные содержат также новый адрес получателя пользователя-инициатора А установления соединения вызова, который используется для IP-маршрутизации. Начальные мультимедийные данные могут, например, содержать тональные сигналы звонков (рингтоны), передаваемые произносимые тексты и т.д.
Если вызовы (при так называемом ветвлении) одновременно направляются на множество коммутационных узлов (посредников) телекоммуникационной сети и/или SIP-оконечных устройств (таких, как В, В') одновременно или последовательно и, в конечном счете, от адресованных оконечных устройств направляются на другие оконечные устройства, то от множества оконечных устройств промежуточные ответы и, в соответствующих случаях, начальные мультимедийные данные - потоки мультимедийных данных поступают в оконечное устройство А пользователя-инициатора установления соединения вызова, где их выбор оптимизируется в соответствии с изобретением простым и эффективным образом.
Это возможно, если (переданный в ответе) адрес приема пользователя-адресата вызова (IP В, Port В) идентичен адресу передачи (IP-b, Port-b) пользователя-адресата В вызова, и последний применяется для селекции, так что принимаемые оконечным устройством А пользователя-инициатора установления соединения вызова начальные мультимедийные данные (13, 14) с содержащимся в них адресом передачи (IP b, Port b) пользователя-адресата вызова могут селектироваться (для дальнейшей обработки или игнорирования) простым и эффективным способом без существенного изменения существующих устройств. Игнорирование данных может, например, выполняться, если после передачи сообщения заключительного ответа «200-ОК» на этапах 16, 17 от оконечного устройства-адресата В вызова на оконечное устройство А пользователя-инициатора установления соединения вызова сигнализируется успешное завершение установления вызова, так что после этого возникает «установленный диалог» между оконечным устройством А и оконечным устройством В, за счет чего потоки данных начальных мультимедийных данных, которые не соответствуют «установленному диалогу», возникшему на этапах 16/17, и которые содержат другой адрес передачи пользователя-адресата вызова, могут отбрасываться/подавляться/игнорироваться пользователем-инициатором установления соединения вызова. В соответствии с изобретением подавление осуществляется за счет того, что мультимедийные потоки данных с адресом передачи (IP-b', Port-b') игнорируются. Здесь принимается, что (IP-b', Port-b') и (IP-В', Port-В') идентичны, что на практике очень часто имеет место. Часть сигнализации SIP-оконечного устройства А передает части соединения SIP-оконечного устройства А сообщение 17, что мультимедийные потоки данных с адресом передачи (IP-b', Port-b') должны игнорироваться. Для этого в сообщение 17, например, вводится новый параметр, который представляет один или несколько адресов передачи, пакеты которых должны игнорироваться. Для этого может, например, служить параметр SDP, предложенный рабочей группой IETF MMUSIC “draft-ietf-mmusic-sdp-srcfilter”, который в SDP транспортируется в MOD-сообщении протокола Н.248.
В случае, если (IP-b', Port-b') и (IP-В', Port-В') действительно идентичны, можно избежать так называемого «отсечения», то есть недоступное соединение для передачи полезных данных, после установления соединения в рамках сигнализации на основе заключительного ответа SIP-оконечного устройства В после снятия трубки пользователем, завершается. Недоступное соединение для передачи полезных данных осуществляется за счет дальнейшей обработки не релевантных более потоков данных начальных мультимедийных данных SIP-оконечного устройства В' с другими адресами передачи IP b', Port b'. В противном случае, только после приема сообщения SIP-Cancel (этап 20) SIP-посредника в другом SIP-оконечном устройстве (В') (только) это SIP-оконечное устройство В' не могло бы больше отправлять потоки данных начальных мультимедийных данных, и отсечение могло бы сохраняться на протяжении переходного периода, если оконечное устройство А еще принимает эти начальные мультимедийные данные.
Если (IP-b, Port-b) и (IP-В, Port-В) не идентичны, то, несмотря на это, поток мультимедийных данных от SIP-оконечного устройства В представляется. Если бы, напротив, SIP-оконечное устройство А после получения сообщения 17 заключительного ответа «200-ОК» еще принимало бы сообщения с адреса (IP-b, Port-b), то «правильный» мультимедийный поток данных подавлялся бы, возможно даже после того, как никакие другие начальные мультимедийные данные, например, от оконечного устройства В' больше не будут приниматься.

Claims (14)

1. Способ выбора полезных данных (13 для В; 14 для В'), передаваемых на основе установления соединения вызова (1-12 и 15-19) между пользователем-инициатором установления соединения вызова (оконечное устройство А) и, по меньшей мере, одним пользователем-адресатом вызова (В; В') через, по меньшей мере, одну телекоммуникационную сеть (SIP-посредник),
при котором пользователь-инициатор (А) установления соединения вызова в ответном сообщении (9, 10 (для В); 11, 12 (для В')) применяет данные адреса приема (IP-B, Port-B; IP-B', Port-B') пользователя-адресата вызова для, по меньшей мере, одного пользователя-адресата (В, В') вызова, чтобы выбрать полезные данные (13 (/В); 14 (/В')), посланные пользователем-адресатом (В, В') вызова вместе с данными адреса передачи (IP b, Port-b; IP-b', Port-b' для В') пользователя-адресата вызова,
при этом данные адреса приема (IP-B, Port-B) пользователя-адресата вызова для пользователя-адресата (В) вызова также представляют данные адреса передачи (IP b, Port b) этого пользователя-адресата (В) вызова.
2. Способ по п.1, отличающийся тем, что применяемые для выбора данные адреса приема пользователя-адресата вызова содержат IP-адрес (IP-B) и/или порт (Port-B).
3. Способ по п.1, отличающийся тем, что выбор осуществляется путем отбрасывания пакетов потока мультимедийных данных с определенными адресами передачи (IP-b, Port-b; IP-b', Port-b' для В').
4. Способ по любому из пп.1-3, отличающийся тем, что между частью сигнализации SIP-оконечного устройства А и частью соединения SIP-оконечного устройства А передаются один или более адресов передачи (IP-b', Port-b' для В'), принятые с которых пакеты полезных данных должны отбрасываться.
5. Способ по п.4, отличающийся тем, что применяется SDP параметр, определенный рабочей группой IETF MMUSIC в проекте "drafy-ietf-mmusic-sdp-srcfilter", чтобы определить IP-адрес источника и UDP-порт источника.
6. Способ по п.1, отличающийся тем, что данные адреса приема (IP-B, Port-B) пользователя-адресата вызова извлекаются из SIP-сообщения, посланного от пользователя-адресата (В) вызова пользователю-инициатору (А) установления соединения вызова, в частности, SIP-сообщения промежуточного ответа или SIP-сообщения заключительного ответа.
7. Способ по любому из пп.1-3, отличающийся тем, что отсечение в конце установления соединения (16-18) для передачи полезных данных предотвращается за счет выбора для отбрасывания нерелевантных более полезных данных.
8. Способ по любому из пп.1-3, 6, отличающийся тем, что при выборе полезных данных отбрасываются полезные данные начальных мультимедийных данных пользователя-адресата (В, В') вызова после получения SIP-сообщения заключительного ответа в оконечном устройстве А пользователя-инициатора установления соединения вызова, которые принадлежат одному или более другим потокам полезных данных начальных мультимедийных данных, иных чем поток мультимедийных данных этого SIP-сообщения заключительного ответа.
9. Способ по любому из пп.1-3, 6, отличающийся тем, что при выборе полезных данных начальных мультимедийных данных пользователя-адресата вызова после получения сообщения пользователя-адресата (В') вызова, открывающего посредством получения новых данных адреса приема (IP-B, Port-B) пользователя-адресата вызова новый поток полезных данных начальных мультимедийных данных, отбрасываются полезные данные начальных мультимедийных данных из потоков полезных данных начальных мультимедийных данных, открытых перед этим новым потоком полезных данных начальных мультимедийных данных.
10. Способ по любому из пп.1-3, 6, отличающийся тем, что как только пользователь-инициатор (А) установления соединения вызова пошлет пользователю-адресату (В') вызова сообщение (SIP Cancel 20), завершающее SIP-диалог, он (А) отбрасывает начальные мультимедийные данные (как 13, 14), принимаемые от, по меньшей мере, этого пользователя-адресата (В') вызова с его (В') адреса приема (IP-B, Port-B') пользователя-адресата вызова.
11. Устройство для выбора полезных данных, передаваемых через телекоммуникационную сеть, причем полезные данные передаются в ответе пользователю-инициатору установления вызова, инициирующему вызов к пользователю-адресату вызова, содержащее
устройство сигнализации (часть сигнализации SIP-оконечного устройства А) и устройство для обработки соединений для передачи полезных данных (часть соединения SIP-оконечного устройства А), конфигурированное для использования данных адреса приема (IP-B, port-B; IP-B', port-B') пользователя-адресата вызова, содержащихся в ответном сообщении (9, 10 (для В); 11, 12 (для 12')), для, по меньшей мере, одного пользователя-адресата вызова (В, В'), чтобы выбрать полезные данные (13 (/В); 14 (/В')), посланные пользователем-адресатом (В, В') вызова вместе с адресом передачи (IP b, Port-b; IP-b', Port-b' для В') пользователя-адресата вызова, при этом данные адреса приема (IP-B, port-B) пользователя-адресата вызова для пользователя-адресата (В) вызова также представляют данные адреса передачи (IP b, Port-b) пользователя-адресата вызова этого пользователя-адресата (В) вызова.
12. Устройство по п.11, отличающееся тем, что пользователь-инициатор (А) установления соединения вызова содержит MGCF, или IM-MGW, или MRFC, или MPFP, или другое устройство коммутации телекоммуникационной сети.
13. Устройство по п.11, отличающееся тем, что для передачи полезных данных (начальных мультимедийных данных 13, 14) в SIP-сообщениях предусмотрено Н.248- или MEGACO-соединение, причем в Н.24- или MEGACO-соединениях указаны одни или более данных адреса пользователя-адресата вызова.
14. Устройство по п.11, отличающееся тем, что телекоммуникационная сеть является сетью мобильной связи.
RU2006116572/09A 2003-10-16 2004-09-24 Обработка начальных мультимедийных данных i RU2374777C2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10348208.3 2003-10-16
DE10348208A DE10348208A1 (de) 2003-10-16 2003-10-16 Behandlung von Early Media-I

Publications (2)

Publication Number Publication Date
RU2006116572A RU2006116572A (ru) 2007-11-27
RU2374777C2 true RU2374777C2 (ru) 2009-11-27

Family

ID=34442020

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2006116572/09A RU2374777C2 (ru) 2003-10-16 2004-09-24 Обработка начальных мультимедийных данных i

Country Status (12)

Country Link
US (1) US7577109B2 (ru)
EP (1) EP1673918B1 (ru)
KR (1) KR100963368B1 (ru)
CN (1) CN1868196B (ru)
AT (1) ATE358388T1 (ru)
AU (1) AU2004306948B2 (ru)
BR (1) BRPI0415407B1 (ru)
DE (2) DE10348208A1 (ru)
MX (1) MXPA06004147A (ru)
PL (1) PL1673918T3 (ru)
RU (1) RU2374777C2 (ru)
WO (1) WO2005039139A1 (ru)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100563282C (zh) * 2005-05-29 2009-11-25 华为技术有限公司 网络互通时主叫用户终端听被叫信号音的方法
JP4341628B2 (ja) * 2006-01-25 2009-10-07 コニカミノルタビジネステクノロジーズ株式会社 データ通信装置及びデータ通信処理プログラム
US20070294411A1 (en) * 2006-06-20 2007-12-20 Nokia Corporation Methods, Apparatuses, a System and Computer Program Products for Providing Early Session Media to Announce Another Media Session
US8850012B2 (en) * 2006-08-21 2014-09-30 Nokia Corporation Mechanism for charging and session handling supporting forking
CN101227303B (zh) * 2007-01-19 2011-08-24 中兴通讯股份有限公司 彩铃和彩像发送方法以及早媒体发送方法
CN101123593B (zh) * 2007-09-20 2010-06-09 中兴通讯股份有限公司 媒体网关控制功能实现早媒体功能的方法
US8107956B2 (en) * 2008-12-30 2012-01-31 Motorola Mobility, Inc. Providing over-the-top services on femto cells of an IP edge convergence server system
US8121600B2 (en) * 2008-12-30 2012-02-21 Motorola Mobility, Inc. Wide area mobile communications over femto-cells
US8384756B2 (en) * 2008-12-30 2013-02-26 General Instrument Corporation Video telephony device having functionality to mute incoming messages that are being recorded
US9532191B2 (en) 2012-05-18 2016-12-27 Kirusa, Inc. Multi-modal transmission of early media notifications
CN106489275B (zh) * 2014-07-16 2020-01-31 瑞典爱立信有限公司 会话发起协议分叉中的策略控制方法及节点
US10931719B2 (en) * 2015-04-20 2021-02-23 Avaya Inc. Early media handling
US10397285B2 (en) * 2016-02-29 2019-08-27 Nec Corporation Early-media service control device, early-media service control method, and storage medium having program stored thereon

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9715857D0 (en) * 1997-07-29 1997-10-01 Philips Electronics Nv Wireless networked message routing

Also Published As

Publication number Publication date
DE502004003359D1 (de) 2007-05-10
US7577109B2 (en) 2009-08-18
US20070002775A1 (en) 2007-01-04
CN1868196B (zh) 2012-11-07
WO2005039139A1 (de) 2005-04-28
KR20060133977A (ko) 2006-12-27
AU2004306948A1 (en) 2005-04-28
CN1868196A (zh) 2006-11-22
DE10348208A1 (de) 2005-05-19
EP1673918A1 (de) 2006-06-28
BRPI0415407A (pt) 2006-12-05
BRPI0415407B1 (pt) 2018-02-14
RU2006116572A (ru) 2007-11-27
AU2004306948B2 (en) 2009-07-30
PL1673918T3 (pl) 2007-08-31
ATE358388T1 (de) 2007-04-15
MXPA06004147A (es) 2006-06-27
EP1673918B1 (de) 2007-03-28
KR100963368B1 (ko) 2010-06-14

Similar Documents

Publication Publication Date Title
US7809125B2 (en) Method and apparatus for selection of special-purpose gateways
US7280532B2 (en) Call set-up method using SIP-T overlap signaling
RU2332804C2 (ru) Обработка начальных мультимедийных данных ii
US20080240375A1 (en) Method Of Processing Multiple Ring Back Tone In Voice Service Application Based On Sip Fork
WO2009115048A1 (zh) 基于同号移动终端与软终端通话切换方法、系统及设备
RU2374777C2 (ru) Обработка начальных мультимедийных данных i
US7443834B1 (en) Combining multimedia services with traditional telephony
US20050047423A1 (en) Protocol interworking framework
WO2008064580A1 (fr) Procédé, système et serveur d'application pour éviter la diaphonie de signal de rappel couleur
JP3990297B2 (ja) 応答処理制御方法
KR100514196B1 (ko) 네트웍 어드레스 변환 및 세션 관리 시스템 및 그 방법
US7620167B2 (en) Apparatus to override the redirect or reject feature at an SIP end point
EP1959608A1 (en) A method, a application server and a system for implementing the third party control service
KR101069530B1 (ko) 차세대통신망에서 착신 통화로 제어 장치 및 그 방법과, 그를 이용한 멀티미디어 정보 서비스 시스템 및 그 방법
US8249238B2 (en) Dynamic key exchange for call forking scenarios
EP2020813B1 (en) A method, device and system for implementing the session service
EP2088759A1 (en) A method, telephone system and telephone terminal for calling session
WO2009036801A1 (en) Methods and arrangements for a telecommunications system
KR100627818B1 (ko) 얼리 미디어 서비스 제공 방법 및 시스템
US8228918B2 (en) Method, communications system and communications terminal for establishing communication
KR101467388B1 (ko) 호 설정 메시지 송신 시스템 및 방법
KR101208119B1 (ko) 스마트 카드를 이용한 sip 기반 영상통화 서비스 시스템 및 그 방법
KR100963010B1 (ko) 스마트 카드를 이용한 sip 기반 영상통화 서비스 시스템및 그 방법
JP2006050250A (ja) Ip電話システム用の呼制御方法及び呼制御システム

Legal Events

Date Code Title Description
PC4A Invention patent assignment

Effective date: 20100706

PD4A Correction of name of patent owner