EP1878198A1 - Procede et serveur a protocole d'ouverture de session (sip) a fonction de verification des capacites des points d'extremite - Google Patents

Procede et serveur a protocole d'ouverture de session (sip) a fonction de verification des capacites des points d'extremite

Info

Publication number
EP1878198A1
EP1878198A1 EP06728027A EP06728027A EP1878198A1 EP 1878198 A1 EP1878198 A1 EP 1878198A1 EP 06728027 A EP06728027 A EP 06728027A EP 06728027 A EP06728027 A EP 06728027A EP 1878198 A1 EP1878198 A1 EP 1878198A1
Authority
EP
European Patent Office
Prior art keywords
sip
message
service
header
point capabilities
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP06728027A
Other languages
German (de)
English (en)
Inventor
Peter Postmus
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP1878198A1 publication Critical patent/EP1878198A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols

Definitions

  • the present invention relates to a method and system for verifying end-point capabilities information.
  • the Session Initiation Protocol is an Internet Engineering Task Force (IETF) standard protocol that allows for the establishment of interactive user sessions involving multimedia elements such as video, voice, chat, gaming, and virtual reality.
  • IETF Internet Engineering Task Force
  • SIP works in the application layer of the Open Systems Interconnection (OSI) communications model and can establish multimedia sessions or Internet telephony calls, modify, or terminate them.
  • OSI Open Systems Interconnection
  • the protocol can also invite participants to unicast or multicast sessions that do not necessarily involve the initiator. Because SIP supports name mapping and redirection services, it makes possible for users to initiate and receive communications and services from any location, and for networks to identify the users wherever they are.
  • SIP is a request-response protocol, dealing with requests from clients and responses from servers. Participants are typically identified by SIP Uniform Resource Identifiers (URIs). Requests can be sent through any transport protocol, such as the User Datagram Protocol (UDP), the Simple Control Transport Protocol (SCTP), or Transfer Control Protocol (TCP). SIP can determine the end system to be used for the session, the communication media and media parameters, and the called party's desire to engage in the communication. Once these are assured, SIP establishes call parameters at either end of the communication, and handles call transfer and termination. SIP is specified in lETF's Request for Comments [RFC] 3261, which is herein included by reference.
  • RRC Request for Comments
  • SIP services are typically implemented via SIP-based application servers.
  • a SIP application server is a server of the SIP-based distributed network that provides business logic for one or more application programs that enable the provision of SIP services. Examples of SIP services that may be provided to SIP users are: SIP conferencing service, SIP presence service, Push-To-Talk, SIP Session Forwarding, and Messaging Server.
  • Telecommunications equipment vendors developed SIP-based application servers that are currently reaching the market, as SIP services begin to be commercially exploited.
  • SIP-based application server including a SIP Servlet Application Programming Interface (API), called SSA, based on JAVA TM programming running on top of a PC server or other platforms, such as for example Linux.
  • the SSA offers an API that service developers can use to easily develop new SIP services, also called SIP applications.
  • SSA is based on the Hyper Text Transfer Protocol (HTTP) servlet mechanism.
  • HTTP Hyper Text Transfer Protocol
  • SSA The methods available in SSA are implemented in a SIP engine, also called the SIP container.
  • the main purpose of SSA is to offer an abstraction from the SIP protocol.
  • Ericsson included the SIP container in the Ericsson's Application Server (E-AS) as well as in Ericsson's Service Development Studio (SDS) package.
  • E-AS Ericsson's Application Server
  • SDS Service Development Studio
  • Such an application server is a 3GPP (3 rd Generation Partnership Project) defined SIP application server, which acts as a central node in the IP Multimedia System (IPMM) architecture for enabling SIP-based applications. It combines a SIP container implementing the SSA methods and a full computer server.
  • IPMM IP Multimedia System
  • ISC IP Multimedia Subsystem
  • IETF also defined so-called SIP option tags in RFC 3261 , which is also herein included by reference. These option tags indicate capabilities of the SIP end-points (e.g. User Equipment (UE), application servers, etc) of a SIP session.
  • SIP end-points e.g. User Equipment (UE), application servers, etc
  • end-points refer to and encompass any node in a route followed by a SIP message, which may not only include the sender and the receiver of the SIP message, but also any intermediate node, such as for example a SIP-based application server or proxy server, which may be configured to perform processing on the said SIP message.
  • the RFC 3261 describes a mechanism in which, during a SIP session, SIP end-points can request from other end-points the capabilities they support, or advertise their own capabilities, or require from the recipient end-point the support of specific capabilities to make the service provision successful.
  • SIP message headers of various SIP messages e.g. SIP INVITE message, SIP OPTION message, etc
  • option tag information “Require”, “Supported”, “Proxy-Required”, and "Unsupported”.
  • a SIP option tag is a string of characters associated with a particular SIP option (i.e., an extension), and identifies the option to SIP end-points.
  • Figure La shows a list 100 of exemplary various SIP option tags 102, along with their short descriptions 104.
  • option tags may also exist.
  • Each such option tag may be included in a header of a SIP message like a SIP INVITE message, alone or along with one or more other option tags.
  • a SIP end-point may include in a "supported" header of a SIP INVITE message the following option tag value:
  • a service running on a given SIP application server can act as an end-point and respond to a SIP request that it receives, or can initiate a SIP request by itself.
  • IETF is also currently defining another type of end-point capability through the so-called SIP feature tags which are indicative of SIP caller/callee preferences and capabilities.
  • Caller preferences are used, for example, to route a SIP request to the proper terminal of a given recipient (in SIP, a terminal is called User Equipment, i.e. UE), among possibly a plurality of terminals of the recipient, which supports capabilities indicated in the specific SIP message headers.
  • UE User Equipment
  • Callee preferences are used to advertise what capabilities are supported by a given UE (User Equipment) or required from a given UE to establish a SIP communication.
  • the UE may advertise its own capabilities through the use of SIP feature tags included, for example, using a SIP message's "Contact" header employed during a SIP registration process.
  • a given UE can also find out the feature tags supported by another UE by sending a SIP OPTIONS request to the SIP server. It may include a SIP "Contact" header with its own feature tags as well, so that each UE involved in a SIP session can learn about the other session participant's supported, or required, features.
  • feature tags included in the SIP request message insure that the SIP session is established with the UE that best corresponds to the tags required by the caller.
  • caller preferences describe how a SIP request can be best routed to a UE that supports certain feature tags.
  • Feature tags can be included in an "Accept-Contact", "Reject-Contact” and/or "Request-Disposition" header of various SIP messages, such as for example in SIP INVITE request messages, SIP OPTION request messages, etc, to ensure that the request message is routed to a terminal that registered with, or without, the network with that specific feature tag.
  • a SIP end-point may include in a "Contact" header of a SIP INVTE message the following feature tag value:
  • SIP services are developed by various application developers with different degrees of knowledge and programming experience. Due to this discrepancy in the developers' skills, it was noticed that not all new SIP services are developed with the ability of managing SIP option tags and feature appropriately, and that some SIP services do not support SIP option tags or feature tags at all. It is easy for a service developer to forget to include this functionality when programming a new SIP service. Thus, it may happen that a service cannot appropriately respond to an incoming SIP message. For example, a problem arises when an incoming SIP message requires the support of a particular option or feature tag from the recipient end-point, and when this end-point is not configured for providing such support.
  • the recipient end-point cannot properly treat the incoming message to provide a meaningful response. Most often, when this occurs, the receiving end-point provides no answer or a faulty answer to such SIP messages, and in both cases this may escalate into a drop of the SIP communication session.
  • the present invention is a method for processing an incoming Session
  • SIP Initiation Protocol
  • the present invention is a Session Initiation Protocol (SIP) application server comprising:
  • capabilities included in the incoming SIP message further determines whether or not the end- point capabilities included in the incoming SIP message match end-point capabilities of the SIP service, and upon determining that the end-point capabilities included in the incoming SIP
  • Figure Ia shows a list of various SIP option tags that may be included in SIP
  • FIG. 2 is an exemplary high-level block diagram of a SIP application server according
  • FIG. 3 is an exemplary representation of a SIP INVITE request comprising a SIP option
  • Figure 4 is an exemplary flowchart diagram of a method according to the preferred
  • SIP Session Initiation Protocol
  • application server is extended with service logic that automatically interprets SIP end-point
  • the SIP container invokes the SIP service and relays the message to the service for processing. Otherwise, a
  • the SIP container of the SIP application server analyses a deployment
  • descriptor file associated with the given service application
  • the value in this tag indicates the particular option tag supported or required by the service for the proper processing of SIP messages, or respectively the feature tag supported by the SIP service for the proper processing of SIP messages.
  • the same tag may appear multiple times if multiple option tags (or feature tags) are supported by the service.
  • the SIP container By analysing the deployment descriptor file of a SIP service, the SIP container reads the option tags and feature tags that are supported or required by the service. If no tag of a given type (e.g. no option tag) exists in the deployment descriptor of a given SIP service, it is assumed that there is no support in the SIP service for any option tags.
  • the SIP container of the SIP application server examines certain headers of the incoming SIP message in order to detects end-point capabilities, such as the option tags required and/or supported by the sender of the incoming SIP message, and/or the feature tags required by the said sender.
  • the SIP container Upon receipt of a SIP message, the SIP container inspects the above-mentioned message headers to determine which end-point capabilities are required by the sender end-point from the destination end-point, or supported by the sender side. Then, the SIP container further determines whether or not the destination SIP end-point service's capabilities match the capabilities indicated in the message. In the affirmative, the SIP container invokes the service and forwards the SIP message to the proper SIP service for processing. Otherwise, the SIP container does not invoke the destination SIP service, and may issue either a error message, or relay the message to another destination.
  • FIG 2 is an exemplary high-level block diagram of a SIP application server 200 according to the preferred embodiment of the present invention.
  • the SIP application server 200 which may comprise a computer system running an Operating System (OS), the server 200 further comprising a SIP container 202, also called a SIP engine, that implements SIP Servlet API (SSA) methods and service logic 204 supporting SIP-based communications for the server 200.
  • SIP container 202 also called a SIP engine
  • SSA SIP Servlet API
  • service logic 204 supporting SIP-based communications for the server 200.
  • two (2) SIP services 206 and 208 also called SIP applications, responsible for implementing particular services in the server 200.
  • the SIP services 206 and 208 are connected to the SIP container 202, as shown, via proper communication links and/or interfaces.
  • Each one of the SIP services 206 and 208 comprises a deployment descriptor file 210 and 212 respectively, which comprises information about the services' capabilities relative to the option tags and feature tags supported or required by each service.
  • the SIP service 206 comprises the deployment descriptor file 210 that includes the indications 214, 216, and 218 related to two option tags supported or required by the SIP service 206, as well as one feature tag supported by the service 206.
  • the deployment descriptor file 210 preferably also contains a set of mapping rules 219 (specified in SSA). These mapping rules 219 contain criteria indicating which messages the service wishes to receive. This can be indicated, for example, by specifying the message type (e.g. SIP INVITE, SIP REGISTER, etc), the Request URI (Uniform Resource Indicator), or using information from the message header (destination or sender identifier).
  • mapping rules 219 contain criteria indicating which messages the service wishes to receive. This can be indicated, for example, by specifying the message type (e.g. SIP INVITE, SIP REGISTER, etc), the Request URI (Uniform Resource Indicator), or using information from the message header (destination or sender identifier).
  • a new SIP service such as for example the SIP service 206 is installed in the SIP application server 200.
  • the SIP container 202 analyzes the new SIP service 206 in order to determine which end-point capabilities, i.e. which option tags and/or feature tags, are supported or required by the service.
  • the service 206 also comprises a deployment descriptor file 210 that stores information relative to its supported and/or required end-point capabilities (option tags and feature tags).
  • action 404 comprises analyzing by the SIP container 202 the deployment descriptor file 210 of the service 206 for determining the option tags and feature tags supported and/or required by to the SIP service 206.
  • the SIP engine 202 acquires knowledge about the option and feature tags used (supported or required) by the new application service 206, action 406.
  • the SIP application server 200 may receive a SIP message 220 from an external end-point, such as for example a SIP INVITE or a SIP REQUEST message, wherein the SIP message 220 comprises a Uniform Resource Identifier (URI) 222 that identifies the destination end-point of the message 220, and also destination end-point capabilities 223 that are either required from the destination end-point of the message 220 for the proper processing of that message, or supported by the sending end-point of the message 220.
  • URI Uniform Resource Identifier
  • the SIP container 202 of the application server 200 first determines in action 410 whether or not the incoming SIP message 220 is destined to a local end-point, i.e.
  • the SIP Container 202 may examine the Servlet Mapping rules 219 acquired from the deployment descriptor file 210 of the service 206 for comparing the URI 222 of the message 220 with the URI identifying the service 206 that act as a SIP end-point. In the negative, i.e.
  • the incoming SIP message 220 does not map with any of the mapping rules of the services, it is concluded that it is not destined to the local service 206, and in such as case, for example, the servlet mapping rules of the next service (e.g. of the service 208) are further analyzed in an analogous manner to determine whether or not the SIP message is destined to that service. If not, the SIP message 220 is further relayed (proxied) from the server 200 to the proper end-point external to the SIP application server 200, action 412.
  • the SIP container 202 further acts in action 414 to determine whether or not the end-point capabilities 223 specified in the message 220 in the headers described hereinbefore match the capabilities 214, 216, and 218 of the SIP service 206.
  • Such a determination 414 may be effectuated, for example, as shown in the above-mentioned table, which is reproduced hereinbelow, too.
  • the SIP container 202 determines in action 414 that a match is not achieved, like for example when one or more of the required end-point capabilities 223 are not supported by the SIP service 206, then it issues an error message (not shown) to the originator of the message 220 or alternatively may further relay(proxy) the SIP message 220 to yet another (alternate) destination, action 416. Otherwise, if the SIP container 202 rather determines in action 414 that a match is achieved between the end-point capabilities 223 specified in message 220 and the one related to the SIP service 206, then it invokes the service 206 and sends the SIP message 220 to that service, action 418.
  • the SIP service 206 processes the SIP message 220 according to its internal set-up for providing the appropriate service, and then returns to the SIP container 202 a SIP response message 230, a new SIP request 230 or even a copy of the original request 230, modified or unmodified, action 420.
  • the SIP container 202 sends out the SIP request and/or response message 230, which may be destined to the originator of the SIP message 220, or to any other party as required by the processing of the incoming SIP message 220.
  • FIG. 3 is an exemplary representation of a SIP INVITE request message 350 comprising SIP end-point capabilities in the form of SIP option tags 352, which are included in a "Supported” header 354 as well as in a “Required” header 356.
  • the INVITE message 350 is sent by a sender supporting the option tag “privacy” (shown in the "Supported” header 354) and who also wants the request to be routed to a terminating party that supports the same option tag “privacy” (shown in the "Required” option tag 356).
  • the "Required” field 356 of the SIP message header indicates that the SIP option "Privacy” is required from the destination end-point (the message receiver) for the message to be processed correctly, while the "Supported” field 354 of the SIP message header indicates that the SIP option "Privacy” is supported by the sender end-point.
  • the SIP container 202 inspects in previously described action 414.
  • the present invention provides an advantageous solution, which first verifies that the end- point capabilities specified in an incoming SIP message are matched by the ones supported and/or required by a given SIP service of the SP server, and only in the affirmative, the incoming SIP request message is forwarded to the service end-point. It should be realized upon reference hereto that the innovative teachings contained herein are not necessarily limited thereto and may be implemented advantageously with any applicable radio telecommunications standard that makes also use of SIP, or that supports SIP.
  • IMS IP Multimedia Subsystem

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé et un serveur d'application à protocole d'ouverture de session (SIP), serveur comprenant un conteneur SIP prenant en charge les communications SIP et un service SIP exploité sur le serveur SIP. Lorsqu'un message SIP est reçu au niveau d'un serveur d'application SIP, le conteneur SIP détecte que le message est destiné au service SIP local et détermine quelles capacités de points d'extrémité sont incluses dans le message SIP, ces capacités indiquant, par exemple, les exigences de traitement approprié du message. Le conteneur SIP détermine également si les capacités des points d'extrémité du service SIP correspondent à celles incluses dans le message SIP, et lors de la détermination de l'existence d'une correspondance, appelle le service SIP et retransmet le message au service. Autrement, si aucune correspondance n'est détectée, le conteneur SIP n'appelle pas le service SIP et délivre plutôt un message d'erreur ou retransmet le message SIP vers une autre destination.
EP06728027A 2005-04-26 2006-04-24 Procede et serveur a protocole d'ouverture de session (sip) a fonction de verification des capacites des points d'extremite Withdrawn EP1878198A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/114,155 US20060239247A1 (en) 2005-04-26 2005-04-26 Method and session initiation protocol (SIP) server with end-point capabilities check
PCT/IB2006/051272 WO2006114757A1 (fr) 2005-04-26 2006-04-24 Procede et serveur a protocole d'ouverture de session (sip) a fonction de verification des capacites des points d'extremite

Publications (1)

Publication Number Publication Date
EP1878198A1 true EP1878198A1 (fr) 2008-01-16

Family

ID=36753924

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06728027A Withdrawn EP1878198A1 (fr) 2005-04-26 2006-04-24 Procede et serveur a protocole d'ouverture de session (sip) a fonction de verification des capacites des points d'extremite

Country Status (3)

Country Link
US (1) US20060239247A1 (fr)
EP (1) EP1878198A1 (fr)
WO (1) WO2006114757A1 (fr)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8665714B2 (en) * 2004-06-16 2014-03-04 Avaya Inc. Call admission control of shared-access resources through a call-handling server
US20060099933A1 (en) * 2004-06-16 2006-05-11 Avaya Technology Llc Call admission control of a shared-access resource during a handover
US7830823B2 (en) * 2005-06-07 2010-11-09 Siemens Enterprise Communications, Inc. SIP telephone feature control
KR101331321B1 (ko) * 2005-12-07 2013-11-20 삼성전자주식회사 프레젼스 서비스를 제공 및 제어하는 방법
US8391165B2 (en) * 2005-12-30 2013-03-05 Motorola Mobility Llc Method and apparatus for identifying caller preferences matched to callee capabilities for IMS communications
US8842660B2 (en) * 2006-03-31 2014-09-23 Microsoft Corporation VoIP variable metadata
US20070253407A1 (en) * 2006-05-01 2007-11-01 Microsoft Corporation Enhanced VoIP services
US20070274293A1 (en) * 2006-05-26 2007-11-29 Microsoft Corporation Archiving VoIP conversations
US8139566B2 (en) * 2006-07-21 2012-03-20 Cisco Technology, Inc. System and method for establishing a communication session between two endpoints that do not both support secure media
US7864752B1 (en) * 2006-08-09 2011-01-04 Nortel Networks Limited Bearer path resource matching in a wireless communication network
US8484326B2 (en) * 2006-09-28 2013-07-09 Rockstar Bidco Lp Application server billing
FI20065756A0 (fi) * 2006-11-28 2006-11-28 Nokia Corp Ryhmäviestintä
US8170183B2 (en) * 2007-01-22 2012-05-01 Control4 Corporation Systems and methods for providing a message service for a site
KR101431826B1 (ko) * 2007-03-29 2014-08-25 삼성전자주식회사 프레젼스 소스로부터 프레젼스 정보를 직접 요청하기 위한시스템 및 방법
CN101374259B (zh) * 2007-08-22 2012-08-08 华为技术有限公司 实现多媒体彩铃和多媒体彩像业务的方法和装置
US8260944B2 (en) * 2007-09-07 2012-09-04 International Business Machines Corporation Using a state machine embedded within a session initiation protocol (SIP) servlet to implement an application programming interface (API)
CN101459664B (zh) * 2007-10-22 2010-10-20 华为技术有限公司 一种获取iptv业务媒体描述信息的方法及装置
CN101658011B (zh) * 2008-02-05 2013-11-06 华为技术有限公司 一种部署方法、sip业务的处理方法与设备
US20090300115A1 (en) * 2008-06-03 2009-12-03 Telefonaktiebolaget Lm Ericsson (Publ) Method, node and system for adapting a session initiation protocol (sip) message for an ip multimedia subsystem (ims)
EP2291963B1 (fr) * 2008-06-23 2016-04-27 BlackBerry Limited Procédé pour fournir des capacités de dispositifs et de serveurs
JP5260746B2 (ja) * 2008-09-05 2013-08-14 テレフオンアクチーボラゲット エル エム エリクソン（パブル） エンド・ツー・エンドのアドレス転送
US8179889B2 (en) * 2009-06-30 2012-05-15 Avaya Inc. SIP servlet applications co-hosting
US9843650B2 (en) * 2009-09-03 2017-12-12 Avaya Inc. Intelligent module sequencing
WO2014007708A1 (fr) * 2012-07-06 2014-01-09 Telefonaktiebolaget L M Ericsson (Publ) Procédé d'ajout de données de capacité client à un message sip
US9019869B2 (en) * 2012-12-07 2015-04-28 Avaya Inc. System and method to suppress voice prompts in SIP calls
US10491641B2 (en) * 2015-02-20 2019-11-26 T-Mobile Usa, Inc. Inter-IMS service support in telecommunication systems
US11153353B1 (en) * 2020-05-19 2021-10-19 Avaya Management L.P. Far end audio mode detection
US20230044527A1 (en) * 2021-07-20 2023-02-09 Samsung Electronics Co, Ltd. System and methods for handling immersive service in ip multimedia subsystem and mission critical services

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1886999B (zh) * 2003-12-30 2010-10-06 艾利森电话股份有限公司 自动发现多媒体服务能力的方法和通信系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006114757A1 *

Also Published As

Publication number Publication date
US20060239247A1 (en) 2006-10-26
WO2006114757A1 (fr) 2006-11-02

Similar Documents

Publication Publication Date Title
US20060239247A1 (en) Method and session initiation protocol (SIP) server with end-point capabilities check
EP1790149B1 (fr) Procede et serveur de protocole d'initiation de session (sip) pour echanger des capacites des terminaux d'extremite
US6904140B2 (en) Dynamic user state dependent processing
US8320349B1 (en) Combined user agent for packet-based communication clients
US8098671B1 (en) Monitoring datagrams in a data network
US8296447B2 (en) Method for copying session information, call control server for executing the same, and computer product
US7697471B2 (en) Address translation in a communication system
US20060187912A1 (en) Method and apparatus for server-side NAT detection
US20090310595A1 (en) Providing session initiation protocol (sip) call control functions to public switched telephone network (pstn)-based call controller
US11496531B2 (en) System and method to identify secure media streams to conference watchers in SIP messaging
WO2006064347A1 (fr) Procede et systeme de transfert instantane de fichiers multimedia entre des utilisateurs de radiocommunications mobiles desservis par des services combinatoires
US8656001B2 (en) Communication system, application server and communication method for server cooperation
JP2012100293A (ja) 異種通信ノードを特徴付けるための方法およびシステム
KR20030081433A (ko) Ｉｐ 기반 서비스 아키텍처
US20080208993A1 (en) Method For Distributing New Services in an Internet Multimedia Subsystem (Ims), and a Node Adapted Therefore
WO2007112640A1 (fr) Procédé et appareil de remplacement de l'identification de session, serveur d'application et procédé de remplacement de session
US20080137647A1 (en) VoIP terminal and method for providing multi-call service
EP1879345A1 (fr) Méthode pour transmettre un message du Session Initiation Protocol (SIP) en utilisant l'encapsulation SIP
Tiilikainen SIP (RFC 2543), an Implementation for Marratech Pro
KR100636279B1 (ko) 브이오아이피 시스템의 자원정보를 이용한 호제어 시스템및 그 방법
Bhat Voice Over IP–The SIP Way
KR100757535B1 (ko) 어플리케이션 구분이 가능한 멀티미디어 서비스 방법 및장치
WO2005107205A1 (fr) Correlation de trains de donnees multimedia
Le Kim THESIS/THÈSE
Chang et al. Towards mobile agent based provision of voice over IP services

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

17P Request for examination filed

Effective date: 20071120

17Q First examination report despatched

Effective date: 20080221

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20091103