WO2008080334A1 - Agent d'utilisateur dos à dos et procédé de transmission d'informations associé - Google Patents
Agent d'utilisateur dos à dos et procédé de transmission d'informations associé Download PDFInfo
- Publication number
- WO2008080334A1 WO2008080334A1 PCT/CN2007/071236 CN2007071236W WO2008080334A1 WO 2008080334 A1 WO2008080334 A1 WO 2008080334A1 CN 2007071236 W CN2007071236 W CN 2007071236W WO 2008080334 A1 WO2008080334 A1 WO 2008080334A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- route
- message
- record
- user agent
- header field
- Prior art date
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/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/36—Backward learning
-
- 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/1046—Call controllers; Call servers
Definitions
- the invention relates to the field of communications, in particular to an IP (Internet Protocol) multimedia subsystem (IMS, IP Multimedia Subsystem).
- IP Internet Protocol
- IMS IP Multimedia Subsystem
- RFC 3840 defines a method for carrying the capabilities and feature information of a user agent in the parameters of the Contact header field of the SIP message, so that when the user initiates the registration or conversation, the capability and feature information can be notified in the Contact header field.
- the intermediate network element and/or the peer user agent serve as an important reference for the intermediate network element and the peer user agent to process the dialogue.
- the terminal can use the isfocus parameter in the contact header field to make the terminal aware that the opposite end of the current conversation is the conference center, so as to guide the user to perform related operations on the conference, such as Subscribe to the meeting status.
- the method of carrying the capability and feature information of the terminal through Contact defined by RFC 3840 can be operated well in the case where the signaling path is Proxy; however, if there is a back-to-back user agent in the signaling path (B2BUA, Back) To Back User Agent), since the back-to-back user agent modifies the Contact header field of the message while forwarding the Invite message, the capability and feature information of the originating UA will be modified at the B2BUA, but cannot be delivered to the subsequent network element and / or UA receiving the conversation.
- Step SI The user sends an INVITE request, which carries sip: Conf-Factory, indicating that the conference is in progress.
- Step S2 The user agent 1 receives the INVITE request and forwards it.
- Step S3 The back-to-back user agent receives the INVITE request and forwards it.
- Step S4 The user agent 2 receives the INVITE request and forwards it to the conference center.
- Step S5 After receiving the INVITE request, the conference center returns a 200 OK response, and carries the Conf-ID and isfocus parameters in the Contact header field.
- Step S6 After receiving the 200 OK response, the user agent 2 forwards it to the back-to-back user agent.
- Step S7 After receiving the 200 OK response, the back-to-back user agent changes the Contact header field to the address of the back-to-back user agent (Contact: B2BUA), and then forwards it to the user agent 1.
- Contact B2BUA
- Step S8 After receiving the 200 OK response, the user agent 1 forwards the response to the user.
- the back-to-back user agent modifies the Contact header field to the address of the back-to-back user agent, the original Conf-ID and isfocus parameters are lost in the Contact header field, so that the user cannot know the address of the conference center according to the Conf-ID and isfocus parameters, and thus cannot Conduct conference-related operations, thereby affecting the provision of conference services.
- the invention provides a method of transmitting information of a user agent and a back-to-back user agent, which can avoid the influence of back-to-back user agents on the conference service.
- the present invention provides a method for back-to-back user agent to transmit information, including: receiving a session establishment request message or a session establishment response message; retaining an original Contact header field in the message, and adding a back-to-back user agent address in the message Record-Route header field; forwards the message to which the Record-Route header field has been added.
- the present invention also provides a back-to-back user agent, comprising: a receiving unit, configured to receive a dialog establishment request message or a dialog establishment response message; and a Record-Route processing unit, configured to add a Record carrying a back-to-back user agent address in the message- a route header field, and retaining the original Contact header field in the message; and a sending unit, configured to forward the message processed by the Record-Route processing unit.
- the invention also provides a computer readable medium storing a back-to-back user agent transmission letter
- the software of the method when the software is executed, includes the following steps: receiving a dialog establishment request message or a dialog establishment response message; retaining the original Contact header field in the message, and adding a back-to-back user agent address in the message Record-Route header field; forwards the message to which the Record-Route header field has been added.
- the back-to-back user agent carries the routing address through the Record-Route header field instead of modifying the Contact header field, so that the Conf-ID and isfocus parameters carried in the Contact header field of the conference center are transmitted to the user, and the user can according to the Conf-ID and the isfocus.
- the parameters carry out other related operations of the conference call, thereby ensuring the normal development of the conference service.
- FIG. 1 is a schematic diagram of a conference application process in the prior art
- FIG. 2 is a schematic diagram of a conference application process according to a first embodiment of the present invention
- FIG. 3 is a schematic diagram of a back-to-back user agent according to a first embodiment of the present invention
- FIG. 4 is a schematic diagram of a dialog flow of a second embodiment of the present invention.
- FIG. 2 is a schematic diagram of a conference application process according to a first embodiment of the present invention. Since the back-to-back user agent associates two conversations in one conversation, it is necessary to maintain a separate route set for the two conversations, and the two routing sets are independent of each other, so when the back-to-back user agent receives the conversation establishment request message, All Record-Route saves in the dialog establishment request message are taken out as the route set of the dialog establishment requestor. When the back-to-back user agent forwards the request message, all the Record-Routes in the received request are removed first, and the UAS (UA server, user agent server) subsequent request is guaranteed in order not to modify the Contact header field in the original request message. Being able to route to itself correctly, the back-to-back user agent adds a Record-Route header field when forwarding the request message, carrying the address of the back-to-back user agent.
- UAS U server, user agent server
- the back-to-back user agent When the back-to-back user agent receives the response message of the session establishment request, it extracts all the Record-Routes in the response message and removes the last Record-Route, and then saves it as the route set to the dialog establishment response party.
- Step 1 User A sends an INVITE request, which carries sip: Conf-Factory, indicating that the conference is in progress.
- Step 2 After receiving the INVITE request, the user agent 1 adds a Record-Route header field to the INVITE request, and the content is the address of the user agent 1, and then forwards it.
- Step 3 After the back-to-back user agent receives the INVITE request, in order for the subsequent request message to be routed to the user A, the back-to-back user agent obtains the Record-Route list in the request message and saves it as the route set to the user A, and needs to be removed. All the Record-Routes in the received request, then add the Record-Route header field in the INVITE request, the content is the address of the back-to-back user agent, and then forward it.
- Step 4 After receiving the INVITE request, the user agent 2 adds a Record-Route header field to the address of the User Agent 2 (Record-Route: Proxy2) in the INVITE request, and then forwards it to the conference center.
- Record-Route Proxy2
- Step 5 After receiving the INVITE request, the conference center carries the Conf-ID and isfocus parameters in the Contact header field, and then carries the Record-Route to return a 200 OK response.
- Step 6 After receiving the 200 OK response, User Agent 2 forwards it to the back-to-back user agent.
- Step 7 After the back-to-back user agent receives the 200 OK response, the back-to-back user agent can obtain the Record-Route list in the 200 OK response message and remove the last URI (Uniform Resource Identifier) in the Record-Route list ( Because the last URI is the back-to-back user agent's own address, no need to save), then save the modified Record-Route list as a route set to the conference center; also need to remove all the Record-Route in the response message received, and then respond The Record-Route header field is added to the message, and the content is its own address.
- URI Uniform Resource Identifier
- step 3 the back-to-back user agent has obtained the route set to User A, and the back-to-back user agent removes all the Records in the received response message.
- the route add the Record-Route list of User A saved in Step 3 to the response message, and then add a Record-Route at the top of the Record-Route list, which is the address of the Back-to-Back User Agent (B2BUA), and then forward it to the user.
- Agent 1 the Back-to-Back User Agent
- Step 8 After receiving the 200 OK response, the user agent 1 forwards it to the user A, so that User A can obtain the Conf-ID and isfocus parameters carried in the Contact header field of the conference center, and perform subsequent operations of the conference.
- the above embodiments are not limited to conversations of a conference call, but can also be used for other forms of conversation, such as conversations between users or conversations between user agents.
- FIG. 3 is a schematic diagram of a back-to-back user agent according to a first embodiment of the present invention.
- the back-to-back user agent unit 10 includes: a receiving unit 2, a Record-Route processing unit 5, a storage unit 8 and a transmitting unit 9, the receiving unit 2 is configured to receive a message; and the Record-Route processing unit 5 is configured to remove the received message. All the Record-Route in the message, then add the Record-Route header field in the received message, the content is the back-to-back user agent unit's own address.
- the Record-Route processing unit 5 is further configured to obtain a Record-Route list of the request message as a route set of the requester of the request message; and obtain a Record-Route list of the response message, and remove the last URI in the list (because the last a URI is a back-to-back user agent's own address, without saving), as a route set of the responding message sender; the storage unit 8 is configured to save a Record-Route list acquired or processed by the Record-Route processing unit 5; 9 Used to send out messages (ie, forwarded) that have been processed by the Record-Route processing unit.
- FIG. 4 is a schematic diagram of a dialog flow according to a second embodiment of the present invention.
- This dialogue process is the dialogue process between two users.
- Step 01 User A sends an INVITE request and carries user A's capability information (contact: A) through the contact header field.
- Step 02 After receiving the INVITE request, the user agent 1 adds a Record-Route header field to the INVITE request, and the content is the address of the user agent 1 (proxy 1 ), and then forwards it.
- Step 03 After the back-to-back user agent receives the INVITE request, the subsequent request message can be routed to the user A, and the back-to-back user agent obtains the Record-Route list in the request message and saves it as the route set to the user A; All received in the request Record-Route, then add the Record-Route header field in the INVITE request, the address of the back-to-back user agent (B2BUA), and then forward it.
- B2BUA back-to-back user agent
- Step 04 After receiving the INVITE request, the user agent 2 adds a Record-Route header field to the INVITE request, and the content is the address of the user agent 2 (Proxy2), and then forwards it to the user.
- Step 05 After receiving the INVITE request, the user B knows the capability of the user A by carrying the capability information of the user A in the contact header field, and then returns a 200 OK response, and carries the capability information of the user B through the Contact header field (contact: B), and carry the request message in Rscord-Routs.
- Step 06 After receiving the 200 OK response, the user agent 2 forwards it to the back-to-back user agent according to the Record-Route therein.
- Step 07 After the back-to-back user agent receives the 200 OK response, the back-to-back user agent can obtain the Record-Route list in the 200 OK response message and remove the last URI in the Record-Route list (because the last URI is the back-to-back user agent) Your own address, no need to save), and then save the modified Record-Route list as a route set to User B; also need to remove all the Record-Route in the received response message, and then add a Record-Route header in the response message
- the domain, the content is its own address;
- the back-to-back user agent has obtained the route set to user A, and then the back-to-back user agent removes all the Record-Routes in the received response message, in the response message.
- Step 08 After receiving the 200 OK response, the user agent 1 forwards the response to the user A, so that the user A can obtain the capability information of the user B, and perform subsequent operations.
- Step 09 User A sends an ACK message, where Requst-URI is the address of user B, and Route is Proxy 1 and B2BUA.
- Step 010 After receiving the ACK message, the user agent 1 forwards the ACK message to the B2BUA.
- the Requst-URI is the address of the user B, and the route is B2BUA.
- Step 011 After the B2BUA receives the ACK message, the Route in the ACK message is the address of the back-to-back user agent, and the Route is deleted; the Request-URI of the ACK message is the address of the user B; The B2BUA needs to add the route set to user B in the forwarded ACK message, and then forward it to user B.
- the route is Proxy2.
- Step 012 After receiving the ACK message, the user agent 2 forwards the ACK message to the user B, where the Requst-URI is the address of the user B.
- Step 013 User B sends a Bye message, where Requst-URI is the address of user A.
- Step 014 After receiving the Bye message, the user agent 2 forwards the message to the B2BUA, where Requst-URI is the address of user A and Route is B2BUA.
- Step 015 After the B2BUA receives the Bye message, because the Route in the Bye message is the address of the back-to-back user agent, the route is deleted, because the Request-URI of the Bye message is the address of the user A; the B2BUA needs to be added to the forwarded Bye message. User A's route set, then forwarded to user A, and Route is Proxyl.
- Step 016 After receiving the Bye message, the user agent 1 forwards the message to User A, where Requst-URI is the address of User A.
- Step 017-020 User A sends the user to the user via user agent 1, B2BUA and user agent 2.
- the B2BUA can also send the request message in the dialog to the two ends of the dialog, such as rernvite, Bye, etc.
- the B2BUA can fill in the address of the B2BUA, or fill in the pair of the receiver.
- the contact address of the terminal for example, when the user sends a renvvite or Bye to the user B, the contact fills in the address of the user A, but since the rernvite message refreshes the remote target URI, it is recommended to fill in the contact information of the receiver at the opposite end when sending the renvite message. .
- the routing addresses of the back-to-back user agents are stored in the Record-Route header field instead of modifying the Contact header field, both the correct routing of subsequent requests and the end-to-end transmission of information in the Contact header field are ensured, so that two users are in the conversation.
- the capability information carried in the Contact header field can be used, and the user can learn the capability information of the peer end.
- the above method or device is not limited to transmission capability information, and may also be transmitted through the Contact header domain. Other information with the belt.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Telephonic Communication Services (AREA)
Abstract
L'invention concerne un procédé de transmission d'informations mis en oeuvre à l'aide d'un agent d'utilisateur dos à dos. Lorsque le message est reçu, le champ d'en-tête de contact d'origine du message est sauvegardé par l'ajout d'un champ d'en-tête de route d'enregistrement dont le contenu est l'adresse de l'agent d'utilisateur dos à dos du message transmis. La route correcte de la demande séquente peut être garantie et la transmission de bout en bout des informations du champ de l'en-tête de contact peut également être garantie. Un agent d'utilisateur dos à dos et un support lisible par ordinateur sont également décrits dans l'invention.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN 200610063765 CN101212418B (zh) | 2006-12-31 | 2006-12-31 | 背靠背用户代理及其传输信息的方法 |
CN200610063765.5 | 2006-12-31 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2008080334A1 true WO2008080334A1 (fr) | 2008-07-10 |
Family
ID=39588147
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2007/071236 WO2008080334A1 (fr) | 2006-12-31 | 2007-12-14 | Agent d'utilisateur dos à dos et procédé de transmission d'informations associé |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN101212418B (fr) |
WO (1) | WO2008080334A1 (fr) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2010025772A1 (fr) * | 2008-09-05 | 2010-03-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Transfert d'adresse de bout en bout |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102882906A (zh) * | 2011-07-14 | 2013-01-16 | 华为技术有限公司 | 受限应用协议中数据通信的方法和装置 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2873881A1 (fr) * | 2004-07-30 | 2006-02-03 | Groupe Ecoles Telecomm | Procede de fonctionnement d'un reseau operant sous le protocole sip et reseau mettant en oeuvre un tel procede |
CN1780293A (zh) * | 2004-11-25 | 2006-05-31 | 华为技术有限公司 | 在有状态会话初始协议服务器上实现过负荷控制的方法 |
CN1832473A (zh) * | 2005-08-19 | 2006-09-13 | 华为技术有限公司 | 一种在ims网络中处理会话消息的方法及装置 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7688804B2 (en) * | 2005-02-08 | 2010-03-30 | Aspect Software, Inc. | Method of providing fault tolerance in a SIP based contact handling environment |
CN100550813C (zh) * | 2005-05-27 | 2009-10-14 | 精益科技股份有限公司 | 内外网络间通讯的多媒体会议的系统与方法 |
CN100518186C (zh) * | 2005-10-10 | 2009-07-22 | 华为技术有限公司 | 提高sip压缩效率的系统及方法 |
CN1870639B (zh) * | 2005-11-25 | 2010-12-08 | 华为技术有限公司 | 初始会话协议消息编码能力的协商方法及装置 |
-
2006
- 2006-12-31 CN CN 200610063765 patent/CN101212418B/zh active Active
-
2007
- 2007-12-14 WO PCT/CN2007/071236 patent/WO2008080334A1/fr active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FR2873881A1 (fr) * | 2004-07-30 | 2006-02-03 | Groupe Ecoles Telecomm | Procede de fonctionnement d'un reseau operant sous le protocole sip et reseau mettant en oeuvre un tel procede |
CN1780293A (zh) * | 2004-11-25 | 2006-05-31 | 华为技术有限公司 | 在有状态会话初始协议服务器上实现过负荷控制的方法 |
CN1832473A (zh) * | 2005-08-19 | 2006-09-13 | 华为技术有限公司 | 一种在ims网络中处理会话消息的方法及装置 |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2010025772A1 (fr) * | 2008-09-05 | 2010-03-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Transfert d'adresse de bout en bout |
US8606932B2 (en) | 2008-09-05 | 2013-12-10 | Telefonaktiebolaget L M Ericsson (Publ) | End-to-end address transfer |
US9420018B2 (en) | 2008-09-05 | 2016-08-16 | Telefonaktiebolaget Lm Ericsson (Publ) | End-to-end address transfer |
Also Published As
Publication number | Publication date |
---|---|
CN101212418A (zh) | 2008-07-02 |
CN101212418B (zh) | 2010-05-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5363461B2 (ja) | グループ呼機能の問い合わせ | |
JP5043392B2 (ja) | Sip通信セッションをセットアップする方法、並びに、そのシステム及びコンピュータ・プログラム | |
US8296447B2 (en) | Method for copying session information, call control server for executing the same, and computer product | |
US7937463B2 (en) | Method and server for invoking application servers in a SIP network | |
US20060050648A1 (en) | Reducing storage requirement for route information | |
JP5247709B2 (ja) | 中間ノードが利用不可能な場合にsipメッセージを経路指定する方法 | |
US20130080648A1 (en) | Session initiation from application servers in an ip multimedia subsystem | |
WO2008089642A1 (fr) | Procédé, dispositif et système pour le transfert d'informations de terminal dans un sous-système multimédia | |
US9246955B2 (en) | Capability query handling in a communication network | |
CN100574474C (zh) | 一种通讯系统中建立通讯业务连接的方法 | |
JP2017510116A (ja) | 第1のユーザが第2のユーザのソーシャル・ネットワーク識別子およびそれらのソーシャル・ネットワークにおけるこの第2のユーザのそれぞれのステータスを自動的に検出できるようにする方法およびサーバ | |
JP5260746B2 (ja) | エンド・ツー・エンドのアドレス転送 | |
WO2007112640A1 (fr) | Procédé et appareil de remplacement de l'identification de session, serveur d'application et procédé de remplacement de session | |
WO2012013094A1 (fr) | Procédé et système d'établissement de session sur la base d'un identifiant de corrélation de dialogue | |
Baset et al. | The Session Initiation Protocol (SIP): An Evolutionary Study. | |
KR20050002335A (ko) | Sip 망의 호 처리 시스템 및 방법 | |
WO2008080334A1 (fr) | Agent d'utilisateur dos à dos et procédé de transmission d'informations associé | |
JP5608748B2 (ja) | 通信ネットワークにおける方法及び装置 | |
JP2006345231A (ja) | Sip−alg方法 | |
US20080137647A1 (en) | VoIP terminal and method for providing multi-call service | |
Ali et al. | Session initiation protocol | |
KR101344270B1 (ko) | 클라우드 환경을 위한 통신 장치 및 통신 장치 운영 방법 | |
JP4136798B2 (ja) | 音声ガイダンス機能付き中継装置 | |
KR20070061292A (ko) | 접속 설정 프로토콜을 사용하는 인터넷 전화 시스템에서의서비스 제공 방법 및 그 시스템 | |
KR100929113B1 (ko) | 자원 예약 프로토콜을 이용한 양방향 자원 예약 방법 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 07817374 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 07817374 Country of ref document: EP Kind code of ref document: A1 |