CN1980152A - Method and system for realizing management of subscriber sign based on SIP protocol - Google Patents

Abstract

The present invention relates to a method and system for implementing user identification management based on the SIP protocol, which mainly includes: when the message sent by the user terminal carries an identification and the identification is available, the network side sets the identification as the user identification; when the message sent by the user end If the identifier is not carried or the carried identifier is not available, the network side restricts the use of the identifier in the session. It can be seen from the above-mentioned technical solution provided by the present invention that the present invention realizes the management and restriction of the user ID by the server, and optimizes the application of the user ID. The inconvenience brought to the session due to irregular user IDs appearing in the session is avoided.

Description

A method and system for implementing user identification management based on SIP protocol

technical field

The present invention relates to the communication field, in particular to a method and system for implementing user identification management based on the SIP protocol.

Background technique

SIP is a relatively simple session initiation protocol, which provides all communication protocols, but only provides session or call establishment and control functions. SIP supports both unicast and multicast, session participants and media types can join an existing conference at any time.

In a session based on the Session Initiation Protocol (SIP), in order to make the call connection of the user and the network side more humanized, each SIP User Agent (User Agent) can have an identifier. Each UserAgent entity has a number (Public Id) that meets SIP requirements, and can carry the above-mentioned user ID in this number, so that the User Agent that interacts with it does not see a long and boring string of characters (the user's Public Id), but a logo with rich content and full personality. In a SIP call, users can choose to hide their real ID anonymously and use an ID to represent themselves, making SIP calls very interesting.

Currently, the POC call signaling uses the Session Initiation Protocol SIP. In the POC group, each POC end user is assigned a Public Id and can set an identity for himself. Each Public Id uniquely represents a user, so the Public Id of each member cannot be repeated, but because the member ID does not affect the connection of POC calls, the ID of each member can be repeated. But the duplication of IDs will create a new problem, that is, if there are two members with the same ID in a group call at the same time, at the same time, the server's strategy is to display only IDs but not PublicId on the media interaction plane (User Plane) , at this time, the network side can only distinguish users according to the identifiers, so if the identifiers conflict at this time, the users cannot be distinguished; in addition, group members use anonymous calls, and members can provide their own identifiers. At this time, if the identifiers conflict, they cannot be distinguished Members.

In order to ensure that each member can be distinguished, it is required that the identifier of the member can be modified when the identifier conflict of the member occurs, so as to avoid the conflict.

In the prior art, if the terminal needs to modify the identity, the user can modify the original identity on the terminal to the desired identity, and in the next session, carry it in the INVITE sent by the terminal and send it to the network side for identity conflict detection.

Although the above prior art can realize the modification of the identification, this modification cannot realize real-time modification of the user identification. Once the identification is unavailable, it can only be modified before the next session, which still has a certain impact on the normal session.

Contents of the invention

In view of the above-mentioned problems in the prior art, the purpose of the present invention is to provide a method for real-time management of user IDs.

The purpose of the present invention is achieved through the following technical solutions:

A method for realizing management user identification based on SIP protocol, comprising:

A. When the message sent by the user terminal carries an identifier and the identifier is available, the network side sets the identifier as the user identifier;

B. When the message sent by the user terminal does not carry an identifier or the carried identifier is unavailable, the network side restricts the use of the identifier in the session.

The user identification includes the nickname used in the SIP protocol, and also includes any identification in the non-subscription identification used in the service.

The service request sent by the user terminal carries user identification information, and the network side detects the availability of the identification provided by the user terminal according to identification availability judgment rules.

The user identification availability judgment rules include but are not limited to:

Whether the client provides an identification;

or,

Whether the ID provided by the client conflicts with other user IDs in the business;

or,

Whether the identifier provided by the client complies with the system policy.

The policy provisions include, but are not limited to, prohibiting specified words and symbols, and setting the allowable range of identification length.

The network side restricts the use of the identifier in the session. When the identifier provided by the client is unavailable, the method for setting the identifier includes:

The network side resets the identity for the client after negotiation;

The network side restricts the use of the identifier in the session. When the identifier provided by the client is unavailable, the method for setting the identifier includes:

The network side directly resets the identity for the user end without negotiation.

The network side restricts the use of the identifier in the session. When the identifier provided by the client is unavailable, the method for setting the identifier includes:

The network side adopts such a processing method: the user cannot use the identification function in this session, and the session is established or proceeds normally.

The network side restricts the use of the identifier in the session. When the identifier provided by the client is unavailable, the method for setting the identifier includes:

The network side rejects the user's message request and/or terminates the user's participation in the session.

Wherein, when the identifier provided by the client is unavailable, the negotiation process includes:

The network side sets an identifier for the client, and the client judges whether to accept the identifier. If accepted, the client uses the identifier. If not, the client provides a new identifier to the network side and continues to negotiate with the network until until an identifier accepted and usable by the client is obtained.

The method for the network side to reset the identification for the client is as follows:

When the user terminal does not provide an identifier, set the user identifier as business information and add additional information;

When the ID provided by the client is not available, add additional information after the ID provided by the client.

The service information includes but not limited to service name, service group identifier, service provider information, service description information; the additional information includes but not limited to part or all of user identification information, user affiliation information, user subscription information, user Category information, random information.

Among them, when the identifier provided by the user terminal is unavailable, the content indicating the user reason value sent by the network side to the user terminal includes but is not limited to:

Inform the user that the logo is unavailable;

or

inform the user why the logo is unavailable;

or

Remind the user to provide a new logo;

or

Reminds the user that identification is not available for this session.

The user end can modify the identifier used at any time during the business.

The systems to which the method for implementing user identity management is applicable include, but are not limited to, all systems based on service initiation protocol entity exchange.

A database for storing prohibited signs is created on the network side.

Wherein, if the user ID conflicts with the prohibited ID in the database, the network side will reset an ID for the user according to the ID setting method.

The methods of carrying the identification include but are not limited to the following methods:

Ported using the user's Uniform Resource Identifier;

or,

Carried by the session description protocol body;

or,

Portable via Extensible Markup Language;

or

Carried in the SIP message header.

The network side sends a message to the user terminal, indicating the user identification restriction made by the network side.

A system for managing user identification based on the SIP protocol, including on the network side,

The identity management module is used to modify and set the identity provided by the client that conflicts with the identity in the session;

A negotiation module, configured to send the modification of the conflicting identifier by the identifier management module to the client side;

On the client side include,

The identification management initiating module is used to send identification setting and modification requests to the network side, and provide user identification.

Wherein, both the network side and the user end are equipped with a negotiation module, the network side negotiation module is used to send the modification of the conflicting ID by the identification management module to the user end side, and the user end negotiation module is used to judge whether to accept the network side as the user end. Modified ID.

Description of drawings

Fig. 1 is a schematic diagram of terminal user setting identification in the session establishment process according to an embodiment of the present invention;

Fig. 2 shows that an embodiment of the present invention modifies the schematic diagram of the identification when the user calls after the session is established;

Fig. 3 is described as an embodiment of the present invention when the user is called after the session is established and modifies the schematic diagram of the identification;

Fig. 4 shows a schematic diagram of management identification by POC terminal users under the condition that there is a negotiation process according to an embodiment of the present invention;

Fig. 5 shows a schematic diagram of management identification of a POC terminal user through a POC terminal when there is no negotiation process and the user is calling in an embodiment of the present invention;

Fig. 6 shows a schematic diagram of user management identification through the POC terminal when there is no negotiation process and the user is called in an embodiment of the present invention;

FIG. 7 is a schematic diagram of an embodiment of a POC system without negotiation between the network side and the user in the present invention;

FIG. 8 is a schematic diagram of an embodiment of a POC system without negotiation between the network side and the user in the present invention;

FIG. 9 is a schematic diagram of an embodiment of a POC system without negotiation between the network side and the user in the present invention;

FIG. 10 is a schematic diagram of an embodiment of a POC system without negotiation between the network side and the user in the present invention;

FIG. 11 is a schematic diagram of a system according to an embodiment of the present invention.

Detailed ways

The core of the present invention is that during and after the session is established, when the identification provided by the user does not conform to the policy or rules of the network side, the network side can directly assign the identification to the user according to the modification rules, or through the communication between the user and the user. The message interaction carried out can modify the originally set identification in real time, and can also refuse the user to use the identification function in this session.

Specifically, the present invention sets up and revises the process of user identification during session establishment process and after session establishment as follows:

In the process of establishing a session, the user provides an identifier to request to enter an existing session on the network side, and the network side checks the availability of the identifier provided by the user.

If the identifier provided by the user complies with the policies or rules of the network side, the network side allows the user to use the identifier provided by itself to enter the session.

When the identifier provided by the user does not comply with the policies or rules on the network side, the network side can adopt two solutions:

The network side directly modifies the identifier provided by the user to an identifier that conforms to the network-side policy or rules according to the modification rules, and allows the user to use the usable identifier to enter the session, and notifies the user of the modification result of the identifier;

or

The network side refuses the user to use the identity provided by itself to enter the session, and at the same time, the network side recommends to the user an available identity that conforms to the network-side policy and rules according to the modification rules, or the network side sends the user a reason value indicating the user.

or

The network side refuses the user to use the identification function in this session, and in this session, the user's identification is the basic user identification.

When the network side recommends an identity to the user, if the user agrees to use the identity as the user identity, the network side allows the user to use the available identity to enter the session; if the user does not agree to use the identity, the user is required to provide a new identity, and According to the above method, re-check the availability of the new identifier and process it according to the detection result until the user provides a legal identifier or agrees to use the identifier recommended by the network side to enter the session.

When the network side sends the indicated user reason value to the user, the contents of the indicated user reason value include but are not limited to:

Inform the user that the logo is unavailable;

or

inform the user why the logo is unavailable;

or

Reminds the user to provide an ID again.

The unavailable user identity refers to that the network side detects the availability of the identity provided by the user terminal according to the identity availability judgment rule, and if the user identity conflicts with the identity availability judgment rule, the user identity is unavailable. The user identification availability discrimination rules include:

Whether the client provides an identification;

or,

Whether the ID provided by the client conflicts with other user IDs in the service;

or,

Whether the identifier provided by the client complies with the system policy.

After the session is established, the user can modify the currently used ID at any time. When modifying the logo, the user provides a new logo to the network side as the modification logo, and the network side checks the validity of the modification logo provided by the user.

If the modification identifier provided by the user complies with the identifier policy or rule of the network side, the network side allows the user to use the modification identifier to enter the session.

When the modification identifier provided by the user conflicts with the original identifier on the network side, the network side can adopt two solutions, and the specific processing methods are similar to those in the session establishment process:

The network side directly modifies the modification identifier provided by the user into an available identifier that conforms to the network-side policy or rules according to the modification rules, and allows the user to use the usable identifier to enter the session, and at the same time notifies the user of the modification result of the identifier;

or

The network side refuses the user to enter the session using the modified ID provided by itself, and the user continues to use the original ID in the session. User sent indicating user reason value.

or

The network side refuses the user to use the identification function in this session, and in this session, the user's identification is the basic user identification.

When the network side recommends a logo to the user, if the user agrees to use the available logo as the user's new modification logo, the network side allows the user to use the logo in the session; if the user does not agree to use the new logo as the modification logo, the user can Provide a new modified ID at any time during the session, and re-check the new ID according to the above method and process it according to the detection result until the user provides a new legal ID in the session or agrees to use the one recommended by the network side until identified.

When the network side sends the indicated user reason value to the user, the contents of the indicated user reason value include but are not limited to:

Inform the user that the logo is unavailable;

or

inform the user why the logo is unavailable;

or

Reminds the user to provide an ID again.

The method described in the present invention will be further described in detail below in conjunction with the accompanying drawings.

The schematic diagram of terminal user setting identification in the session establishment process of the present invention is shown in Figure 1, and its working process is as follows:

Step 11, the terminal user sends an INVITE message to the server on the network side.

Sessions between various end users in the network are established by the communication server on the network side. The sessions here include but are not limited to Session Initiation Protocol (SIP) sessions, Instant Messaging (IM) sessions, Push to Talk (PoC) sessions, and Conference (Conference) sessions.

End users not participating in a session can either join an already established session or create a new session.

After the terminal user contacts the server on the network side, the server checks whether the user ID complies with the policies or rules on the network side.

The server on the network side checks whether the user ID is legal according to the policy or rules customized by the operator. The legality of content here includes that the user requesting to enter the session has the same ID as the existing user in the session, and the user ID does not comply with the operator's policy. Here, the restriction on the name by the operator's policy may include but not limited to: restriction on the byte range of the user identification, prohibiting the use of some specific characters.

Step 12. If the user has already carried the ID, the communication server on the network side checks the user ID and finds that the ID is illegal. At this time, a new available identifier can be determined after negotiation between the user and the network-side server, or the network-side server can directly assign an available identifier to the user without going through the negotiation process.

121. The negotiation process includes:

1211. The server on the network side sends a 183 message to request the user to carry a new identifier again;

1212. The user carries a new identifier through a provisional confirmation (PRACK) message

If the new identity is checked by the server and found to be in compliance with the policies or rules on the network side, the server accepts the identity as the user identity;

If the new ID is still invalid after being checked by the server, the above process can be repeated until the user provides the server with an available ID that does not conflict.

122. Processes without negotiation include:

1221. The server directly assigns an identifier to the user according to the modification rule, and the identifier is directly carried to the user through a 200 OK message.

1222. The terminal user sends an acknowledgment (ACK) message to the network side server and enters the session.

At this time, the user terminal may not use the identifier assigned by the server, but in this session, the user can only use the identifier assigned by the server.

When the user uses a different ID from the server in the session, the server can directly replace the ID with the ID used in the previous step or reject the user request; the user can be notified of the operation process during the process of replacing the ID and rejecting the user request.

Fig. 2 shows the method for modifying the identity after the calling party enters the session. During the session, the user actively initiates identity modification.

Step 21, the terminal user sends an INVITE to the server on the network side, requesting to enter the session.

Step 22, the network side server sets and modifies the identity for the user according to the identity of the terminal user and sends a 200 OK message to the terminal to notify the terminal user of the setting and modification of the identity.

Step 23, the terminal user sends an ACK message to the network side server and enters the session.

Step 24: When the user enters the session and wishes to modify the ID during the session, the terminal sends an UPDATE message carrying an ID modification request to the server on the network side, and the message may carry the modification ID proposed by the user.

When the modification ID provided by the user conflicts with other user IDs on the network side, a new available ID can be determined after negotiation between the user and the network side server, or the network side server can directly assign an available ID to the user without going through the negotiation process .

After the identity is determined, the user uses the new identity in the session.

Step 25. After determining the new user ID, the network side sends a 200 OK message to the terminal, notifying the user of the currently used new ID.

Fig. 3 shows the method for modifying the identity after the user is called into the session. During the session, the user actively initiates identity modification.

Step 31, the server on the network side sends an INVITE to the user, inviting the user to enter the session.

Step 32. The terminal sends a response message 200 OK to the server on the network side. The response message carries its own identity. The server on the network side judges whether the identity is legal according to relevant policies. If it is legal, the user is allowed to directly enter the session. If it is not legal, no negotiation is required. The user is directly assigned an available ID, which the user uses to enter the session.

Step 33: After the user enters the session, the server on the network side sends an ACK message to the terminal to notify the terminal of the situation.

Step 34: When the user enters the session and wishes to modify the identifier during the session, the terminal sends an UPDATE message carrying an identifier modification request to the server on the network side, and the message may carry the modification identifier proposed by the user.

When the new identity provided by the terminal is legal, the server on the network side changes the identity to the user identity;

When the new ID provided by the terminal is invalid, the server on the network side directly assigns an available ID to the user according to the rules, and changes the ID to a user ID.

Step 35. After the server on the network side has changed the identity for the user, it sends a 200 OK message to the terminal to send the change result to the terminal.

In the following two embodiments, the process of the user setting and modifying the identity for himself is introduced in detail in the present invention with and without the negotiation process:

Fig. 4 shows an embodiment of a POC system of the present invention, which realizes the function that the POC server modifies the user's identity, and then sends the modification result to the user.

In this embodiment, the modification of the user ID by the server includes a negotiation process between the user and the server, and the user performs the negotiation through real-time message interaction. The negotiation process can be carried out during the service establishment process between the user and the server, or can be carried out with the server at any time after the user completes the service.

In this embodiment, the group has been created, the ID of the group is sip:chatroom_tree@network.net, the group type is open, and there is no restriction on the entry of members. There is no special limitation on the group type here, and other types of groups such as closed groups can also be used. It is known that there are two POC terminals, namely:

POC terminal A, its logo and Public Id are: "lemon" <sip: PoC-UserA@networkA.net>

POC terminal B, its logo and Public Id are: "lemon" <sip: PoC-UserB@networkB.net>

If this chat room session has been established, POC terminal A has entered the session and carries out POC communication with the members in the session, then when POC terminal B prepares to enter this chat room, the workflow of the present embodiment is as follows:

Step 41. The user of POC terminal B selects the chat room group ID: sip:chatroom_tree@network.net from the contact list, and initiates a call to the home POC server of POC terminal B through an INVITE message.

Step 42. The home POC server of terminal B assumes the role of PF in this process. After the server passes the corresponding service inspection, it will send an INVITE message to the home POC server of the chat room group.

Step 43: After receiving the INVITE message, the POC server (CF) checks that the chat room group is carrying out a POC session according to the group ID carried in the message. At this time, the POC server (CF) will perform a corresponding response to the POC terminal B. Call conflict check, and send a 183 response to the home POC server of terminal B according to the check result.

Conflict checking and corresponding processing are as follows:

431. If the policy of the POC server determines that in the user plane (User Plane) preemption instruction message, users are only distinguished according to the identifier, that is, the legality check of the identifier includes group members in addition to the legality check of the identifier rule on the network side The following three situations exist in the ID conflict check:

If there is no conflict between the identity provided by user B and the identity of other members in the session, the POC server will use the identity provided by user B in the session by default.

If the identity of user B conflicts with the identity of other users in the session, the POC server will modify the identity of B according to the modification rules, and send the modified identity to B for negotiation.

If user B does not provide an identifier, the POC server will construct an identifier according to the modification rules, and send the constructed identifier to B for negotiation.

432. If the policy of the POC server determines that the user identification and number are used together in the user plane (User Plane) preemption indication message to distinguish users, the preemption indication message is the corresponding message of the POC server's request for the user's preemption, and informs the user whether Get the right to apply.

Then there are the following 3 situations:

4321. If user B hides his number and only has a logo,

When another user A already exists in the session and also hides his number and has the same ID as B, the POC server will modify the ID of B according to the modification rules and send it to B for negotiation.

When there is no member who hides the number and has the same ID in the session, the POC server defaults that B uses the ID provided by itself in the session.

When user B hides his number and does not provide an ID, the POC server assigns an ID to B according to the modification rules and sends it to B for negotiation.

4322. If user B provides its own number and ID, the POC server defaults that B uses the ID provided by itself in the session.

4323. If B brings his own number but no identification, the POC server will assign an identification to B according to relevant rules and send it to B for negotiation.

The modification rules described in the above 3 cases are:

When the user does not provide an ID, the user ID is set in the form of adding additional information after the business information;

When the user provides an ID but the provided ID is not available, the method for setting the user ID is to add additional information after the user-provided ID.

The service information includes but not limited to service name, service group identifier, service provider information, service description information; the additional information includes but not limited to part or all of user identification information, user affiliation information, user subscription information, user Category information, random information.

For example, if the POC server needs to modify the identity "lemon" of user B, at this time, the identity of POC terminal B can be changed to "lemon_1" according to certain rules, and a temporary response (for example: 183) is sent to POC terminal B for confirmation. The server will record User B's new identity. When modifying the identifier, the SIP header field can be used to carry in the Uri, including carrying through SDP, and also including carrying through XML.

Step 44: After receiving the 183 response, the home POC server of terminal B forwards the message to POC terminal B for identity negotiation.

Step 45: After receiving the 183 response, the POC terminal B negotiates the identity, stores the negotiation result in a PRACK message and sends it to terminal B's home POC server (PF).

The following example illustrates the negotiation process of terminal B on the identity.

When terminal B learns that its identity has been changed to "lemon_1", the terminal will ask POC user B to accept the identity or provide a new identity. If the POC terminal B chooses to accept, the identifier carried in the PRACK message is "lemon_1". If the POC terminal B chooses to re-enter an identifier, such as "flower", then the "flower" identifier is carried in the PRACK message. Subsequent POC server checks that there is still a conflict, and the POC server will modify and negotiate again according to the rules.

Step 46: After receiving the PRACK message, the home POC server (PF) of the POC terminal B forwards the PRACK message to the POC server (CF). After the POC server (CF) receives the PRACK message, it checks and checks the identity just modified. There are two situations:

If the identifier carried in the message is the same as the identifier saved by the POC server, a 200 OK will be returned to the POC terminal B.

If the identifier carried in the message is different from the identifier saved by the POC server, the strategy according to step 3 will be checked. If there is no conflict, 200 OK will be returned to POC terminal B. If there is still a conflict, the POC server will modify its identifier according to the modification rules and Continue to initiate the negotiation process until the negotiation is successful.

Steps 47 and 48, since the POC server (CF) checks that the identifier of POC terminal B still conflicts with the session members, at this time the POC server (PF) will reassign an identifier according to the relevant policy, and send it to the POC again through a 183 response Terminal B. The subsequent negotiation process is as described above.

Steps 49 and 410, after the CF passes the identity check, it is determined that the identity re-modified by the POC terminal B does not conflict with the member identity in the session, and will return a 200 OK message to the POC terminal B.

In steps 411 and 412, the POC terminal B sends an ACK message to the POC server (PF, CF), thereby entering the group session.

Fig. 5 shows another POC system embodiment of the present invention.

This embodiment is used to describe the process of how the user sets an ID to enter the session and initiates ID modification freely and at any time in the session without a negotiation process when the group session has been established.

The POC server (CF) assigns an identity to the user temporarily without negotiating with the user when the user identity conflicts according to the modification rules and continues to connect the call. After the user enters the session, if he wants to change the ID, he will send a new modification ID to the POC server through a message (for example: reINVITE, UPDATE).

If the POC server detects that the new modification ID does not conflict with other user IDs, the server accepts the ID as the user's new ID.

If the POC server detects that the new modification ID conflicts with other user IDs, it will assign an ID to the user again, and notify the user through a final response message, and the user will use the reassigned ID in the session. If the POC user wants to change the logo, he can re-initiate the modification.

Step 51, the user of POC terminal B selects a chat room group ID from the contact list, and initiates a call to the home POC server of POC terminal B.

Step 52: After the home POC server of terminal B (acting as the PF role in this process) passes the corresponding service check, it will send an INVITE message to the home POC server of the chat room group.

Steps 53 and 54, the POC server (CF) checks whether the identification of the POC terminal B conflicts, if the POC terminal B needs to change the identification due to the conflict, the POC server (CF) will temporarily assign an identification to it according to the modification rules, and pass 200 The OK message is brought to POC terminal B.

Steps 55 and 56, after receiving the 200 OK message, the POC terminal B immediately sends an ACK message to the POC server to enter the session.

Steps 57 and 58, if the POC terminal B user wants to change an ID, the new modification ID will be sent to the POC server through terminal operation, and the modification ID can be carried by a SIP message (for example: reINVITE, UPDATE). The modification identifier can be carried in the Uri of the user in the SIP header field, and can be carried through SDP or XML.

Steps 59 and 510, after the POC server receives the SIP (for example: UPDATE) message that carries the new modification identifier, it is confirmed that the POC terminal user B wishes to change the identifier, and now the POC server will check the legality of the identifier according to its policy.

If the identity does not conflict, accept its identity modification, and send 200 OK to POC terminal B.

If the identifier conflicts, an identifier will be re-assigned to POC terminal B according to the rules, and the temporary assigned identifier will be brought to POC terminal B through 200 OK message. The user uses the newly assigned identifier in the session and can initiate a new modification at any time.

FIG. 6 shows an embodiment of a POC system without negotiation between the network side and the user in the present invention.

This embodiment is used to describe a process in which a user initiates identity modification freely and at any time without negotiating with the network side.

The difference between this and the previous embodiment shown in Figure 5 is that the POC server invites the POC terminal B to enter the session, and the terminal B carries its own identification in the response message, and the POC server (CF) judges whether the identification is available according to relevant policies . When the user ID is available, the user uses the ID to enter the service; when the user ID is not available, the POC server temporarily assigns an ID to the user and continues the call. The process of POC server assigning an ID to the user does not include the negotiation process.

If the user wants to change the ID after entering the session, he can negotiate with the POC server to update it through messages (for example: reINVITE, UPDATE). If the POC server detects that the ID conflicts with other users, it will temporarily assign an ID to the user. Brought back by the final response message.

If the POC user wants to change the logo, he can re-initiate the modification.

Step 61: After receiving a call initiated by a POC calling terminal, the POC server (CF) will invite the called POC terminal B to enter the session. At this time, the POC server (CF) will send an INVITE message to the home server of the POC terminal B.

Step 62: After the home POC server of terminal B (assuming the role of PF in this process) passes the corresponding service inspection, it will send an INVITE message to POC terminal B.

Steps 63 and 64, POC terminal B will send 200 OK to the POC server (CF) through the POC server (PF), and the identification of POC terminal B is carried in the message.

Steps 65 and 66, the POC server (CF) checks the identity of the POC terminal B according to the policy. If the identity of the POC terminal B needs to be changed, the POC server (CF) will temporarily assign an identity to it at this time, and pass the ACK message with To POC terminal B.

Steps 67 and 68, if the POC terminal B user wants to change an identifier, the new identifier will be sent to the POC server through terminal operation, which can be carried by reINVITE and UPDATESIP messages. The modified identifier can be carried in the Uri of the user in the header field of SIP, can be carried through SDP, and can also be carried through XML.

Steps 69 and 610, after receiving the UPDATE message, the POC server confirms that the user of POC terminal B wants to change the ID. At this time, the POC server will check the legality of the ID according to its policy. If the ID is legal, it will accept the modification of the ID and give the POC Terminal B returns 200 OK. If the identifier is illegal, it will re-allocate an identifier for the POC terminal B according to the rules, and bring the temporarily assigned identifier to the POC terminal B through the 200 OK message.

FIG. 7 shows another embodiment of the POC system in which no negotiation is performed between the network side and the user in the present invention.

Step 710, terminal B includes its own identity in the session request message.

In step 720, the CF checks the validity of the nickname, and if there is a conflict, the function of using the nickname of the current user in this session is not accepted, but the session is established normally. The user is identified by the original SIP URI or TelURI.

FIG. 8 shows another embodiment of the POC system in which no negotiation is performed between the network side and the user in the present invention.

Step 810, terminal B includes its own identity in the session request message.

In step 820, the CF checks the validity of the nickname, and if there is a conflict. The user's current session request is rejected.

The above embodiments only describe the situation where the session request is initiated by the client, and the situation where the session invitation is initiated by the server is similar. The difference is that in the case of a session invitation initiated by the server, the client's nickname identifier is carried by the client's 200 ok response message to the session invitation.

FIG. 9 shows another embodiment of the POC system in which no negotiation is performed between the network side and the user in the present invention.

Through steps 910 and 920, the session is established successfully.

Step 930, the client updates its own identification information through an update message, for example carrying nickname information.

In step 940, the CF checks the validity of the nickname, and if there is a conflict, the function of using the nickname of the current user in this session is not accepted, but the session proceeds normally. The user is identified by the original SIP URI or TelURI.

Fig. 10 shows another embodiment of the POC system in which no negotiation is performed between the network side and the user in the present invention.

Through steps 1010 and 1020, the session is established successfully.

Step 1030, the client updates its own identification information through an update message, for example carrying nickname information.

Step 1040, the CF checks the validity of the nickname, and if there is a conflict. Reject the client's update request and issue a Bye message to end the current session.

The carrying of the client ID in the present invention includes but is not limited to using one of the following methods:

Ported using the user's Uniform Resource Identifier;

or,

Carried by the session description protocol body;

or,

Portable via Extensible Markup Language;

or

Carried in the SIP message header.

In the negotiation process of the present invention, the negotiation information can be carried by various information such as UPDATE message, 183 message, SIP information header, and the negotiation information carried by a certain message can also be carried by other messages. The situation shown is only a specific situation of the present invention, but not limited to this kind of situation.

Fig. 11 is a schematic diagram of the system of the present invention.

The overall flow of the system as shown in Figure 7 is as follows:

During the session establishment process, the user requests to enter the network-side session, and the identification management initiation module of the terminal sends a message carrying user identification information to the identification management module of the network side,

When there is no negotiation process in the system,

If the identifier provided by the user does not conflict with the identifier of the user in the session on the network side, the identifier management module on the network side directly sets the identifier as the user identifier;

If the ID provided by the user conflicts with the user ID in the session on the network side, the ID management module on the network side directly sets an ID for the user according to the modification rules, and notifies the terminal of the modified ID name by sending a message.

When there is a negotiation process in the system,

If the identifier provided by the user does not conflict with the identifier of the user in the session on the network side, the identifier management module on the network side directly sets the identifier as the user identifier;

If the identifier provided by the user conflicts with the identifier of the user in the session on the network side, the negotiation module between the network side and the terminal will negotiate, and the specific process is as follows:

When the network side detects a user ID conflict, it modifies the user ID according to the modification rules, the negotiation module transmits the modification result to the end user, and the user judges whether to accept the ID recommended by the network side, and if accepted, sends a confirmation message to the network side, If you do not accept it, you can re-enter a new ID for yourself, and perform conflict detection again until you get a non-conflicting ID, and set it as the user ID.

During the session establishment process, if the user needs to modify the currently used identity, the identity management initiation module of the terminal sends a message carrying the user's new identity to the identity management module on the network side,

When there is no negotiation process in the system,

If the new identification provided by the user does not conflict with the user identification in the session on the network side, the identification management module on the network side directly modifies the new identification to the user identification;

If the new ID provided by the user conflicts with the user ID in the session on the network side, the ID management module on the network side directly modifies an ID for the user according to the modification rules, and sends a message to notify the terminal of the modified ID name, and the user uses it in the session. The identifier assigned by the network side conducts the session.

When there is a negotiation process in the system,

If the identification provided by the user does not conflict with the user identification in the session on the network side, the identification management module on the network side directly modifies the new identification to the user identification;

If the new identifier provided by the user conflicts with the identifier of the user in the session on the network side, the negotiation module between the network side and the terminal will negotiate, and the specific process is as follows:

When the network side detects that the user’s new ID conflicts, it will modify the new ID provided by the user according to the modification rules, and the negotiation module will send the modification result to the end user, and the user will judge whether to accept the ID recommended by the network side. Confirm the information, and use the recommended logo in the session. If you do not accept it, you can re-enter a new modification logo for yourself, and re-check the conflict until you get a non-conflicting modification logo, and modify it to the user's new logo.

The above is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed in the present invention can easily think of changes or Replacement should be covered within the scope of protection of the present invention. Therefore, the protection scope of the present invention should be determined by the protection scope of the claims.

Claims (23)

1, a kind of implementation method of the management of subscriber sign based on Session Initiation Protocol is characterized in that, comprising:

A, carry sign and identify availablely in the message that user side sends, this sign of network side is set to user ID;

B, in the message that user side sends, do not carry sign or the sign of carrying unavailable, this is identified at use in this session network side restricts.

2, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1 is characterized in that described user ID is included in the pet name of using in the Session Initiation Protocol, also is included in any sign in the non-signatory mark in using in the business.

3, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1, it is characterized in that, carry user totem information in the service request that user side sends, network side detects the availability of sign that user side provides according to sign availability decision rule.

4, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 3 is characterized in that described user ID availability decision rule includes but not limited to:

Whether user side provides sign;

Or,

Whether the sign that user side provides conflicts with other user ID in the business;

Or,

Whether the sign that user side provides the strategy regulation of compliance with system.

5, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 4 is characterized in that, described strategy regulation includes but not limited to forbid words, the symbol of appointment, and the allowed band of sign length is set.

6, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1 is characterized in that, this is identified at use in this session network side restricts, and unavailable when the sign that user side provides, then the method for Biao Shi setting comprises:

Network side is reset sign through consulting for user side.

7, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1 is characterized in that, this is identified at use in this session network side restricts, and unavailable when the sign that user side provides, then the method for Biao Shi setting comprises:

Network side is without consulting directly to reset sign for user side.

8, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1 is characterized in that, this is identified at use in this session network side restricts, and unavailable when the sign that user side provides, then the method for Biao Shi setting comprises:

Network side adopts such processing method: the user can not use this identification function in this session, session is normally set up or normally carried out.

9, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1 is characterized in that, this is identified at use in this session network side restricts, and unavailable when the sign that user side provides, then the method for Biao Shi setting comprises:

Network side is refused this user's message request and/or stops the user to participate in this session.

10, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 6 is characterized in that unavailable when the sign that user side provides, described negotiations process comprises:

Network side is that user side is provided with a sign, user side judges whether to accept this sign, if accept, then user side uses this sign, if do not accept, then user side provides a new sign and network side to continue to consult to network side again, until obtain that a user side is accepted and available sign till.

According to the implementation method of each described a kind of management of subscriber sign based on Session Initiation Protocol in the claim 6 to 9, it is characterized in that 11, network side is that the method that user side is reset sign is,

When user side does not provide sign, user ID is set to add after the business information form of additional information;

Provide sign when user side but identify when unavailable, after the sign that user side provides, add additional information.

12, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 11 is characterized in that described business information includes but not limited to Business Name, service group's sign, service provider's information, business description information; Described additional information include but not limited to user totem information partly or entirely, user attaching information, user signing contract information, user category information, random information.

13, according to claim 1, this method of using that is identified in this session of network side restricts also comprises the indication user cause value that network side sends as user side.

14, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 13 is characterized in that, unavailable when the sign that user side provides, network side is that the content of the indication user cause value that sends of user side includes but not limited to:

The announcement user should identify unavailable;

Or

The announcement user should identify disabled reason;

Or

Remind the user that a sign is provided again;

Or

Remind the user in this session, can not use identification function.

15, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1 is characterized in that, user side can be made amendment to the sign of using in business is carried out at any time.

16, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1, it is characterized in that the system that implementation method was suitable for of described management of subscriber sign includes but not limited to all systems based on professional initiation protocol entity exchange.

17, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1 is characterized in that, creates a database that is used to preserve the sign that bans use of at network side.

18, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 17, it is characterized in that, if the identification collision that bans use of in user ID and the database, network side will be that user side is reset a sign according to the sign method to set up.

19, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1 is characterized in that the method for carrying of described sign includes but not limited to use following method:

Use user's unified resource identifier to carry;

Or,

Carry by the Session Description Protocol body;

Or,

Carry by extend markup language;

Or

Carry by the sip message head.

20, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1, its feature also comprises:

Network side sends message to user side, the user ID restriction that the indication network side is done.

21, a kind of system of the management of subscriber sign based on Session Initiation Protocol is characterized in that,

Comprise at network side,

The identity management module, what be used for user side is provided knows the sign that clashes with session acceptance of the bid and makes amendment, is provided with;

Negotiation module, it is distolateral to be used for that the identity management module is sent to the user to the modification of conflict sign;

Comprise in that the user is distolateral,

The identity management initiation module is used for sending sign setting, revising request to network side, and user ID is provided.

22, the system of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 21, it is characterized in that, in network side and user side, be equipped with negotiation module, it is distolateral that the network side negotiation module is used for that the identity management module is sent to the user to the modification of conflict sign, and it is the sign that user side is revised that the negotiation module of user side is used to judge whether to accept network side.

23, the implementation method of a kind of management of subscriber sign based on Session Initiation Protocol according to claim 1, its feature also comprises:

Network side sends message to user side, the user ID restriction that the indication network side is done.

Images