WO2007033606A1 - Procede de negociation destine a l'adresse de transmission du flux multimedia - Google Patents

Procede de negociation destine a l'adresse de transmission du flux multimedia Download PDF

Info

Publication number
WO2007033606A1
WO2007033606A1 PCT/CN2006/002495 CN2006002495W WO2007033606A1 WO 2007033606 A1 WO2007033606 A1 WO 2007033606A1 CN 2006002495 W CN2006002495 W CN 2006002495W WO 2007033606 A1 WO2007033606 A1 WO 2007033606A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
codec
media stream
message
media
Prior art date
Application number
PCT/CN2006/002495
Other languages
English (en)
Chinese (zh)
Inventor
Peili Xu
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2007033606A1 publication Critical patent/WO2007033606A1/fr

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/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1043—Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • 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/24—Negotiation of communication capabilities

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method for negotiating a media stream transmission address based on a Session Description Protocol (SDP).
  • SDP Session Description Protocol
  • the implementation of the service mainly includes two aspects: signaling control part, media processing and transmission.
  • the signaling part is used to establish a session relationship between the communication entities, and complete negotiation of the communication parameters of both parties.
  • the media processing part mainly performs media stream communication by using a specific media stream packing and transmission method according to the result of signaling negotiation.
  • the real-time transport protocol For real-time media streams such as audio or video, the real-time transport protocol (RTP protocol) is mainly used.
  • RTP protocol real-time transport protocol
  • TCP For media stream transmission of data services such as electronic whiteboards, a protocol such as TCP that can ensure reliable transmission is usually used.
  • the description of the media stream parameters in the signaling negotiation process is mainly based on the SDP protocol, and the two parties negotiate the parameters of the communication address, media stream type, codec capability, etc. through SDP negotiation.
  • the method of negotiation of the communication address is: the party providing the SDP carries the media stream capability supported by itself and the communication address corresponding to each media stream. After the two parties complete the SDP negotiation, the media stream is sent to the specified address.
  • the main definitions are as follows:
  • connection information - not required if included in all media zero or more media descriptions ( see below )
  • the parameters related to the media stream communication address are as follows:
  • the SIP protocol defines how to use SDP to negotiate media capabilities (including media communication addresses).
  • the typical process is as follows (the header fields not related to the present invention are omitted):
  • Step 1 The calling SIP user (a@domain.com) goes to the called party via the INVITE message.
  • Ra audio 49170 RTP/AVP 0
  • the information of the c line indicates that the media stream receiving address of the calling party is 10.0.0.1; the information table of the m line
  • the caller wants to create an audio media stream, the codec is O (PCMU), and the receiving port number of the media is 49170. That is, the calling party wants the peer to send the media stream to the address with port number 49170 and IP address 10.0.0.1.
  • Step 2 The called SIP user (b@domain.com), if it is willing to accept the call after receiving the INVITE, responds to the called party (b@domain.com) with a 200 OK message, which contains the media capabilities of the called party.
  • the message is as follows:
  • the information in row c indicates that the media stream receiving address of the called party is 10.0.0.2; the m line information indicates that the called party agrees to establish an audio media stream, the codec is 0 (PCMU), and the receiving port number of the media is 1234. . That is, the called party wants the peer to send the media stream to the address with port number 1234 and IP address 10.0.0.2.
  • Step 3 The calling SIP user (a@domain.com) sends an ACK message to the called party after receiving the 200, indicating that the 200 OK is received.
  • the message is as follows:
  • Step 4 After the above process is completed, both the calling party and the called party complete the session establishment and media negotiation process.
  • the media stream is sent from the IP address and the port number for the media stream transmission provided to the peer end respectively according to the media stream parameters determined by the negotiation.
  • the syntax is as follows:
  • ⁇ port> represents the media receiving port number corresponding to a media stream
  • the first media stream receives port number 1234, the second one is 5678, but the IP address is 10.0.0.2.
  • the current media stream address negotiation mechanism has the following problems:
  • the terminal can support multiple codecs in one media stream, and it is desirable to select different receiving ports according to different codecs.
  • the existing negotiation mechanism cannot be achieved.
  • the present invention provides a media stream transmission address negotiation method to solve the problem that the existing media stream transmission address negotiation cannot support specifying a transmission address for different codec formats of the media stream.
  • a method for negotiating a media stream address includes the following steps:
  • the first device sends a message including Session Description Protocol (SDP) information to the second device, and specifies a corresponding transport address in the SDP information for part or all of the codec formats of the media stream that the first device needs to establish;
  • SDP Session Description Protocol
  • the second device obtains each codec format and corresponding transport address of the media stream to be established from the SDP information of the received message, determines a codec format desired by the device, and returns a codec format and a corresponding transport address. Response message.
  • the second device may provide a codec format and corresponding transport address information supported by the network device, which may be a uniquely determined codec and a transport address thereof. , or one of the various codecs supported by or supported by the local end and their corresponding transport addresses.
  • the network device After receiving the message sent by the first device or the response message of the message, the network device that supports the message sent by the first device and the second device supports each codec format and corresponding transport address of the media stream. Join the SDP information of the message.
  • the network device determines that the codec format selected by the second device is a codec format supported by the first device, and directly establishes a desired media stream between the first device and the second device.
  • the network device determines that the codec format selected by the second device is a codec format supported by the network device but is not supported by the first device, and establishes a media stream with the first device and the second device, respectively, and completes the codec conversion.
  • the message is a SIP signaling message; or the message is an MGCP signaling message; or the message is an H.248 signaling message.
  • the media description part of the SDP extends at least an attribute definition of the media stream codec format, and the attribute definition describes the codec format and the corresponding transport address.
  • the transport address is not explicitly specified in the attribute definition, it is obtained from the corresponding attribute definition according to the SDP specification.
  • the present invention supports the transmission address negotiation based on the codec level, and the conversion gateway can add the codec information and its transmission address supported by the SDP in order to determine whether the calling party and the called party have matching media capabilities. Achieving flexible control requires a session process for codec conversion.
  • a communication device in a communication network based on the SIP, MGCP, and H.248 protocols based on the SDP protocol can negotiate media transmission addresses corresponding to different codecs in the media stream.
  • 1 is a flowchart of processing a media stream address between a calling party and a called party according to an embodiment of the present invention
  • 2 is a schematic diagram of an intelligent codec conversion gateway participating in session media capability negotiation according to an embodiment of the present invention
  • FIG. 3 is a flow chart of media capability negotiation in a case where the calling and called capabilities are not matched according to an embodiment of the present invention
  • FIG. 4 is a flowchart of media capability negotiation in a case where the calling and called capabilities are matched according to an embodiment of the present invention
  • FIG. 5 is a flowchart of implementing media capability negotiation in a multi-network address application according to an embodiment of the present invention. detailed description
  • the devices participating in the media stream can complete the negotiation of the media stream address, and the present invention is in the SIP message.
  • SDP session description protocol
  • a corresponding transport address is respectively specified for part or all of the codec formats of the media stream that is desired or willing to be established, so that the device participating in the negotiation can select the corresponding transport address according to different codec formats.
  • a corresponding transmission address is respectively specified for part or all of the codec formats of the media stream that is desired to be established; and the party that receives the SIP signaling message may select one of its own wishes.
  • the codec format and notify the other party through the response message, or in the SDP part of the response message sent to the other party respectively specify a corresponding transport address for some or all of the codec formats of the media stream that is willing to be established, and then select the party that initiated the negotiation.
  • a desired codec format and notify the other party, the other party gives confirmation.
  • a border gateway located between two different network domains may have a codec conversion function, and a gateway across a network domain needs to pass a boundary.
  • the gateway transmits the media stream, and when the media capabilities between the devices do not match, the session can be established through the media conversion function. Therefore, when the gateway forwards the SIP message related to the media stream address negotiation between the two devices, when adding the codec supported by the message to the message, the transmission address corresponding to the codec added by itself is also added to the message. If the device that selects the codec format selects the codec format that does not support the other end device, the selection is made by the conversion gateway.
  • the device selecting the codec format will establish and convert the media connection between the gateways, which is completed by the conversion gateway between the devices.
  • Codec format conversion if the codec format supported by the other end device is selected (the conversion is not required at this time), the media connection is established directly between the devices.
  • the present invention extends at least the definition line of the media stream codec format in the media description part of the SDP, and the definition line describes the codec format and the corresponding transport address.
  • a description of a media stream can have one or more such defined lines.
  • the present invention is described in detail by taking the media capability negotiation in the SIP session establishment process as an example.
  • the header field not related to the codec format and the transmission address definition of the present invention is omitted.
  • the description of the media stream address information in the SDP protocol is extended to indicate the address information used by a specific codec in the following manner:
  • the addrtype can specify that the address is rtp, rtcp or other types. If not, the default is the default address type of the media stream.
  • m audio 1234 RTP/AVP 0 4 8 18;
  • Step 100 The calling SIP user (a@domain.com) sends an INVITE message to the called party (b@domain.com) ) Initiating a session request containing the media capabilities of the calling party (including the media communication address).
  • the message is as follows:
  • the information of row c indicates that the media stream receiving address of the calling party is 10.0.0.1; the information of the m line indicates that the calling party wishes to establish an audio media stream, and the codec can be 0 (PCMU), 4 (G.723), 8 (PCMA), the default receiving port number for this media is 49170.
  • the following a lines respectively specify that the receive port number of codec 0 (PCMU) is 50000, and the receive port number of codec 8 (PCMA) is 55000. Codec 4 (G.723) is not specified, so the port number is still the default port number of the media stream 49170.
  • Step 110 After the called SIP user (b@domain.com) receives the INVITE and is willing to accept the call, the 200 OK message is sent to the called party (b@domain.com), which includes Called media ability.
  • the message is as follows:
  • the information in row c indicates that the media stream receiving address of the called party is 10.0.0.2; the m line information indicates that the called party agrees to establish an audio media stream, the codec is 0 (PCMU), and the receiving port number of the media is 1234. . That is, the called party wants the peer to send the media stream to the address with port number 1234 and IP address 10.0.0.2.
  • Step 120 The calling SIP user (a@domain.com) sends an ACK message to the called party after receiving the 200, indicating that the 200 OK is received.
  • the message is as follows:
  • Step 130 After the above process is completed, the calling party and the called party complete the session establishment and media negotiation process, and respectively send media streams according to the media stream parameters determined by the negotiation to the IP address and port number provided by the peer for media stream transmission.
  • the called party selects codec 0 (PCMU). According to the SDP information provided by the calling party, it should send the media stream to the calling port 50000. If the called party chooses Codec 8 (PCMA), it should be sent to the calling 55000 port.
  • PCMU codec 0
  • PCMA Codec 8
  • the conversion gateway adds the transmission address corresponding to the codec added by itself to the codec when it adds its own codec to the SIP message.
  • the session can be established through the media conversion function, for example: the calling party supports codecl; the called party supports codec2, and the conversion gateway supports conversion between the two, then the actual media
  • the channel establishment situation is that the calling party sends the codecl media to the gateway and converts it to codec2 and then forwards it to the called party, and vice versa. If the two capabilities match, there is no need to perform codec conversion, and the media stream can still be established directly between the calling and the called.
  • Step 300 The calling SIP user @domain.com) initiates a session request to the called party (b@domain.com) through the INVITE message, and the message passes through the translation gateway, which includes the media capabilities (including the media communication address) of the calling side.
  • the message is as follows:
  • Step 310 The switching gateway forwards the INVITE message to the called side, but considering the codec conversion that may occur due to the capability mismatch between the calling and the called parties, the switching gateway adds more codec capabilities supported by the SDP. Including media communication address).
  • the message is as follows:
  • the conversion gateway adds its own codec 4 (G.723) and the transport address 11.0.0.1 port number is 2345.
  • Step 320 The called SIP user (b@domain.com), if it is willing to accept the call after receiving the INVITE, responds to the called party (b@domain.com) by a 200 OK message, and the message is returned to the conversion gateway. Since the called party only supports codec 4, it returns its own media capability message as follows:
  • the information of row c indicates that the media stream receiving address of the called party is 10.0.0.8; the information of the m line indicates that the called party agrees to establish an audio media stream, and the codec is 4 (G.723), the receiving port number of the media. It is 3456. That is to say, the called party wants the peer to send the media stream to the address with the port number 3456 and the IP address 10.0.0.8.
  • Step 330 The conversion gateway forwards the response message to the calling SIP user (a@domain.com). Since the called party selects its own codec 4, and the caller only supports codec 0, it is judged that codec conversion is required. Since the caller only supports codec 0, it returns its own allocated codec conversion.
  • the media channel address information of the codec 0 is processed. The message is as follows:
  • Step 340 After receiving the 200, the calling SIP user (a@domain.com) sends an ACK message to the called side to confirm that the 200 OK is received.
  • the message is sent to the translation gateway as follows:
  • Step 350 The conversion gateway forwards the ACK to the called party, and the message is as follows:
  • Step 360 After the above process is completed, the calling party and the called party actually establish a media connection with the switching gateway respectively, and the media stream between the calling side and the switching gateway adopts codec 0, that is, the media stream a-gw, the called side and The codec 4 is used between the conversion gateways, that is, the media stream gw-b.
  • the difference between the processing flow and the flow shown in FIG. 3 is that although the conversion gateway increases its own support capability, since the called side and the calling side have common capabilities, the called party finally selects the ability of the calling party to support, Thereby establishing a media connection directly with the caller.
  • Steps 400-410 The process of calling -> switching gateway, switching gateway -> called is the same as the processing in the process of Figure 3.
  • Step 420 The called SIP user (b@domain.com), if it is willing to accept the call after receiving the INVITE, responds to the called party (b@domain.com) by a 200 OK message, and the message is returned to the conversion gateway. Since the called party supports codec 0, it returns its own media capability message as follows:
  • Content-Type application/sdp Content-Length: ...
  • the information in row c indicates that the media stream receiving address of the called party is 10.0.0.8; the information of the m line indicates that the called party agrees to establish an audio media stream, the codec is 0 (PCMU), and the receiving port number of the media is 3456. . That is, the called party wants the peer to send the media stream to the address with the port number 3456 and the IP address 10.0.0.8.
  • Step 430 The conversion gateway forwards the response message to the calling SIP user (a@domain.com). Since the called party selects not the codec 4 added by itself, but the codec 0 supported by the calling party, it is judged that the codec conversion is not required, and it directly returns the called SDP information to the calling side.
  • the message is as follows:
  • the information of the c line indicates that the received media stream receiving address is 10.0.0.8; the m line information indicates that the called party agrees to establish an audio media stream, the codec is 0 (PCMU), and the receiving port number of the medium is 4567. . In other words, the called party wants the peer to send the media stream to the port number 4567, IP.
  • the address is 10.0.0.8.
  • Step 440-450 The calling party sends an ACK message to the called party.
  • Step 460 After the above process is completed, the calling and the called parties have the same codec capability, and the media conversion is not required by the switching gateway, and the media stream is directly established between the calling party and the called party.
  • the method of the present invention is equally applicable to applications in which a media device supports multiple network addresses. If the calling media processing device is a gateway device that supports multiple IP addresses, different boards provide different types of codec support, and different boards provide different network interfaces (with independent network addresses). At this time, it is necessary to specify the network address of the corresponding board for different codec capabilities during the media capability negotiation process. It is also possible to specify different port numbers depending on the implemented policy. Such as:
  • PCMU Codec 0
  • PCMA PCMA
  • Codec 4 (G.723) has a connection address of 10.0.0.2
  • Codec 18 (G.729) has a connection address of 10.0.0.3
  • Step 500 The calling SIP user (a@domain.com) initiates a session request to the called party (b@domain.com) through the INVITE message, which includes the media capabilities (including the media communication address) of the calling side gateway.
  • the message is as follows:
  • the information of the c line indicates that the default receiving address of the media stream of the calling party is 10.0.0, 1; the information of the m line indicates that the calling party wishes to establish an audio media stream, and the codec can be O (PCMU), 4 (G .723 ), 8 ( PCMA ), 18 ( G729 ).
  • the default receiving port number for this media stream is 1234.
  • the following a-line separately specifies that the receiving IP address of codec 4 (G.723) is 10.0.0.2, and the receiving IP address of codec 18 (G.729) is 10.0.0.3.
  • the codec O (PCMU), 8 (PCMA) is not specified, so the IP address still uses the default address of the media stream 10.0.0.1.
  • Step 510 The called SIP user (b@domain.com), if it is willing to accept the call after receiving the INVITE, responds to the called party (b@domain.com) with a 200 OK message, which includes the called media capability.
  • the message is as follows:
  • the information of the c line indicates that the media stream receiving address of the called party is 10.0.0.8; the information of the m line indicates that the called party agrees to establish an audio media stream, the codec is 0 (PCMU), and the receiving port number of the medium is 1234. . That is, the called party wants the peer to send the media stream to the address with port number 1234 and IP address 10.0.0.2.
  • Step 520 The calling SIP user (a@domain.com) sends an ACK message to the called party after receiving the 200, indicating that the 200 OK is received.
  • the message is as follows:
  • Step 530 After the foregoing process is completed, the calling party and the called party complete the session establishment and the media negotiation process, and respectively send the body stream according to the media stream parameter determined by the negotiation to the IP address and port number provided by the peer end for media stream transmission.
  • the present invention is not limited to this.
  • the present invention is also applicable to the MGCP and H.248 protocol communication networks based on the SDP protocol, and the same is true by the MGCP or H.248 protocol.
  • the negotiation process of the codec transmission address in the present invention may be included in various SDP negotiation scenarios allowed by the corresponding application layer protocols (SIP, MGCP, H.248, etc.), including but not limited to: session establishment. , session modification, re-initiation of capability negotiation, etc.

Abstract

La présente invention concerne un procédé de négociation destiné à l'adresse de transmission du flux multimédia, qui comprend l'envoi de message comprenant l'information sur le protocole de description de session (SDP) à partir du premier dispositif vers le second dispositif, l'adresse de transmission respective est spécifiée pour tout ou une partie des formats codec du flux multimédia que le premier dispositif prévoit établir; le second dispositif obtient divers formats codec et leurs adresses de transmission respectives du flux média qui devraient être établis à partir de l'information SDP incluse dans le message reçu; détermine lui-même le format codec attendu, et renvoie un message de réponse de l'information SDP comprenant le format codec et son adresse de transmission.
PCT/CN2006/002495 2005-09-23 2006-09-22 Procede de negociation destine a l'adresse de transmission du flux multimedia WO2007033606A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN200510104899.2 2005-09-23
CN200510104899 2005-09-23
CN200510106295.1 2005-09-30
CN200510106295.1A CN1937620A (zh) 2005-09-23 2005-09-30 一种媒体流传输地址的协商方法

Publications (1)

Publication Number Publication Date
WO2007033606A1 true WO2007033606A1 (fr) 2007-03-29

Family

ID=37888559

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/002495 WO2007033606A1 (fr) 2005-09-23 2006-09-22 Procede de negociation destine a l'adresse de transmission du flux multimedia

Country Status (2)

Country Link
CN (1) CN1937620A (fr)
WO (1) WO2007033606A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101141807B (zh) * 2007-08-25 2011-10-26 中兴通讯股份有限公司 一种编解码协商方法
CN110062056B (zh) * 2018-01-19 2021-11-02 中兴通讯股份有限公司 网络地址转换方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003032585A1 (fr) * 2001-10-09 2003-04-17 Nokia Corporation Systeme de transcodage dans une initiation de session
CN1533107A (zh) * 2003-03-18 2004-09-29 华为技术有限公司 一种ip网络中的媒体流处理方法
KR20050080619A (ko) * 2004-02-10 2005-08-17 주식회사 케이티 접속 설정 프로토콜 가입자 코덱제공서버를 이용한 호처리 시스템 및 그 코덱 매칭 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003032585A1 (fr) * 2001-10-09 2003-04-17 Nokia Corporation Systeme de transcodage dans une initiation de session
CN1533107A (zh) * 2003-03-18 2004-09-29 华为技术有限公司 一种ip网络中的媒体流处理方法
KR20050080619A (ko) * 2004-02-10 2005-08-17 주식회사 케이티 접속 설정 프로토콜 가입자 코덱제공서버를 이용한 호처리 시스템 및 그 코덱 매칭 방법

Also Published As

Publication number Publication date
CN1937620A (zh) 2007-03-28

Similar Documents

Publication Publication Date Title
JP4746054B2 (ja) ネットワーク用通信デバイスのためのメディアクライアントのアーキテクチャ
EP1832087B1 (fr) Procede de commande a distance de dispositifs medias par un reseau de communication
Singh et al. Interworking between sip/sdp and h. 323
US7301913B2 (en) Transcoding arrangement in a session initiation
Dalgic et al. Comparison of H. 323 and SIP for IP Telephony Signaling
JP4875169B2 (ja) ホームネットワークに対するリモートアクセスのための方法及び装置
US20080165787A1 (en) Method for negotiating about the media stream packet time length
US6738390B1 (en) SIP-H.323 gateway implementation to integrate SIP agents into the H.323 system
TWI434562B (zh) 藉由私人網路致能多媒體通信之方法與配置
US20090092109A1 (en) Method and Apparatus for Enabling Discovery Within a Home Network
EP1389862A1 (fr) Interception legale pour appels VOIP dans un réséau de telecommunications IP
US20070198669A1 (en) Plug-and-play device for videophony applications on packet-switched networks
TW201002018A (en) Method for predicting port number of NAT apparatus based on two STUN server inquiry results
Arora et al. Voice over IP: Protocols and standards
US20080208993A1 (en) Method For Distributing New Services in an Internet Multimedia Subsystem (Ims), and a Node Adapted Therefore
KR100514196B1 (ko) 네트웍 어드레스 변환 및 세션 관리 시스템 및 그 방법
WO2007019777A1 (fr) Méthode d’établissement de session et nœud de contrôle de session
WO2007036124A1 (fr) Procédé d'adressage dans un système de communication
WO2007098653A1 (fr) Dispositif de pontage de flux multimédia et système de services multimédia
WO2007033606A1 (fr) Procede de negociation destine a l'adresse de transmission du flux multimedia
US7310665B2 (en) Method, gateway system and arrangement in a communication network
WO2011054318A1 (fr) Procede, dispositif et systeme de negociation de sessions multimedia
EP1871067B1 (fr) Procede d'appel entre les terminaux d'un systeme de communication multimedia par paquets
Jones h. 323 protocol overview
US8009664B2 (en) Method for exchanging media description information between user agents using session initiation protocol

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06791085

Country of ref document: EP

Kind code of ref document: A1