Call routing of the SIP IP phone system
Zhao Zhifeng 1,2,3 Yang Yongkang 2 hatred 1
(1. Zhejiang University Postdoctoral Research Mobile Station Hangzhou 310027, China)
(2. Eastern Communication Postdoctoral Research Station Hangzhou 310053)
(3. School of Communication Engineering, PLA, Nanjing 210007, China)
Summary: The article first introduces several basic concepts used by the SIP IP phone system call routing, including requesting resource identifiers, routing heads, routing records, and routing sets. Then describe the basis of the SIP call routing - the registration and the logout process. There are two cases of the SIP system's call routing process for the SIP system within two situations and dialogue. Finally, the SIP mobile frame and the mobile call routing process are given. Keywords: SIP IP Phone System Call Routing Mobility Redirection
1 Introduction
The call routing process of the SIP IP phone system is completely coordinated by the user agent, the proxy server, and the registration server. The user agent is used to initiate and receive a call, and the proxy server is responsible for forwarding the call request and response message. The registration server accepts the registration request of the user agent and updates the user's address mapping information in the locator.
This article will introduce the call routing process of the SIP on the basis of [1]. The main content has basic concepts and terms, registration / logout processes, dialogue, and call routing processes outside the dialogue, and call routing processes when moving.
2 Basic Concept 2.1 Request Resource Identification
Request-URI is the primary content of the request message starting line, and its function is the final recipient that identifies the request message in RFC 3261 [2]. When the user agent customer (UAC: user agent client) sends a request message, the content requested the resource identifier is generally the logical address of the called. When the request message reaches the called domain, the proxy server finds the contact address of the called location by looking up the location server. When requesting a message to the called forward request message, the request resource ID will be modified to the called address.
2.2 Routing records and routing heads
The role of the Route Record (the Route) The header is to record the path to the request message, represented by the proxy server SIP URI address sequence. The header is inserted by the proxy server that the request message is inserted as needed, and all request messages for enforce this dialog must pass the proxy server.
The role of the Route head is very similar to the role of the Source point selection option in the TCP / IP. The header as part of the request message describes the list of proxy servers that the request message must pass. The routing head is also represented in the form of a proxy server SIP URI list, and is generated by the user when constructing a message. For request messages that have not yet established a dialog (called dialogue), the routing header is generally set according to the content of the preset routing set. For request messages that have established dialog (called dialogue), the routing header is set according to the content of the Route Set.
2.3 Routing Set
The routing set is a SIP URI sequence that indicates that the user agent must have a list of servers that must be elapsed when sending a request message to the peer user agent within the conversation. The content of the routing set is extracted from the routing header of the request or response message of the establishment of the conversation, which is only valid within the scope of this dialog.
3 Registration and cancellation process
The SIP uses the idea of the logical address and the contact address. The logical address is used to identify the user, and the contact address indicates the user's current location. This separation provides technical possibilities for mobility of users. In order to realize dynamic mapping between logical addresses and contact addresses, support must be supported by registration and logout.
SIP defines the registration server and the Register message. User agent can complete the registration, logout, refresh, address mapping acquisition, etc. by sending a Register request message to the registration server. When constructing a registration request message, the request-uri domain should contain the domain name information of the registration server; the token contains the logical address of the user to register or log out; from ORM contains address records of the registered message; Contact contains the contact address information to register. To implement communication with the registration server, the user agent must first determine the address of the registered server. SIP defines three confirmation methods: static configuration, using address records and through multicast, see RFC 3261 for details.
Registration: When the user agent adds an address mapped record to the registration server, the Contact domain contains the lifetime of the contact address to increase, and declare the life period of the contact address via the Expires header domain or the EXPIRES parameter of the address information. Users can increase multiple address mapping records through a Register request message.
Refresh: When you want to refresh an address mapping record, the Contact domain contains the contact address information to be refreshed, and declare the life-action period of the registration address through the Expires header domain or the EXPIRES parameter of the address information to refresh the mapping record. The user can refresh a particular record or simultaneously refresh multiple mapping records.
Logout: When the user agent wants to delete a mapping record, you can fill in the contact address information you want to delete in the Contact domain, and set the expiRES parameter 0, and the mapping record will be removed after the registration server is received. If the Contact domain is set to "*", and the expiRES header domain is set to 0, all contact address mapping records of the user will be deleted.
Get address mapping: After each successfully processed the Register request message each time, it will return a status code 200 successful response. The response of the Contact header will contain all contact address information registered by the user. The user can obtain all address mapping records of the user from the response message.
The user agent can receive a call after the registration server is successfully registered. Its enter the agent forwards the call request message to the current contact address of the user agent based on the query result of the user's address mapping information. If registration is not registered, the entry agent will not know the current location of the user agent.
4 call routing
The call routing of the SIP system is essentially the routing process of the INVITE request message. It contains how the user agent customer builds a request message, sent to the next hop; how the proxy server processes the request message, forwards to the next hop; until the request message reaches the input agent and sends a process of sending it to the user proxy server. During the call, the next hop URI address can be determined using the DNS lookup process defined by RFC 3263 [3] to determine the use of the transfer protocol, the target IP address, and the port number to send the message to the next hop. The call routing of the following dialogue and call routing within the conversation are introduced.
4.1 Route outside the dialogue
The routing of the dialogue refers to the route process when the user agent client uses the INVITE request message to initiate a call.
4.1.1 User Agent Customer
When the user agent client UA is to send a request message, it sets the value of the TO header of the request message to the logical address of the called party, set the value of the FROM head to the logical address of the user, set the CONTACT header. The user's current contact address. Set the value of the Request-URI to the same logical address as the TO header. The user agent customer constructs other contents of the request message as needed and configuration information.
The process of the route (ROUTE) header is more complicated. Under normal circumstances, the user agency customer has a preset routing set, which contains a list of proxy servers that the user must pass when sending a request message. This can be flexible to the route of the request message. The easiest application of the preset route set is to include only the SIP URI address of the agent. Thus all request messages will be sent to the outgoing agent, which is responsible for forwarding the message by the outgoing agent. User Agent Customer uses the content of the preset routing set as a routing head, inserted into the request message in order. After completing the above steps, you must perform DNS queries to get the next hop address, port number, and transfer protocols used. User Agent Customer Inserts a VIA header in the request message (including your own host address, port number, transfer protocol, etc.), send the request message to the next hop.
4.1.2 Proxy Server
After receiving the request message, the proxy server is first checked. Possible steps are: syntax check, request-uri check, loop detection, etc. In order to implement backward compatibility, the proxy server also processes the request message to form a standard request message that meets the RFC 3261 requirements.
If the proxy server is an intermediate proxy server (the domain in the Request-URI is not responsible by this proxy server), then the target of the request message is the request-URI, there is no need to perform more operations.
If the proxy server is an entry agent (the domain in the Request-URI is responsible by this proxy server). The proxy server needs to determine the request target for the request. RFC 3261 describes the means of determining the request target into a locating server, and the access result is a set of SIP URIs. The proxy server uses these SIP URI to build a target set, that is, the actual recipient of the request message. In general, the entry agent sorts the SIP URI in the target set, and sequentially processed according to the high and low priority. The proxy server replaces the message's request-URI to the address from the target set. This means that the destination of the request message has become a new address, that is, from the user's logical address to the current contact address of the user.
If the proxy server requires the subsequent request message established by this request message must pass the proxy server, it inserts its own SIP URI into the front of the routing header. Then determine the next hop address, the port number, and the proxy server inserted into the VIA header in the request message, and sends the message to the next hop.
4.1.3 User Agent Server
After the user agent server receives the request message, if the message is legal, it will be prepared to send a successful response and establish a conversation. User Agent Server To build a conversation context for the conversation. The content of the routing set is built according to the routing record header included in the request message, which indicates a list of proxy servers that must be passed from the request message called the calling call.
User Agent Server builds a response message, copy the header information such as TO, FROM, VIA, RECORD-ROUTE from the request message. Set the contents of the Contact head to your contact address.
Since the VIA header indicates the send path of the request message, the response message will return to the sender's user agent customer along the path.
4.1.4 Redirection
The SIP defines the redirect server and can be redirected according to the configuration. For example, a user opens a call forwarding service, and if you receive a call request to it, you can respond by redirectation. Again, if the redirect server is discovered by querying the locator, the user has moved out of the domain, which can also reactivate the call by redirecting the user agent.
The redirect server can be placed together with the entering proxy server or user proxy server to implement control of the call request. When the redirect server is determined to redirect a request message, it will construct a redirect response message. The contents of the response message of the TO, FROM, VIA and other heads are copied from the request message. The content of the Contact domain includes a list of redirected target addresses. The redirect response message will return to the user to the user according to the original path according to the contents of the VIA header. User Agent Customer After receiving an redirect response, build a new target set according to the contents of the response message Contact header and re-initiate the call request using a call routing process outside the dialog. 4.2 Routing within the conversation
When the dialog is established, the user agent customer and user proxy server will establish a conversation context for the conversation. The conversation context contains information such as logical addresses, contact addresses, and request messages. With this information, please
The routing process of requesting messages is very simple. Since the proxy server cannot sense the presence of the dialog, the behavior of the proxy server is the same as the dialogue.
4.2.1 User Agent Customer and Server
When a user agent customer wants to build a request message, the content of the message is set to the remote URI and local URI of the conversation context, respectively. The value of the Request-URI is set as the remote target of the conversation context. The routing set of the conversation context is inserted into the request message in the routing head. After the message is built, it is sent to the next hop.
The user agent server is more simple, and after receiving the request message and gives the appropriate response. The response message returns to the user agent customer in the path of the VIA header.
If the successful response is received, the request is completed successfully. If a redirect response is received, the redirection response message is processed accordingly.
4.2.2 Target Refresh
A very important process in the conversation process is the target refresh, that is, refreshed the user's contact address and session parameters. During the dialogue, if the contact address or session parameters of either party changes, the other party can be notified by the target refresh.
The target refresh is implemented by the INVITE request message in the dialog (called RE-INVITE). When the contact address of the user agent changes, it constructs an INVITE request message using the conversation context information, putting the new contact address in the Contact header, and send the message to the other party using the routing process within the dialog. After the other party receives the request message, discover the content of the contents of the Contact header and the remote target of the conversation, use the new contact address to update the remote target of the conversation context. The target refresh process can also be used to modify the current session parameters, such as increasing the media stream, changing ports, etc.
5 call routing when moving
In order to meet the needs of multimedia communication systems, SIP takes into account the support of mobility at the beginning of the design, and uses a variety of simple, flexible mechanisms. For example, logical address and contact address separation, registration / logout, target refresh, etc. SIP user agent, registration server, and proxy server assumes a certain function in the mobile frame.
5.1 Mobile Framework
The SIP mobile frame includes address separation mechanism, registration / logout, call redirection, and target refresh process.
The basis of the user mobility is the uniqueness of its identity, and other users use this unique identifier to contact mobile users, and the SIP is called the logical address of the mobile user. However, to implement communication with mobile users, you must send the packet to its current location, that is, its contact address. This contact address is varied as the mobile user location changes. Users use logical addresses for calls, and network entities communicate with the contact address.
Address separation provides the foundation for mobility support. To complete a call to a mobile user, you must know the current location information of the user. This requires the support of registration and logout processes. When a user accesss to a SIP system, it first initiates registration to report its current contact address. When the user changes the contact address due to movement, it must log out of the old address mapping and establish a new address mapping through the registration process. Thus, the address map in the positioning server can always reflect the user's latest location information to ensure a call to the mobile user.
A process related to mobility support is a callback redirect. When the redirect server finds that the call needs to be redirected (for example, it is found to be moved), it generates a redirect response message, and the current contact address of the called user is called the calling user. The calling user initiates the INVITE Call Request to the new contact address. The request message is routed to the user terminal where the contact address is located. From this, it can be seen that the call redirect is a universal signaling process established after the user moves. The target refresh can be used to inform Communication The other party's own contact address changes. This is very important for the movement in communication. When the user moves in communication, its contact address may change (such as entering another domain to change the IP address). When the contact address changes, the user uses the target refresh process to inform the new contact address to the peer. The peer can use the new contact address to communicate with its communication, ensuring the uninterrupted communication in the movement. After the target refresh process is completed, the user must register a new address to your registration server in time so that the network knows its current location.
5.2 Mobility Support
In Figure 1, after the mobile terminal user moves to the field network, first register the current contact address to its home network through the registration process. The peer user initiates a call using the logical address of the mobile terminal user, and the call request reaches the input agent server of the mobile terminal user, the query positioning server discovers that the mobile terminal has moved its home network. The entry agent informs the peer user by redirecting the current contact address of the mobile terminal user. Reissute the call request to the current contact address of the mobile terminal user. Therefore, the moving call routing process is completed by the address separation mechanism, registration / logout, and call redirection process.
In FIG. 2, the communication peer and the mobile terminal user are performing communication, and the mobile terminal user moves from the field network 1 to the field network 2, causing its contact address to change. Mobile Terminal User uses the target refresh process to tell the peer to the peer, the peer to communicate with its new address. It can be seen that mobility support during communication is completed by the target refresh process.
2 Mobile during communication
6 Conclusion
This article describes a detailed introduction to the call routing process of the SIP IP phone system. After describing the basic concept, the basic registration / logout process is first described. The registration / logout process is the premise of the SIP call routing process. There are two cases of the article sub-dialogue and the dialogue to the SIP's call routing process. Since the SIP takes into account the support of mobility when designing, mobile call routing and movement during communication can be well supported.
With the gradual maturity and popularization of SIP, many researchers put forward the expansion usage scheme for SIP. For example, the support of timely messages [4], support for conference functions [5], etc. We will closely track the development of SIP applications and study these new application methods.
references
[1] Zhao Zhifeng, Yang Yongkang, Qiu Pei Liang.Sign IP Phone System Based on SIP. China Data Communication, No. 1 2004.
[2] IETF RFC 3261, Session Initiation Protocol, June 2002.
[3] Ietf RFC 3263, Session Initiation Protocol (SIP): Locating Sip Servers, June 2002.
[4] Ietf RFC 3428, Session Initiation Protocol (SIP) Extension for Instant Messaging, DEC, 2002
[5] J. Rosenberg. Draft-Ietf-Sipping-Conferencing-Framework-01, OCT 2003.
Zhao Zhifeng: Men, born in March 1975. In 2002, he received a Ph.D. in Communication and Information System of Communication Engineering College of Polytechnic University. Now the Postdoctoral Scientific Research Station of Zhejiang University & Oriental Communication Postdoctoral Scientific Research Work Station is engaged in the research work of next-generation network technology. The direction of the research is the next generation of network, soft exchange technology, AD HOC network and mobile network technology.
