WO2006037276A1 - Procede d'intercommunication entre des reseaux possedant des versions differentes du protocole internet - Google Patents

Procede d'intercommunication entre des reseaux possedant des versions differentes du protocole internet Download PDF

Info

Publication number
WO2006037276A1
WO2006037276A1 PCT/CN2005/001640 CN2005001640W WO2006037276A1 WO 2006037276 A1 WO2006037276 A1 WO 2006037276A1 CN 2005001640 W CN2005001640 W CN 2005001640W WO 2006037276 A1 WO2006037276 A1 WO 2006037276A1
Authority
WO
WIPO (PCT)
Prior art keywords
version
message
called
network
state control
Prior art date
Application number
PCT/CN2005/001640
Other languages
English (en)
French (fr)
Inventor
Hui Li
Yajuan Wu
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.
Priority to EP05795754A priority Critical patent/EP1798918A4/en
Publication of WO2006037276A1 publication Critical patent/WO2006037276A1/zh
Priority to US11/703,709 priority patent/US7792116B2/en

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/1016—IP multimedia subsystem [IMS]
    • 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
    • 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/08—Protocols for interworking; Protocol conversion
    • 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/08—Protocols for interworking; Protocol conversion
    • H04L69/085—Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • 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 network interworking technologies, and in particular to interworking of different versions of Internet Protocol (IP) networks related to the Internet Protocol Multimedia Core Network subsystem.
  • IP Internet Protocol
  • the mobile communication system can meet the requirements of people to communicate anytime and anywhere, and has developed rapidly since its appearance.
  • 3G Third Generation
  • the bandwidth of mobile networks is greatly increased, and mobile communication will not only be limited to traditional voice communication, but also combine audio, video, pictures and text.
  • Multimedia services of the media type will gradually develop.
  • Mobile communication combined with data services such as presence, short message, web browsing, location information, push service (PUSH), file sharing, etc., can provide users with more business choices, such as instant messaging for message services.
  • Chat room multimedia short message, video business class entertainment, multimedia information, daily communication, e-commerce product catalog, search engine, shopping cart, order management, payment, game-like single player, group game, location service Class of tracing, wizards, alarms, personal assistant class address book, calendar, bookmark management, file storage, event reminders, email, can better meet the various needs of users.
  • IP Multimedia Subsystem IMS
  • R5, Release 5 IP Multimedia Subsystem
  • the IMS is composed of a Call Session Control Function (CSCF), a Media Gateway Control Function (MGCF, Media Gateway Control Function), a Media Resource Function (MRF), and a Home Subscriber Server (HSS). It is composed of functional entities. According to the different functions implemented by the CSCF, it can be divided into three logical entities: a service CSCF (S-CSCF, Serving CSCF), a proxy CSCF (P-CSCF, Proxy CSCF), and a query CSCF (I-CSCF, Interrogating CSCF), where
  • S-CSCF is a service switching center of the IMS, performs session control, maintains session state, manages user information, generates charging information, and the like;
  • the P-CSCF is an access point for the user terminal to access the IMS, completes user registration, and performs service.
  • I-CSCF implements route lookup, such as interworking between IMS domain and IMS domain, management of S-CSCF, and hidden network of external network and other IMS domains The topology and configuration, generating billing information, and more.
  • the MGCF implements the function of controlling the gateway to implement interworking between the IMS network and other networks.
  • the MRF provides media resources, such as receiving and playing audio, encoding and decoding information transmitted between user terminals, and a multimedia conference bridge.
  • the HSS is a user database that stores subscription data and configuration information of users in the IMS network.
  • the 3GPP defines, for example, a packet network defined by 3GPP2, a wireless local area network (WLAN), and a Next Generation Network (NGN). , achieves independence from the type of terminal used by the user and independence from the type of access network.
  • WLAN wireless local area network
  • NTN Next Generation Network
  • Session Initiation Protocol As a signaling control protocol for IP multimedia sessions.
  • SIP Session Initiation Protocol
  • the SIP protocol is an IP telephony signaling protocol proposed by the Internet Engineering Task Force (IETF).
  • IETF Internet Engineering Task Force
  • SIP is used to initiate a session. It controls the establishment and termination of multimedia sessions in which multiple participants participate, and dynamically adjusts and modifies session attributes such as session bandwidth requirements and the type of media being transmitted (voice). , video and text, etc.), media codec format, support for multicast and unicast, etc.
  • IPv4 Internet Protocol version 4
  • IPv6 Internet Protocol version 6
  • GGSN GPRS Gateway Support Node
  • GGSN IPv6 Dynamic Host Configuration Protocol
  • IPv6 scale commercialization has not reached the expected speed.
  • the lack of support for all IPv6-based products will delay the IPv6-based IMS application, and mobile operators will provide richer services for 3G users.
  • the multimedia service promotes the commercialization of Wideband Code Division Multiple Access (WCDMA) as soon as possible to attract more users and promote the development of 3G networks. It proposes to 3GPP and considers supporting IPv4 in the implementation of IMS. In order to meet the needs of early commercial use.
  • WCDMA Wideband Code Division Multiple Access
  • 3G is another mainstream standard code division multiple access 2000 (CDMA2000, Code Division) Multiple Access 2000)
  • MMD Multimedia Domain
  • 3GPP2 can be implemented based on IPv4 or IPv6, and there are many commercial SIP terminals based on IPv4 on the Internet, which will lead to 3GPP IPv6-based IMS and external based
  • IPv4 IPv6-based IMS and external based
  • 3GPP decided to add support for IPv4 in the initial IMS products, so that IMS supports both IPv6 and/or IPv4, so 3GPP needs to study how to introduce IPv4-based IMS and interworking and roaming based on IPv4 and IPv6 IMS. Interoperability between IMS and IPv4 SIP applications.
  • IP version type supported by UE IP version type supported by IMS network
  • IP version type supported by GPRS network IP version type supported by GPRS network
  • the network address translation and protocol translation (NAT-PT) and the application layer gateway (ALG) function are used in the place where the IP version interworking needs to be implemented.
  • the NAT-PT function is used to implement the network.
  • Address translation and protocol transformation, ALG function is used to implement application layer related address translation.
  • NAT-PT and ALG functions each time means the increase of the session delay and the quality of service, which means that the fewer times the IP address is converted, the less the impact on the quality of the session, and thus the less.
  • the pressure on the devices that implement NAT-PT and ALG functions reduces the number of network bottlenecks. Therefore, when IPv4 and IPv6 interworking, you need to consider when to introduce NAT-PT and ALG functions, which can enable end-to-end interworking. The number of conversions passed was the least.
  • the UE may only support the IPv4 protocol stack, or only support the IPv6 protocol stack, or both IPv4 and IPv6 dual stacks; likewise, other functional entities involved in the session establishment process, such as the peer UE, AS, CSCF, GGSN, etc. may only support IPv4, or It only supports IPv6, or both IPv4 and IPv6 dual stack.
  • IPv6 addresses Considering that the trend of IMS network development in the future is to use IPv6 addresses, and because the existing IPv4 address space is tight, many operators use private network IP addresses, which leads to private network IPv4 when interworking with other IP domain networks. The address is translated into a public IP address. Therefore, the prior art solution proposes to use an IPv6 address as much as possible. This can reduce the use of the ALG/NAT-PT function, thereby improving the service shield of the session.
  • FIG. 1 In the interworking of the IP version involving the service, the scheme proposed by the 3GPP to implement the instant messaging service between the IPv4-capable UE and the IPv6-capable UE is shown in FIG. 1 .
  • UE A supports IPv4.
  • When transmitting an instant message to UE B it does not involve negotiation of media components, and directly uses SIP signaling to carry related information.
  • UE B supports Pv6, and its home network is different from UE Ao in initiator one.
  • the home S-CSCF of UE A supports the IPv4 and IPv6 dual stacks, and translates the SIP messages transmitted using IPv4 directly into SIP messages transmitted using IPv6, and then continues to transmit to the receiving UE B.
  • the IMS-ALG refers to the ALG function entity in the IMS network
  • the TrGW is the Network Address Translator- Protocol Translator (NAT-PT) functional entity in the IMS network.
  • NAT-PT Network Address Translator- Protocol Translator
  • the session initiator UE A supports IPv6, and the home S-CSCF of the UE A supports the IPv4 and IPv6 dual stacks, and the home S-CSCF where the home S-CSCF is located is queried by the Domain Name System (DNS).
  • DNS Domain Name System
  • the mechanism determines that the receiver cannot communicate through IPv6, and replaces the information related to the IPv6 version in the SIP message by interacting with the IMS-ALG and the TrGW, and then continues the session negotiation process using IPv4 and the user side B to establish a media transmission path.
  • the existing interworking between different IP versions first determines the IP version supported by the UEs of the communication parties, that is, the initiator uses IPv4, the receiver uses IPv6, or the initiator uses IPv6, and the receiver uses IPv4. And then according to this premise, at the earliest can Where the ALG/NAT-PT function is used, that is, the mapping of the IP version related information is performed at the home S-CSCF of the initiator UE supporting the dual stack.
  • the prior art solution preferentially uses IPv6, that is, as long as the next functional entity can support IPv6, IPv4 to IPv6 conversion is performed.
  • the existing technical solutions are not comprehensive in considering the interworking of different IP versions in the IMS, and may require unnecessary version conversion when interworking with different IP versions, and increase the implementation of ALG/
  • the pressure of the NAT-PT device affects the quality of service for the session.
  • the main reason for this situation is: First, the existing technical solutions consider that the initiator uses IPv4, the receiver uses IPv6 or the initiator uses IPv6, and the receiver uses IPv4. This is not the case.
  • the early commercial IMS is likely due to The limitation of services and the poor availability of IPv6 devices only support IPv4.
  • the IMS network implemented later will support IPv4 and IPv6 silent stacks for forward compatibility and backward compatibility. When the technology is more stable, the market is more mature.
  • the IMS network may only implement IPv6, the three types of IMS networks need to be considered when the IP version is interoperable.
  • the initial use of the IMS network needs to be considered between a large number of existing v4 networks and services. Interworking, otherwise there may be a large number of conversions between IP versions that can be avoided.
  • the calling home network only supports IPv4
  • the called home network supports IPv4 and IPv6 dual stacks, and the calling UE and the called party
  • the IPv4 to IPv6 address information conversion may not be performed in the calling home network. However, according to the prior art solution, this conversion is still required.
  • the calling home S-CSCF cannot know the IP address type used by the called UE in advance, and can only know the address type of the IP domain where the called UE's home network is located.
  • the IP version used by the UE is known only by its home S-CSCF.
  • the IP version is executed at the earliest place where ALG/NAT-PT can be used. After the mapping of related information, it is likely that a new one needs to be executed after reaching the home network of the called UE.
  • ALG/NAT-PT conversion for example, when the calling home network only supports IPv4, and the called home network supports both IPv4 and IPv6 dual stacks, and both the calling UE and the called UE use IPv4 addresses, so that these The conversion can be done completely, it is not needed at all, resulting in unnecessary conversion between IP versions.
  • the object of the present invention is to provide a method for interworking between different versions of the internetwork protocol network, so that when the IMS is applied, the conversion between unnecessary IP versions is reduced, and the IP networks of different IP versions are improved. Interoperability.
  • the present invention provides a method for interworking between different versions of internetwork interconnection protocols, the method comprising the following steps:
  • the calling party's home call state control device determines whether the called home network supports the IP version of the calling party's internetworking protocol. If yes, the autonomously called message is forwarded directly to the called home call state control entity. Otherwise, After the IP version is converted, the message is sent to the called home call state control device;
  • the called party's home call state control device After the called party's home call state control device receives the message, it determines whether the called party supports the IP version of the message. If yes, the message is directly forwarded to the called party. Otherwise, after the IP version is converted, the message is translated. Send to the called party.
  • the step A further includes:
  • the calling home call state control device determines whether the IP address of the calling party is a private IP address, and if yes, step A02 is performed, otherwise, step A is directly executed;
  • the calling home call state control device uses the network address translation NAT function entity to convert the private IP address into a public network IP address, and then performs step A.
  • the step A01 and the step A02 further include: the calling home call state control device determines whether the called home network is the same as the calling home network, and if yes, the master The caller and the called party directly communicate; otherwise, go to step A02.
  • the calling home state control device of the calling party determines whether the called home network supports the IP version of the calling party, including: the calling home call state control device acquires the called party by querying the local configuration or the domain name service system DNS server. The IP version supported by the home network, and then determine whether the called home network supports the IP version of the calling party.
  • the method includes: the call state control device determines whether there is a media description in the message, and if yes, performing step g, otherwise, the call state control device directly performs IP on the message. Version conversion
  • the call state control device uses the application layer gateway device and the network address translation and protocol conversion device to perform IP version conversion on the message.
  • the step g further includes: the call state control device providing the next address for subsequent message routing to the application layer gateway device.
  • the application layer gateway device communicates with the network address translation and protocol conversion device using the session initiation protocol, or the H.248 protocol, or the media and body gateway control MeGaCo protocol.
  • the message from the calling party in step A is a SIP message.
  • the call state control device is a call state control function entity.
  • step B it is determined whether the called party supports the IP version of the message, including: the called home call state control device obtains the IP version supported by the called party by querying the IP version supported by the called party stored locally, and then determines whether the called party is called. Support for the IP version of the message.
  • the invention judges the IP address type supported by the calling party and the called party or the IP version supported by the home network at the call state control device, and only uses the ALG/NAT-PT function when the Chinese version is inconsistent, otherwise
  • the last call state control device placed in the end-to-end process that is, the called call state control device uses ALG/NAT-PT or just performs mapping of the IP version, and can be found by comparing with the existing scheme, the present invention Technical side
  • the difference between the present invention and the prior art solution is that the present invention only converts or uses ALG/NAT-PT if the IP versions of the node and the next hop node are inconsistent and communication cannot be continued without IP version conversion.
  • the ALG/NAT-PT transformation is placed on the called side as much as possible, which reduces unnecessary conversion and ALG/NAT-PT processing.
  • the IP version of the next hop node is firstly queried with the local node. If yes, the information is directly sent. Otherwise, the information is sent after the IP version is converted.
  • the consistency of the IP version can be queried according to local configuration information or a DNS server.
  • the difference in the technical solution brings about a more obvious beneficial effect.
  • the solution of the present invention is transmitted as much as possible according to the IP version of the calling party, the conversion is performed only when the communication cannot be continued without IP version conversion. Therefore, many unnecessary IP version conversions can be avoided, and the number of times of ALG/NAT-PT function in the session can be minimized, thereby reducing the delay of session transmission, improving the quality of service, and enabling IP networks of different IP versions. Interoperability is better.
  • the number of uses of the ALG NAT-PT function can be greatly reduced, the burden on the ALG/NAT-PT device in the system is reduced, and the performance of the system is improved.
  • FIG. 1 shows a scheme proposed by the 3GPP for implementing an instant messaging service between an IPv4-capable UE and an IPv6-capable UE;
  • FIG. 2 shows a process in an existing interworking scheme when a UE in an IMS network initiates a session
  • 3 illustrates a flow of IP network interworking of different IP versions with a media negotiation session establishment process in accordance with a preferred embodiment of the present invention
  • 4 illustrates a message delivery process between functional entities in an end-to-end setup process with media negotiation sessions in accordance with a preferred embodiment of the present invention
  • FIG. 5 is a schematic diagram of message delivery in a method for implementing an instant messaging service between an IPv4-capable UE and an IPv6-capable UE according to a preferred embodiment of the present invention. Mode for carrying out the invention
  • the basic principle of implementing the present invention is: In order to reduce the conversion between unnecessary IP versions, the solution of the present invention completes the IP version conversion as much as possible on the called side, unless the functional entity of the calling side processing session does not perform the IP version. The transformation cannot continue the subsequent communication, otherwise the IP version conversion will not be performed. In this way, the unnecessary IP version conversion can be reduced as much as possible, and the interworking between different IP versions of the IP network can be improved, and the IP network interworking schemes of different IP versions can be optimized and the interworking effect is better.
  • the solution of the present invention considers that the IMS functional entities located in the same IMS network, that is, the IP versions supported by the P-CSCF, the I-CSCF, and the S-CSCF, are considered from the perspective of convenient operation of the IMS network operator. The same is true. Otherwise, the IMS operator must consider various interworking scenarios that may exist between different functional entities in the IMS network, which increases the complexity of network planning.
  • the flow of interworking between different IP versions of the IP network with the media negotiation session establishment process is as shown in FIG. 3.
  • Step 100 The calling party initiates a call.
  • the calling party can initiate a call by using a SIP message.
  • Step 120 The calling home S-CSCF determines whether the called home network is the same as the calling home network. If yes, step 170 is performed; otherwise, step 130 is performed. In this step, if the called home network is the same as the calling home network, the calling party and the called party are in the same private network at the same time, and the IP version is the same, and the private IP address does not need to be mapped to the public network IP. Address, no need to convert IP version.
  • Step 130 The home of the calling party
  • the S-CSCF uses the NAT function entity to map the private IP address of the calling party to the public network IP address, that is, converts the private IP address into a public network IP address, and then performs step 140.
  • the mapping method of the private IP address to the public network IP address is well known to those skilled in the art, and is not described here.
  • Step 140 The calling home S-CSCF determines whether the called home network supports the IP version of the calling party. If yes, step 160 is performed; otherwise, step 150 is performed.
  • the calling home S-CSCF can obtain the IP version of the called home network by means of query or configuration. For example, when the calling home S-CSCF obtains the called home network domain name, it can send a query request to the DNS according to the current IP version used by itself. It should be noted that only the called UE is located in the query.
  • the address of the I-CSCF of the network external interface but based on the above considerations, the address type of the I-CSCF can be considered to represent the IP address type of the IMS network in which it resides.
  • the calling home S-CSCF can determine whether it can directly communicate with the peer without ALG/NAT-PT conversion.
  • the calling home S-CSCF currently receives the IPv4 message, and the calling home S-CSCF first queries the DNS server for the called home network according to the called home network domain name. Whether there is a corresponding IPv4 address. If the DNS server returns an IPv4 type address, it indicates that the called home network supports IPv4 or supports IPv4 and IPv6 dual stack. Otherwise, the DNS server will only return the IPv6 address corresponding to the called home network.
  • the called address or the home network domain name and the IP version information supported by the home network can be directly configured in the S-CSCF or the I-CSCF, so that Determine whether it can directly communicate with the I-CSCF of the external interface of the home network where the called party is located.
  • Step 150 The calling party's home S-CSCF uses the ALG/NAT-PT to perform the conversion of the IP version information, and the called home S-CSCF/I-CSCF is sent to, and then step 180 is performed.
  • the calling home S-CSCF forwards the SIP message to the ALG function entity of the calling home network to perform IP address version information conversion of the application layer, and the ALG controls the NAT-PT function entity to execute the user. Face IP address version information conversion.
  • the ALG functional entity and the NAT-PT functional entity can communicate using the SIP protocol, or the H.248 protocol, or the Media Gateway Control (MeGaCo, Media Gataway Control) protocol. It should be noted that when the calling S-CSCF forwards the message to the ALG functional entity, it also provides the next hop address to the ALG functional entity for routing of subsequent messages.
  • Step 160 The calling home S-CSCF sends a message directly to the called home S-CSCF/I-CSCF, and then proceeds to step 180.
  • the called home network supports the IP version of the calling party, it is not necessary to perform the IP version conversion or directly communicate. Therefore, based on the principle that the conversion is performed as far as possible on the called side, the calling party's attribution S- The CSCF sends the message directly to the called home S-CSCF/I-CSCF.
  • Step 170 The attribution of the calling party The S-CSCF ends the entire process without directly performing IP version conversion. In this step, since the calling and called home networks are the same, the communication can be directly performed without performing IP version conversion.
  • the related processing method is completely the same as the prior art, and will not be described in detail herein.
  • Step 180 After the called home S-CSCF receives the call initiated by the called party, it determines whether the called party supports the IP version of the calling party. If yes, step 210 is performed; otherwise, step 190 is performed.
  • the IP version supported by the called party is stored locally and can be directly queried.
  • Step 190 The called home S-CSCF sends a message to the ALG functional entity to perform application layer IP version conversion.
  • the ALG function entity in the step is an ALG function entity in the called home network, and the called home S-CSCF provides the next hop address to the ALG function entity when forwarding the message to the ALG function entity. Routing for subsequent messages.
  • Step 200 The ALG function entity controls the NAT-PT function entity to perform user plane IP version conversion.
  • the ALG functional entity and the NAT-PT functional entity can communicate using the SIP protocol, or the H.248 protocol, or the MeGaCo protocol.
  • Step 210 Forward the message to the P-CSCF corresponding to the called party.
  • the IP version supported by the called P-CSCF is the same as the IP version supported by the called party.
  • Step 220 The called P-CSCF sends a message to the called party.
  • the IP version of the message is already the IP version supported by the called party.
  • UE A initiates an IMS session request to UE B, which uses IPv4. Transmitted
  • the P-CSCF A corresponding to UE A forwards the session request message to the S-CSCF A/I-CSCF A of the home network of UE A;
  • the S-CSCF A/I-CSCF A determines that the home network of UE B can support the IPv4 version used by the current S-CSCF A according to the query or local configuration to the DNS server, and therefore decides to continue to the S- of the home network of UE B.
  • the CSCF B/I-CSCF B forwards the session request message; then, the S-CSCF B/I-CSCF B compares the saved IP address of the UE B with the type of the IP address used by the received request message, and finds that the inconsistency must be If the ALG/NAT-PT function is used for the conversion, the message is forwarded to the ALG functional entity, and the ALG functional entity is provided with the address of the P-CSCF B corresponding to the UE B;
  • the ALG functional entity performs the conversion of the IP address version related information from IPv4 to IPv6, because it involves modification of the user plane, and therefore, uses the extended SIP protocol, or the H.248 protocol, or the MeGaCo protocol and the NAT-PT functional entity.
  • the ALG function entity sends a newly constructed session request message to the P-CSCF B of the network where the UE B is currently located, the message is transmitted using IPv6, and the media description has been modified;
  • the P-CSCF B forwards the session request message to the UE B;
  • the subsequent signaling interaction will be performed between the UE A, the S-CSCF B/I-CSCF B, the ALG and the UE B, that is, the session signaling path established in FIG. 4; the subsequent media interaction will be in the UE A,
  • the NAT-PT functional entity is implemented between the UE and the UE B, that is, the media path established in FIG.
  • an IP version of the service is interworking, no media negotiation is required.
  • the instant message is that only the SIP signaling has no media negotiation process.
  • the ALG function entity is not required to perform IP address mapping. deal with.
  • the IP network interworking principle of different IP versions is the same as the above procedure.
  • the S-CSCF can determine whether there is a media description in the received message. If yes, the S-CSCF uses the ALG device and the NAT-PT. The device performs IP version conversion on the message; otherwise, because the message is short, it is not The media stream is required. The mapping of the IP version to another IP version is performed by the called home S-CSCF.
  • the ALG/NAT-PT function is not required, and the S-CSCF can directly convert the IP version of the message.
  • the IP version of the next hop can also be obtained by querying the local settings or the DNS server.
  • FIG. 5 A schematic diagram of message delivery in a method for implementing an instant messaging service between an IPv4-capable UE and an IPv6-capable UE according to a preferred embodiment of the present invention is shown in FIG. 5.
  • the UE A transmits the instant message to the UE B, it does not involve the negotiation of the media component, and directly uses the SIP signaling to carry the related information.
  • the home network of the UE B is different from the home network of the UE A.
  • the home S-CSCF of UE B supports IPv4 and IPv6 dual stacks, and is responsible for directly converting SIP messages transmitted using IPv4 into SIP messages transmitted using IPv6, and then continuing to transmit to the receiving UE B.
  • the present invention judges the IP address type supported by the calling party and the called party or the IP version supported by the home network at the S-CSCF, and only uses the ALG if the versions of the two parties are inconsistent.
  • /NAT-PT function otherwise it is placed in the last S-CSCF of the end-to-end process, that is, the called S-CSCF uses ALG/NAT-PT or just performs mapping of the IP version, so that the pair can be minimized.
  • the number of times the ALG/NAT-PT function is used; in addition, this method treats IPv4 and IPv6 equally.
  • the S-CSCF/I-CSCF in the figure is only the name of the logical entity corresponding to the call state control function when it is applied in the IMS network.
  • S-CSCF/I-CSCF Corresponding to the state proxy server in the SIP network responsible for processing the UE session request, the P-CSCF corresponds to the proxy server in the session path, and its function is the same.
  • the application network is different, so the method can also be applied to a general SIP network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Telephonic Communication Services (AREA)

Description

不同版本的网间互联协议网络互通的方法 技术领域
本发明涉及网络互通技术， 特别是指与网际协议多媒体核心网子系 统有关的不同版本的网际协议（IP, Internet Protocol ) 网络的互通。 发明背景
移动通信系统能够满足人们随时随地进行通信的要求， 从它出现后 就得到了迅速的发展。 随着第三代移动通信（3G, The Third Generation ) 技术的提出和进一步发展， 移动网络的带宽大大增加， 移动通信将不仅 仅局限于传统的语音通信， 结合音频、 视频、 图片和文本等多种媒体类 型的多媒体业务将逐渐开展起来。 移动通信与呈现业务（presence )、 短 消息、 网页浏览、 定位信息、 推送业务（PUSH )、 文件共享等数据业务 相结合， 可以为用户提供更多的业务选择， 例如消息业务类的即时消息 和聊天室、 多媒体短消息， 视频业务类的娱乐、 多媒体 息、 日常交流， 电子商务类的产品目录、 搜索引擎、 购物车、 订单管理、 支付， 游戏类 的单人游戏、 群組游戏， 定位业务类的寻人、 向导、 报警， 个人助理类 的地址本、 日程表、 书签管理、 文件存储、 事件提醒、 电子邮件， 能够 更好的满足用户的多种需求。
考虑到 IP 网絡的应用越来越广泛， 第三代合作伙伴项目 （3GPP, 3rd Generation Partnership Project ) 以及第三代合作伙伴项目 2 ( 3GPP2, 3rd Generation Partnership Project 2 )等标准组织都制定了将移动网络向 全分组、 全 IP方向演进的标准， 提出了基于 IP的多媒体子系统架构， 目的是在移动网络中使用一种标准化的开放结构来实现多种多样的多 媒体应用， 为用户提供更多的选择和更丰富的感受。 其中， 3GPP在版本 5 ( R5 , Release 5 ) 阶段引入了 IP多媒体子系 统（IMS, IP Multimedia Subsystem )域， IMS域是叠加在分组域网络之 上的。 IMS由呼叫状态控制功能（CSCF, Call Session Control Function ), 媒体网关控制功能（ MGCF, Media Gateway Control Function )、 媒体资 源功能 ( MRF, Multimedia Resource Function )和归属签约用户服务器 ( HSS, Home Subscriber Server )等功能实体组成。 根据 CSCF实现的 不同功能， 又可分为服务 CSCF ( S-CSCF, Serving CSCF )、 代理 CSCF ( P-CSCF, Proxy CSCF )和查询 CSCF ( I-CSCF, Interrogating CSCF ) 三个逻辑实体， 其中， S-CSCF是 IMS的业务交换中心， 执行会话控制、 维持会话状态、 管理用户信息、 生成计费信息， 等等； P-CSCF 是用户 终端接入 IMS的接入点， 完成用户注册、 进行服务质量（QoS )控制和 安全管理， 等等； I-CSCF实现路由查找， 如 IMS域内及 IMS域之间的 互通， 对 S-CSCF的分配进^ ^管理， 对外部网絡和其他 IMS域隐藏网络 的拓朴结构和配置， 生成计费信息，等等。 MGCF实现控制网关的功能， 实现 IMS网络与其他网络之间的互通； MRF提供媒体资源， 如收放音、 对用户终端之间传输的信息进行编解码和多媒体会议桥等。 HSS是用户 数据库， 存储有 IMS网络中用户的签约数据和配置信息等。
由于 IMS网络的结构做到了与底层承载网絡无关， 因此 3GPP定义 絡上，比如 3 GPP2定义的分组网络、无线局域网（ WLAN , Wireless Local Area Network )、 以及下一代网络 ( NGN , Next Generation Network )等， 实现了与用户使用终端类型的无关性以及与接入网络类型的无关性。 这 里不限制 IMS只应用在 3GPP相关的网络和应用上， 其他类型的接入网 络和承载网络的业务和应用也可以用 IMS架构来实现。
在 IMS中， 使用会话初始化协议（ SIP, Session Initiation Protocol ) 作为 IP多媒体会话的信令控制协议。 其中， SIP协议是由互联网工程任 务组（ IETF, Internet Engineering Task Force )提出的 IP电话信令协议。 正如其名字所隐含的， SIP 用于发起会话， 它能控制多个参与者参加的 多媒体会话的建立和终结， 并能动态调整和修改会话属性， 如会话带宽 要求、 传输的媒体类型 （语音、 视频和文本等）、 媒体的编解码格式、 对组播和单播的支持等。
3GPP在制定 IMS相关规范时， 考虑到网间互联协议第 4版（ IPv4 , Internet Protocol version 4 )存在地址空间即将耗尽、 路由表爆炸等问题， 而 IMS的广泛应用是需要大量可用的 IP地址的， 在实现多种媒体类型 融合的下一代网络中对网络的安全、 质量和移动性都提出了更高的要 求， 因此， 3GPP明确规定实现 IP多媒体业务时， 用户终端必须支持使 用网间互联协议第 6版（ IPv6, Internet Protocol version 6 )地址进行通 讯。对移动网絡功能实体而言， IMS的所有功能实体，包括用户设备（ UE , User Equipment ), CSCF、 MGCF、 MRP和应用服务器（ AS, Application Server )都必须支持 IPv6; 由于通用分组无线业务网关支持节点（ GGSN, GPRS Gateway Support Node ) 与 IMS有接口， 也必须支持 IPv6, 为支 持动态地址解析， GGSN还需支持 IPv6的动态主机配置协议（DHCP, Dynamic Host Configuration Protocol )。
但是随着市场的变化和技术的发展， IPv6规模商用目前没有达到原 来预计的速度，同时缺乏所有基于 IPv6产品的支持将使基于 IPv6的 IMS 应用延迟， 移动运营商为了通过给 3G用户提供更丰富的多媒体业务， 促进宽带码分多址（ WCDMA, Wideband Code Division Multiple Access ) IMS 的尽快商用， 来吸引更多的用户， 促进 3G网络的发展， 向 3GPP 提出建议，考虑在 IMS的实现中支持 IPv4,以此来满足早期商用的需求。 同时， 3G另一种主流制式码分多址 2000 ( CDMA2000, Code Division Multiple Access 2000 ) 的标准化组织 3GPP2制定的多媒体域（MMD, Multimedia Domain )可基于 IPv4或 IPv6实现， 并且 Internet上已有不 少基于 IPv4的商用 SIP终端， 这将导致 3GPP基于 IPv6的 IMS与外部 基于 IPv4网络的互通出现问题。 因此， 3GPP决定在初期的 IMS产品中 增加对 IPv4的支持， 使得 IMS同时支持 IPv6和 /或 IPv4, 这样 3GPP 就需要研究如何引入基于 IPv4的 IMS, 以及基于 IPv4和 IPv6 IMS之间 的互通和漫游、 IMS和 IPv4 SIP应用之间的互通等问题。
3GPP技术艮告（TR, Technical Report ) 23.981对各种可能存在的 互通问题进行了分析， 包括： UE支持的 IP版本类型， IMS网络支持的 IP版本类型， GPRS网络支持的 IP版本类型， 考虑漫游的情况， 端到端 的互通场景， 涉及业务的 IP版本互通等。 在需要实现 IP版本互通的地 方使用网絡地址转换和协议转换（NAT-PT, Network Address Translation and Protocol Translation ) 和应用层网关 ( ALG , Application Layer Gateway )功能，其中， NAT-PT功能用于实现网络地址变换和协议变换， ALG功能用于实现应用层相关的地址变换。
由于每次使用 NAT-PT和 ALG功能就意味着会话时延的增力口，降低 了服务质量，这就表明转换 IP地址的次数越少，对会话的服务质量影响 就越小，进而减轻了对实现 NAT-PT和 ALG功能的设备的压力，减少了 网络瓶颈的数量， 因此在 IPv4和 IPv6互通时就需要考虑在什么时候引 入 NAT-PT和 ALG功能， 可以使得实现端到端的互通过程中经过的转 换次数最少。
现有的解决 IMS中 IPv4和 IPv6互通的方案是由 3GPP提出的。 在 现有技术方案中， UE可以只支持 IPv4协议栈，或者只支持 IPv6协议栈 , 或者同时支持 IPv4和 IPv6双栈； 同样， 在会话建立过程中涉及到的其 他功能实体， 如对端 UE、 AS、 CSCF、 GGSN等都可能只支持 IPv4, 或 者只支持 IPv6, 或者同时支持 IPv4和 IPv6双栈。
考虑到今后 IMS网络发展的趋势是都使用 IPv6地址， 同时因为现 有 IPv4地址空间的紧张， 很多运营商使用私网 IP地址， 导致和其他 IP 域网络进^ "互通时， 必须将私网 IPv4地址转化为公网 IP地址， 因此， 现有技术方案建议尽量使用 IPv6地址，这样可以减少使用 ALG/NAT-PT 功能的情况， 从而提高会话的服务盾量。
在涉及业务的 IP版本互通中， 3GPP建议的实现支持 IPv4的 UE和 支持 IPv6的 UE之间进行即时消息业务的方案如图 1所示。其中， UE A 支持 IPv4, 在向 UE B传送即时消息时， 不涉及到媒体成分的协商， 直 接使用 SIP信令携带相关的信息； UE B支持 Pv6, 其归属网络不同于 UE Ao 在发起方一侧， UE A的归属 S-CSCF支持 IPv4和 IPv6双栈， 将 使用 IPv4传送的 SIP消息直接转化为使用 IPv6传送的 SIP消息， 然后 继续传送给接收方 UE B。
当 IMS网絡中的 UE发起会话的时候， 现有的一种互通方案中的处 理过程如图 2所示。 其中， IMS-ALG指的是 IMS网络中的 ALG功能实 体， TrGW是 IMS网络中的网络地址转换-协议转换（ NAT-PT, Network Address Translator - Protocol Translator )功能实体。 才艮据图 2的描述， 会 话发起方 UE A支持 IPv6 , UE A的归属 S-CSCF支持 IPv4和 IPv6双栈， 其所在的归属 S-CSCF通过域名服务系统（DNS , Domain Name System ) 查询等机制确定接收方无法通过 IPv6进行通信， 则通过与 IMS-ALG以 及 TrGW的交互，替换 SIP消息中 IPv6版本相关的信息，然后使用 IPv4 和用户侧 B继续会话协商过程， 建立媒体传输路径。
通过以上描述可以看出，现有的不同 IP版本之间互通的方案先确定 了通信双方 UE支持的 IP版本， 即发起方使用 IPv4、 接收方使用 IPv6 , 或发起方使用 IPv6、 接收方使用 IPv4, 然后根据这个前提， 在最早可以 使用 ALG/NAT-PT功能的地方，即支持双栈的发起方 UE的归属 S-CSCF 处， 执行 IP版本相关信息的映射。 熟悉本领域的技术人员可以理解， 现 有的技术方案优先使用 IPv6, 即只要下一个功能实体能够支持 IPv6, 就 会执行 IPv4到 IPv6的转换。
在实际应用中， 上述方案存在以下问题： 现有的技术方案对 IMS中 不同 IP版本互通的情况考虑不全面， 而且在不同 IP版本互通时可能会 完成不必要的版本转换， 增加了实现 ALG/NAT-PT的设备的压力， 影响 了会话的服务质量。 造成这种情况的主要原因在于， 首先， 现有的技术 方案认为发起方使用 IPv4、 接收方使用 IPv6或发起方使用 IPv6、 接收 方使用 IPv4, 而实际情况并非如此，早期商用的 IMS很可能由于业务的 限制以及 IPv6设备的可用性差而只支持 IPv4, 稍后实现的 IMS网络则 出于前向兼容和后向兼容的考虑， 会同时支持 IPv4和 IPv6默栈， 当技 术更稳定， 市场更成熟的时候， IMS网络可能只实现 IPv6， 因此这三种 类型的 IMS网絡在 IP版本互通的时候都需要考虑， 尤其是 IMS网络使 用的初期，还需要考虑和大量现有] v4网络和业务之间的互通， 否则可 能会存在大量的本能够避免的 IP版本之间的转换，比如当主叫的归属网 络只支持 IPv4, 被叫的归属网络支持 IPv4和 IPv6双栈， 而且主叫 UE 和被叫 UE均使用 IPv4地址时，主叫的归属网络中完全可以不执行 IPv4 到 IPv6的地址信息转换， 但^^据现有技术方案仍需要进行这个转换。
其次， 实际实现的时候， 主叫的归属 S-CSCF是无法事先知道被叫 UE使用的 IP地址类型的，只能知道被叫 UE的归属网络所在 IP域的地 址类型， 当被叫 UE漫游到另一个网络中、 ·由漫游网络分配 IP地址时， 该 UE使用的 IP版本只有其归属 S-CSCF知道， 按照现有技术的处理过 程， 在最早可以使用 ALG/NAT-PT的地方执行 IP版本相关信息的映射 之后， 很可能在到达被叫 UE 的归属网络之后还需要执行新的 ALG/NAT-PT变换， 例如， 当主叫的归属网絡只支持 IPv4, 而被叫的归 属网絡支持 IPv4和 IPv6双栈， 而且主叫 UE和被叫 UE都是使用 IPv4 地址的， 这样， 这些转换完全可以不执行， 根本是不需要的， 造成了 IP 版本之间不必要的转换。 发明内容
有鉴于此， 本发明的目的在于提供一种不同版本的网间互联协议网 络互通的方法， 使得应用 IMS时， 减少了不必要的 IP版本之间的转换， 完善不同 IP版本的 IP网络之间的互通。
为实现上述目的， 本发明提供了一种不同版本的网间互联协议网络 互通的方法， 该方法包含以下步骤：
A、 主叫的归属呼叫状态控制设备判断被叫的归属网络是否支持主 叫的网间互联协议 IP版本， 如果是， 则将来自主叫的消息直接转发给被 叫的归属呼叫状态控制实体， 否则， 对该消息进行 IP版本转换后， 发送 给被叫的归属呼叫状态控制设备；
B、 被叫的归属呼叫状态控制设备收到消息后， 判断被叫是否支持 该消息的 IP版本， 如果是， 则将该消息直接转发给被叫， 否则， 对该消 息进行 IP版本转换后， 发送给被叫。
所述步骤 A之前进一步包括：
A01、 主叫的归属呼叫状态控制设备判断主叫的 IP地址是否为私有 IP地址， 如果是， 则执行步骤 A02, 否则， 直接执行步骤 A;
A02、 主叫的归属呼叫状态控制设备使用网络地址转换 NAT功能实 体将私有 IP地址转换为公网 IP地址， 然后执行步骤 A。
所述步骤 A01和步骤 A02之间进一步包括：主叫的归属呼叫状态控 制设备判断被叫的归属网络与主叫的归属网络是否相同， 如果是， 则主 叫和被叫直接进行通信； 否则， 执行步骤 A02。
步骤 A中所述主叫的归属呼叫状态控制设备判断被叫的归属网络是 否支持主叫的 IP版本， 包括： 主叫的归属呼叫状态控制设备通过查询本 地配置或域名服务系统 DNS服务器获取被叫的归属网络支持的 IP版本， 然后判断被叫的归属网络是否支持主叫的 IP版本。
步骤 A或步驟 B中所述对消息进行 IP版本转换， 包括： 呼叫状态 控制设备判断所述消息中是否有媒体描述， 如果是， 则执行步骤 g, 否 则， 呼叫状态控制设备直接对消息进行 IP版本转换；
g、呼叫状态控制设备使用应用层网关设备以及网络地址转换和协议 转换设备对消息进行 IP版本转换。
所述步驟 g进一步包括： 呼叫状态控制设备向应用层网关设备提供 用于后续消息路由的下一条地址。
应用层网关设备与网络地址转换和协议转换设备之间使用会话初始 化协议、 或 H.248协议、 或媒、体网关控制 MeGaCo协议进行通信。
步驟 A中所述来自主叫的消息为 SIP消息。
在多媒体子系统中， 所述呼叫状态控制设备为呼叫状态控制功能实 体。
步骤 B中所述判断被叫是否支持消息的 IP版本， 包括：被叫的归属 呼叫状态控制设备通过查询存储于本地的被叫支持的 IP 版本获取被叫 支持的 IP版本， 然后判断被叫是否支持消息的 IP版本。
本发明通过在呼叫状态控制设备处对主叫和被叫支持的 IP 地址类 型或者归属网络支持的 IP版本进行判断，只有在汉方版本不一致的情况 下才使用 ALG/NAT-PT功能， 否则就放在端到端流程的最后一个呼叫状 态控制设备， 即被叫呼叫状态控制设备处使用 ALG/NAT-PT或者仅仅是 执行 IP版本的映射，通过与现有方案的比较可以发现，本发明的技术方 案与现有技术方案的区别在于， 本发明只有在本节点和下一跳节点的 IP 版本不一致、如果不进行 IP版本转换就无法继续通信的情况下， 才进行 转换或使用 ALG/NAT-PT功能，也就是说将 ALG/NAT-PT变换尽可能的 放在被叫侧完成， 减少了不必要转换和 ALG/NAT-PT处理。 具体来说， 先查询下一跳节点的 IP版本和本节点是否一致， 如果是则直接发送信 息，否则经过 IP版本转换以后再发送信息。可以根据本地的配置信息或 DNS服务器来对 IP版本的一致性进行查询。
这种技术方案上的区别， 带来了较为明显的有益效果， 即首先， 由 于本发明方案尽量按照主叫的 IP版本进行传送， 只有在不进行 IP版本 转换就无法继续通信时才进行转换，因此可以避免许多不必要的 IP版本 转换， 最大程度地降低了会话中 ALG/NAT-PT功能的使用次数， 因此能 够减少会话传输的时延， 提高了服务质量， 使不同 IP版本的 IP网络的 互通效果更好。其次，由于 ALG NAT-PT功能的使用次数可以大大减少 , 因此减轻了系统中 ALG/NAT-PT设备的负担，提高了系统的性能。再次， 由于本发明方案不同于现有技术中优先考虑采用 IPv6传输的方案， 对 IPv4和 IPv6 同等对待， 因此兼容性能更好， 可以应用在网络商用的各 个阶段， 能够最大限度的保护运营商的投资。 附图简要说明
图 1示出了 3GPP建议的实现支持 IPv4的 UE和支持 IPv6的 UE之 间进行即时消息业务的方案；
图 2示出了当 IMS网络中的 UE发起会话时， 现有的一种互通方案 中的处理过程；
图 3示出了根据本发明的一个较佳实施例的带有媒体协商的会话建 立过程的不同 IP版本的 IP网络互通的流程； 图 4示出了根据本发明的一个较佳实施例的端到端的带有媒体协商 的会话的建立流程中各个功能实体之间的消息传递流程；
图 5 示出了根据本发明的一个较佳实施例的实现一个支持 IPv4的 UE与支持 IPv6的 UE之间进行即时消息业务的方法中消息的传递示意 图。 实施本发明的方式
为使本发明的目的、 技术方案和优点更加清楚， 下面结合附图对本 发明作进一步的详细描述。
实现本发明的基本原理是： 为了减少不必要的 IP版本之间的转换， 本发明方案将 IP版本变换尽可能的放在被叫侧完成，除非主叫侧处理会 话的功能实体不进行 IP版本变换就无法继续后续的通信，否则就不执行 IP版本变换。 这样能够尽可能的减少不必要的 IP版本变换， 完善了不 同 IP版本的 IP网络之间的互通， 使不同 IP版本的 IP网络互通的方案 更加优化， 互通的效果更好。
首先需要说明的是， 本发明方案从 IMS网络运营商运营方便的角度 考虑， 认为位于同一个 IMS网絡中的各个 IMS功能实体， 即 P-CSCF、 I-CSCF和 S-CSCF所支持的 IP版本是相同的， 否则， IMS运营商自己 还要考虑 IMS网络内不同功能实体之间可能存在的多种互通场景，无端 增加了网络规划的复杂度。
根据本发明的一个较佳实施例的带有媒体协商的会话建立过程的不 同 IP版本的 IP网络互通的流程如图 3所示。
步骤 100: 主叫发起呼叫。 其中， 主叫可以采用 SIP消息发起呼叫。 步骤 110: 主叫的归属 S-CSCF收到主叫发起的呼叫后，判断主叫的 IP地址是否是私有 IP地址， 如果是， 则执行步驟 120; 否则， 执行步骤 140。 由于 IPv4地址的紧张， 现有的 IPv4网络上很多站点都采用了私网 IPv4地址， 当需要接入公网时， 在私网和公网的边缘进行私网地址与公 网地址之间的映射。
步骤 120:主叫的归属 S-CSCF判断被叫的归属网络与主叫的归属网 络是否相同， 如果是， 则执行步骤 170, 否则， 执行步骤 130。 在该步 骤中， 如果被叫的归属网络与主叫的归属网络相同， 则说明主叫和被叫 同时处于一个相同的私网中， IP版本也相同， 无需将私有 IP地址映射 到公网 IP地址， 更无需进行 IP版本的转换。
步骤 130: 主叫的归属 S-CSCF使用 NAT功能实体将主叫的私有 IP 地址映射到公网 IP地址， 即将私有 IP地址转换为公网 IP地址， 然后执 行步驟 140。 其中， 私有 IP地址到公网 IP地址的映射方法为本领域技 术人员所公知， 在此不进行伴细说明。
步驟 140:主叫的归属 S-CSCF判断被叫的归属网络是否支持主叫的 IP版本， 如果是， 则执行步骤 160; 否则， 执行步驟 150。 主叫的归属 S-CSCF可以通过查询或者配置的方法得到被叫的归属网络的 IP版本。 例如， 当主叫的归属 S-CSCF得到的是被叫的归属网络域名时， 可以根 据当前自己使用的 IP版本发送查询请求给 DNS， 需要说明的是， 这里 查询得到的仅仅是被叫 UE所在网络对外接口的 I-CSCF的地址，但是基 于上文的考虑， 认为 I-CSCF的地址类型可以代表其所在 IMS网络的 IP 地址类型。 >据 DNS月 务器返回的 IP地址类型， 主叫的归属 S- CSCF 可以确定是否可以不经过 ALG/NAT-PT变换直接与对端进行通信。在本 发明的一个较佳实施例中， 主叫的归属 S-CSCF当前收到 IPv4消息， 则 主叫的归属 S-CSCF先根据被叫的归属网络域名，向 DNS服务器查询被 叫的归属网络是否有对应的 IPv4地址，如果 DNS服务器返回了 IPv4类 型的地址， 说明被叫的归属网络支持 IPv4或者支持 IPv4和 IPv6双栈； 否则， DNS服务器会只返回被叫的归属网络对应的 IPv6地址。 熟悉本 领域的技术人员可以理解， 除了查询 DNS服务器， 还可以直接将被叫 地址或者归属网络域名和其所在归属网络支持的 IP 版本信息配置在 S-CSCF或者 I-CSCF中， 这样， 也可以确定是否可以直接与被叫所在归 属网络对外接口的 I-CSCF进行通信。
步骤 150: 主叫的归属 S-CSCF使用 ALG/NAT-PT执行 IP版本信息 的转换后被叫的归属 S-CSCF/I-CSCF, 发送给， 然后执行步骤 180。 在 本发明的一个较佳实施例中， 主叫的归属 S-CSCF将 SIP消息转发到主 叫归属网络的 ALG功能实体执行应用层的 IP地址版本信息转换， ALG 控制 NAT-PT功能实体执行用户面 IP地址版本信息转换。 其中， ALG 功能实体与 NAT-PT功能实体之间可以使用 SIP协议、 或 H.248协议、 或媒体网关控制（ MeGaCo, Media Gataway Control )协议进行通信。 需 要说明的是，主叫的归属 S-CSCF在转发消息给 ALG功能实体时， 同时 向 ALG功能实体提供下一跳的地址， 用于后续消息的路由。
步骤 160: 主叫的归属 S-CSCF直接向被叫的归属 S-CSCF/I-CSCF 发送消息， 然后执行步骤 180。 在该步骤中， 由于被叫的归属网络支持 主叫的 IP版本， 不需要进行 IP版本的转换也可以直接通信， 因此基于 将转换尽量放在被叫侧完成的原则， 主叫的归属 S-CSCF将消息直接发 送给被叫的归属 S-CSCF/I-CSCF。
步骤 170: 主叫的归属 S-CSCF不进行 IP版本转换直接进行处理后 结束整个流程。 在该步驟中， 由于主叫和被叫的归属网络相同， 不需要 进行 IP版本转换即可直接进行通信，相关的处理方法和现有技术完全相 同， 在此不详细说明。
步驟 180:被叫的归属 S-CSCF收到对被叫发起的呼叫后，判断被叫 是否支持主叫的 IP版本，如果是，则执行步骤 210;否则，执行步骤 190。 其中， 被叫支持的 IP版本存储在本地， 可以直接查询得知。
步骤 190: 被叫的归属 S-CSCF将消息发送到 ALG功能实体执行应 用层 IP版本转换。 其中， 该步骤中的 ALG功能实体为被叫的归属网络 中的 ALG功能实体， 被叫的归属 S-CSCF在转发消息给 ALG功能实体 时， 同时向 ALG功能实体提供下一跳的地址， 用于后续消息的路由。
步骤 200: ALG功能实体控制 NAT-PT功能实体执行用户面 IP版本 转换。其中， ALG功能实体和 NAT-PT功能实体之间可以使用 SIP协议、 或 H.248协议、 或 MeGaCo协议进行通信。
步骤 210: 将消息转发给被叫对应的 P-CSCF。 熟悉本领域的技术人 员可以理解， 被叫对应的 P-CSCF支持的 IP版本和被叫支持的 IP版本 相同。
步骤 220: 被叫 P-CSCF将消息发送给被叫。 其中， 该步驟中， 消息 的 IP版本已经为被叫所支持的 IP版本。
至此， 完成一个端到端的带有媒体协商的会话的建立流程。
本领域的技术人员可以理解， 当步驟 130中执行私有 IP地址到公有 IP地址变换的 NAT设备与步骤 150中执行 ALG/ANT-PT功能的设备是 不同的设备时， 那么按照上述流程实现， 否则， 步骤 130中执行的私有 IP地址到公有 IP地址的变换可以和步骤 150中执行 ALG/NAT-PT的变 换一起实现。
根据上述流程， 本发明的一个较佳实施例的端到端的带有媒体协商 的会话的建立流程中各个功能实体之间的消息传递流程如图 4所示。 图 4所示的该较佳实施例的消息传递流程比较清楚， 本领域的普通技术人 员参照图 3的说明很容易理解。
对于图 4的消息传递流程的说明如下：
首先， UE A向 UE B发起一个 IMS会话请求， 该消息是使用 IPv4 传送的；
然后， UE A对应的 P-CSCF A 向 UE A 的归属网络的 S-CSCF A/I-CSCF A转发该会话请求消息；
然后， S-CSCF A/I-CSCF A根据向 DNS服务器的查询或本地配置确 定 UE B的归属网络能够支持当前 S-CSCF A使用的 IPv4版本 , 因此决 定继续向 UE B的归属网络的 S-CSCF B/I-CSCF B转发该会话请求消息； 然后， S-CSCF B/I-CSCF B将保存的 UE B的 IP地址与收到的请求 消息使用的 IP地址类型进行比较，发现不一致， 必须使用 ALG/NAT-PT 功能进行转换， 则将该消息转发到 ALG功能实体， 同时向 ALG功能实 体提供 UE B对应的 P-CSCF B的地址；
然后， ALG功能实体执行 IP地址版本相关信息从 IPv4到 IPv6的转 换， 因为涉及到对用户面的修改， 因此， 使用扩展的 SIP协议、或 H.248 协议、或 MeGaCo协议与 NAT-PT功能实体进行交互；交互结束后， ALG 功能实体将新构造的会话倩求消息发送给 UE B当前所在网络的 P-CSCF B, 该消息使用 IPv6传送， 而且媒体描述已经被修改；
然后， P-CSCF B向 UE B转发该会话请求消息；
最后， 后续的信令交互将在 UE A、 S-CSCF B/I-CSCF B、 ALG和 UE B之间进行， 即图 4中建立的会话信令路径； 后续的媒体交互将在 UE A、 NAT-PT功能实体和 UE B之间进行， 即图 4中建立的媒体路径。
需要说明的是， 如果一种涉及业务的 IP版本互通场景， 不需要进行 媒体协商， 比如即时消息就是只有 SIP信令没有媒体协商过程， 此时， 就不需要 ALG功能实体执行 IP地址信息映射的处理。 这种情况下， 不 同 IP版本的 IP网络互通的原理和上述流程的原理相同， S-CSCF可判断 收到的消息中是否有媒体描述，如果是， 则 S-CSCF使用 ALG设备以及 NAT-PT设备对消息进行 IP版本转换； 否则， 由于消息比较短， 因此不 需要媒体流， 只是由被叫的归属 S-CSCF完成一个 IP版本到另一个 IP 版本的映射， 不需要使用 ALG/NAT-PT功能， S-CSCF可直接对消息进 行 IP版本转换。 在消息互通的时候， 下一跳的 IP版本同样可以通过查 询本地设置或 DNS服务器得到。
根据本发明的一个较佳实施例的实现一个支持 IPv4 的 UE和支持 IPv6的 UE之间进行即时消息业务的方法中消息的传递示意图如图 5所 示。 其中 UE A在传送即时消息给 UE B时， 不涉及到媒体成分的协商， 直接使用 SIP信令携带相关的信息， UE B的归属网络与 UE A的归属网 络不同。 在被叫方一侧， UE B的归属 S-CSCF支持 IPv4和 IPv6双栈 , 负责将使用 IPv4传送的 SIP消息直接转化为使用 IPv6传送的 SIP消息 , 然后继续传送给接收方 UE B。
熟悉本领域的技术人员可以看出， 本发明通过在 S-CSCF处对主叫 和被叫支持的 IP地址类型或者归属网络支持的 IP版本进行判断， 只有 在双方版本不一致的情况下才使用 ALG/NAT-PT功能， 否则就放在端到 端流程的最后一个 S-CSCF, 即被叫 S-CSCF处使用 ALG/NAT-PT或者 仅仅是执行 IP版本的映射， 从而可以最大程度的降低对 ALG/NAT-PT 功能的使用次数； 此外， 该方法对 IPv4和 IPv6同等对待， 在 IMS应用 的初期， 因为使用 IPv4的消息较多， 因此， 根据每次查询 DNS服务器 或者配置的结果， 将尽量使用 IPv4传送， 等到后期使用 IPv6成为主流 的时候， 使用该方法将大量使用 IPv6传送消息， 因此兼容性好， 可以应 用在 IMS商用的各个阶段。
图示中的 S-CSCF/I-CSCF只是呼叫状态控制功能在 IMS网络中应用 时对应的逻辑实体的名称， 当该方法应用在一^：的 SIP 网络中时， S-CSCF/I-CSCF对应的就是 SIP网络中负责处理 UE会话请求的状态代 理服务器， P-CSCF对应的是会话路径中的代理服务器， 其功能是一样 的， 不过是应用的网络不同， 因此， 该方法也可以应用在一般的 SIP网 络中。
虽然通过参照本发明的某些优选实施例， 已经对本发明进行了图示 和描述， 但本领域的普通技术人员应该明白， 可以在形式上和细节上对 其作各种各样的改变， 而不偏离所附权利要求书所限定的本发明的精神 和范围。

Claims

权利要求书
1、 一种不同版本的网间互联协议网络互通的方法， 其特征在于， 该 方法包含以下步骤：
A、 主叫的归属呼叫状态控制设备判断被叫的归属网络是否支持主 叫的网间互联协议 IP版本，如果是， 则将来自主叫的消息直接转发给被 叫的归属呼叫状态控制实体， 否则， 对该消息进行 IP版本转换后， 发送 给被叫的归属呼叫状态控制设备；
B、 被叫的归属呼叫状态控制设备收到消息后， 判断被叫是否支持 该消息的 IP版本， 如果是， 则将该消息直接转发给被叫， 否则， 对该消 息进行 IP版本转换后， 发送给被叫。
2、 根据权利要求 1所述的方法， 其特征在于， 所述步驟 A之前进 一步包括：
A01、 主叫的归属呼叫状态控制设备判断主叫的 IP地址是否为私有 IP地址， 如果是， 则执行步驟 A02, 否则， 直接执行步骤 A;
A02、 主叫的归属呼叫状态控制设备使用网络地址转换 NAT功能实 体将私有 IP地址转换为公网 IP地址， 然后执行步骤 A。
3、 根据权利要求 2所述的方法， 其特征在于， 所述步骤 A01和步 骤 A02之间进一步包括：主叫的归属呼叫状态控制设备判断被叫的归属 网絡与主叫的归属网络是否相同，如果是，则主叫和被叫直接进行通信； 否则， 执行步骤 A02。
4、 根据权利要求 1所述的方法， 其特征在于， 步骤 A中所述主叫 的归属呼叫状态控制设备判断被叫的归属网络是否支持主叫的 IP版本， 包括： 主叫的归属呼叫状态控制设备通过查询本地配置或域名服务系统 DNS服务器获取被叫的归属网络支持的 IP版本， 然后判断被叫的归属 网络是否支持主叫的 IP版本。
5、 根据权利要求 1、 2或 3所述的方法， 其特征在于， 步驟 A或步 骤 B中所述对消息进行 IP版本转换， 包括： 呼叫状态控制设备判断所 述消息中是否有媒体描述， 如果是， 则执行步骤 g, 否则， 呼叫状态控 制设备直接对消息进行 IP版本转换；
g、呼叫状态控制设备使用应用层网关设备以及网络地址转换和协议 转换设备对消息进行 IP版本转换。
6、根据权利要求 5所述的方法， 其特征在于， 所述步驟 g进一步包 括： 呼叫状态控制设备向应用层网关设备提供用于后续消息路由的下一 条地址。
7、根据权利要求 5所述的方法， 其特征在于， 应用层网关设备与网 络地址转换和协议转换设备之间使用会话初始化协议、 或 H.248协议、 或媒体网关控制 MeGaCo协议进行通信。
8、 根据权利要求 1所述的方法， 其特征在于， 步骤 A中所述来自 主叫的消息为 SIP消息。
9、 根据权利要求 1所述的方法， 其特征在于， 在多媒体子系统中， 所述呼叫状态控制设备为呼叫状态控制功能实体。
10、 根据权利要求 1所述的方法， 其特征在于， 步骤 B中所述判断 被叫是否支持消息的 IP版本， 包括： 被叫的归属呼叫状态控制设备通过 查询存储于本地的被叫支持的 IP版本获取被叫支持的 IP版本， 然后判 断被叫是否支持消息的 IP版本。
PCT/CN2005/001640 2004-10-05 2005-10-08 Procede d'intercommunication entre des reseaux possedant des versions differentes du protocole internet WO2006037276A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05795754A EP1798918A4 (en) 2004-10-05 2005-10-08 INTERCOMMUNICATIONS PROCEDURES BETWEEN NETWORKS WITH DIFFERENT INTERNET PROTOCOL VERSIONS
US11/703,709 US7792116B2 (en) 2004-10-05 2007-02-08 Method and device for interworking between internet protocol networks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200410079321.1A CN1758649B (zh) 2004-10-05 2004-10-05 版本不同的网间互联协议网络互通的方法
CN200410079321.1 2004-10-05

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/703,709 Continuation US7792116B2 (en) 2004-10-05 2007-02-08 Method and device for interworking between internet protocol networks

Publications (1)

Publication Number Publication Date
WO2006037276A1 true WO2006037276A1 (fr) 2006-04-13

Family

ID=36142297

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2005/001640 WO2006037276A1 (fr) 2004-10-05 2005-10-08 Procede d'intercommunication entre des reseaux possedant des versions differentes du protocole internet

Country Status (4)

Country Link
US (1) US7792116B2 (zh)
EP (1) EP1798918A4 (zh)
CN (1) CN1758649B (zh)
WO (1) WO2006037276A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008039744A3 (en) * 2006-09-25 2008-05-15 Zte Corp System and method for ipv4 and ipv6 migration
CN112714504A (zh) * 2020-12-16 2021-04-27 北京连山科技股份有限公司 一种端到端实时数据传输方法及系统
CN113726881A (zh) * 2021-08-30 2021-11-30 北京百度网讯科技有限公司 通信连接建立方法、相关装置及计算机程序产品

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100208634A1 (en) * 1994-10-11 2010-08-19 Arbinet Corporation System and Method For Managing Multimedia Communications Across Convergent Networks
US8046019B2 (en) * 2006-08-04 2011-10-25 Futurewei Technologies, Inc. Method and system for optimal allocation of uplink transmission power in communication networks
US8325654B2 (en) 2006-12-28 2012-12-04 Futurewei Technologies, Inc. Integrated scheduling and power control for the uplink of an OFDMA network
CN100512461C (zh) 2007-05-17 2009-07-08 华为技术有限公司 消息业务实现方法和消息应用服务器
CN101068215B (zh) * 2007-06-29 2011-09-21 华为技术有限公司 优化媒体协商的方法、装置及系统
CN101340613B (zh) * 2007-07-05 2012-12-12 华为技术有限公司 一种实现用户终端通信的方法、装置和系统
US8185628B2 (en) 2008-03-07 2012-05-22 At&T Mobility Ii Llc Enhanced policy capabilities for mobile data services
CN101600196B (zh) * 2008-06-04 2011-09-14 华为技术有限公司 一种数据通道建立方法及通讯系统以及相关设备
US8683077B2 (en) * 2008-06-24 2014-03-25 Blackberry Limited Method for indicating supported IP versions and reaching a device that supports compatible IP versions with SIP
US8331355B2 (en) * 2008-06-24 2012-12-11 Research In Motion Limited Method for a network component to route a communication session
US8891388B2 (en) 2008-12-08 2014-11-18 Zte Corporation Path node determining method, media path establishing method, and signaling media gateway
US8121600B2 (en) * 2008-12-30 2012-02-21 Motorola Mobility, Inc. Wide area mobile communications over femto-cells
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
US8059643B1 (en) 2009-05-11 2011-11-15 Sprint Communications Company L.P. IPv4 and IPv6 single session on a home agent
RU2550517C2 (ru) * 2011-01-06 2015-05-10 Телефонактиеболагет Л М Эрикссон (Пабл) Способ маршрутизации сессии от вызывающей стороны в обслуживающей сети связи вызывающей стороны к вызываемой стороне
JP5601421B2 (ja) * 2011-07-22 2014-10-08 富士通株式会社 サーバ装置、通信制御プログラム、及び通信制御方法
CN102347950B (zh) * 2011-09-29 2018-02-06 中兴通讯股份有限公司 电信网络向互联网提供会话服务的方法及系统
CN103796195B (zh) * 2012-10-31 2017-05-03 中国移动通信集团公司 一种数据传输处理方法、系统及数据业务网关
WO2015085521A1 (zh) * 2013-12-11 2015-06-18 华为技术有限公司 互联网协议地址分配方法和装置
CN107277188B (zh) * 2017-06-19 2020-01-14 网宿科技股份有限公司 一种确定ip地址归属信息的方法、客户端、服务器及业务系统
CN110912835B (zh) * 2019-11-08 2023-04-07 腾讯科技（深圳）有限公司 业务分流方法、装置及系统
WO2023018968A1 (en) * 2021-08-13 2023-02-16 Fieldcomm Group Security negotiations between different versioned protocol devices to enable backward compatibility

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6580717B1 (en) * 1996-07-04 2003-06-17 Hitachi, Ltd. Packet communication method and apparatus and a recording medium storing a packet communication program
US20030149790A1 (en) 2002-01-08 2003-08-07 Samsung Electronics Co., Ltd. Apparatus for converting internet protocol address, and communication method using the same
CN1496070A (zh) * 2000-05-30 2004-05-12 ������������ʽ���� 多点通信方法和装置
US20040146042A1 (en) 2003-01-08 2004-07-29 Yousuke Ideshita Mobile communication system and method capable of allowing shortest communications path

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4186446B2 (ja) * 2001-09-11 2008-11-26 株式会社日立製作所 アドレス変換方法
JP3972733B2 (ja) * 2002-05-30 2007-09-05 株式会社日立製作所 アドレス変換装置、アドレス変換システム、及びｓｉｐサーバ
US7272148B2 (en) * 2002-06-27 2007-09-18 Hewlett-Packard Development Company, L.P. Non-ALG approach for application layer session traversal of IPv6/IPv4 NAT-PT gateway
JP2005086467A (ja) * 2003-09-09 2005-03-31 Hitachi Ltd セッション制御装置、情報通信端末、サーバ、及び端末
CN1839592A (zh) * 2003-09-11 2006-09-27 富士通株式会社 包中继装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6580717B1 (en) * 1996-07-04 2003-06-17 Hitachi, Ltd. Packet communication method and apparatus and a recording medium storing a packet communication program
CN1496070A (zh) * 2000-05-30 2004-05-12 ������������ʽ���� 多点通信方法和装置
US20030149790A1 (en) 2002-01-08 2003-08-07 Samsung Electronics Co., Ltd. Apparatus for converting internet protocol address, and communication method using the same
US20040146042A1 (en) 2003-01-08 2004-07-29 Yousuke Ideshita Mobile communication system and method capable of allowing shortest communications path
CN1518301A (zh) * 2003-01-08 2004-08-04 �ձ�������ʽ���� 能允许最短通信路径的移动通信系统和方法

Non-Patent Citations (1)

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

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008039744A3 (en) * 2006-09-25 2008-05-15 Zte Corp System and method for ipv4 and ipv6 migration
US8228942B2 (en) 2006-09-25 2012-07-24 Zte Corporation System and method for IPv4 and IPv6 migration
CN112714504A (zh) * 2020-12-16 2021-04-27 北京连山科技股份有限公司 一种端到端实时数据传输方法及系统
CN112714504B (zh) * 2020-12-16 2021-11-05 北京连山科技股份有限公司 一种端到端实时数据传输方法及系统
CN113726881A (zh) * 2021-08-30 2021-11-30 北京百度网讯科技有限公司 通信连接建立方法、相关装置及计算机程序产品
CN113726881B (zh) * 2021-08-30 2024-04-05 北京百度网讯科技有限公司 通信连接建立方法、相关装置及计算机可读存储介质

Also Published As

Publication number Publication date
EP1798918A1 (en) 2007-06-20
US20070195755A1 (en) 2007-08-23
CN1758649A (zh) 2006-04-12
EP1798918A4 (en) 2007-11-14
CN1758649B (zh) 2010-04-28
US7792116B2 (en) 2010-09-07

Similar Documents

Publication Publication Date Title
WO2006037276A1 (fr) Procede d'intercommunication entre des reseaux possedant des versions differentes du protocole internet
JP4571618B2 (ja) 会話型ベアラの交渉
CN100563235C (zh) 互通功能网元、csi终端与ims终端互通系统及其方法
US7965704B2 (en) Method and apparatus for handling IMS terminal's call request including request for real-time service received over IMS domain by CSI terminal
JP5118204B2 (ja) マルチメディアセッションコール制御方法およびアプリケーションサーバ
US8325708B2 (en) Method and apparatus for interworking voice and multimedia services between CSI terminal and IMS terminal
JP4988338B2 (ja) 会話型ベアラネゴシエーション
KR100886548B1 (ko) 인터넷 프로토콜 멀티미디어 서브시스템 네트워크에서단말의 성능 정보를 전달하기 위한 방법 및 시스템
CN101094171B (zh) 实现媒体流交互方法和系统及媒体网关控制器和媒体网关
Faccin et al. IP multimedia services: analysis of mobile IP and SIP interactions in 3G networks
EP1770949A2 (en) Method and communication system for circuit switch users accessing IP multimedia subsystem
WO2006102830A1 (fr) Procede destine a un terminal d’identification de commande de routage d’interaction de capacite pendant que ims et cs sont co-instantanes
WO2006099815A1 (fr) Procede d'enregistrement d'un utilisateur dans le sous-systeme multimedia ip et systeme associe
WO2006116939A1 (fr) Méthode pour réaliser un service de messagerie basé sur un sous-système multimédia en réseau ip
US9055397B2 (en) Method for usage of VPLMN infrastructure by an HPLMN to terminate an IMS session set up for a roaming user
WO2007025429A1 (fr) Procede evitant la derivation du flux media et dispositif correspondant
JP2005530428A (ja) 無線ネットワークへの配送を最適化するための、アプリケーションからの特定指令によるシグナリング・パケットの配送制御
WO2007025443A1 (fr) Systeme de passerelle dans un sous-systeme multimedia ip et methode correspondante
Munasinghe et al. Interworking of WLAN-UMTS networks: an IMS-based platform for session mobility
WO2008110110A1 (fr) Procédé et système de fourniture de service de sous-système multimédia ip
Thanh et al. mSCTP-based proxy in support of multimedia session continutity and QoS for IMS-based networks
KR100895283B1 (ko) 이동 ＶｏＩＰ 서비스 제공 장치 및 호 연결 방법
CN100496049C (zh) Sip多媒体系统中用户面互通方法
Chen et al. An effective IPv4–IPv6 translation mechanism for SIP applications in next generation networks
CN101159744A (zh) 版本不同的网间互联协议网络互通的方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005795754

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11703709

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2005795754

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11703709

Country of ref document: US