CN101645825B - Method, system and SIP entity for overload processing - Google Patents

Method, system and SIP entity for overload processing Download PDF

Info

Publication number
CN101645825B
CN101645825B CN200810117741A CN200810117741A CN101645825B CN 101645825 B CN101645825 B CN 101645825B CN 200810117741 A CN200810117741 A CN 200810117741A CN 200810117741 A CN200810117741 A CN 200810117741A CN 101645825 B CN101645825 B CN 101645825B
Authority
CN
China
Prior art keywords
load head
overload
entity
response message
request
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN200810117741A
Other languages
Chinese (zh)
Other versions
CN101645825A (en
Inventor
乌梅什
甘尼夏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Gaohang Intellectual Property Operation Co ltd
Taizhou Haitong Asset Management Co ltd
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 CN200810117741A priority Critical patent/CN101645825B/en
Publication of CN101645825A publication Critical patent/CN101645825A/en
Application granted granted Critical
Publication of CN101645825B publication Critical patent/CN101645825B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

The invention relates to a method, a system and an SIP entity for overload processing. The overload processing method comprises the following steps that: a requesting party sends a request message carrying a load head to a receiving party by or not by a middle entity; and the middle entity and/or the receiving party can feed a response message carrying the load head back to the requesting party by analyzing the requested load head, so that the requesting party can determine the overloaded entity by analyzing and computing the load head and reduce request messages to be sent. The system comprises the SIP entity of the requesting party and the SIP entity of the receiving party. The method, the system and the SIP entity for overload processing indicate the overloaded entity and the sending quantity of the messages to be reduced by adding load heads in the request message and the response message, realizes the effective overload detection without increasing system load, and is flexible, simple and effective in overload detection.

Description

The SIP entity that overload processing method and system, overload are handled
Technical field
The present invention relates to the mobile communication technology field, particularly a kind ofly transship the SIP entity that processing method and system, overload handle.
Background technology
In communication network, overload control is one of important call treatment controlling mechanism, especially single server handle the call business in the whole nation next generation network (Next Generation Network, hereinafter to be referred as: all the more so NGN).Session initiation protocol (Session Initiation Protocol, hereinafter to be referred as: be in the business of interaction protocol SIP), overload detection and processing exist only in application layer.
In overload control, one is overload detection than being easier to unheeded aspect.Overload detection is based on generally that making of system resource be used for carrying out, and system resource also comprises memory source, file handle, disk I etc. except comprising cpu resource, but generally detect as overload condition with CPU.The situation that takies of system resource can from external observation to.But at the server of operation higher priority or because other certain situation, possible overload detection also can be used other some resources, and is also very important but be not easy to be detected based on the overload condition of these resources; For example, fixedly created 100 threads during program start and be used for handling the thread of calling out thread pool, if these 100 threads are all being handled calling; Just new calling can not have been handled; But taking of this thread resources is to be difficult to from visual observation, promptly from the situation that takies of cpu resource, possibly be not transship; But in fact owing to thread not enough (thread starvations), system transships.
The method that also exists overload to handle in the prior art, and defined overload controlling mechanism at protocol layer.Can use SIP to carry out under the situation of session control; At transmission control protocol (Transfer ControlProtocol; Hereinafter to be referred as: TCP) or UDP (User Datagram Protocol, hereinafter to be referred as: UDP) using down should overload controlling mechanism.Generally this controlling mechanism is more useful in UDP.
At present, overload control is based on that CPU uses, thread uses and overload detection is carried out in the use of other system resource.Usually, accomplish this overload detection through moving an additional programs and circulative metabolism.
Modal method to overload condition is made a response is as shown in Figure 1, and concrete realization is: carry out another one program D, this program D and the B that acts on behalf of of supposition overload move in same system.Program D regularly (as per 1 minute) detects the CPU usage of once acting on behalf of B, supposes that the CPU usage of acting on behalf of B surpasses certain overload threshold value that is provided with in advance, thinks that then acting on behalf of B has transshipped, and transships to acting on behalf of B notification agent B; Act on behalf of B through obtaining (Service Unavailable) 101 and come responds SIP client sent request (Invite) to acting on behalf of the A business of sending.But iff is like this, should can not learn the SIP entity through acting on behalf of the SIP client that A sends request, as act on behalf of B, and the amount of information of overload is what, can not learn that it need reduce how many request messages of transmission and just can solve overload.
As stated, utilize additional programs to carry out the method for overload detection, its accuracy is lower: for example, the overload threshold value and the comparison procedure of setting possibly be actually overhead for network entity and sip server.Again for example, because the limitation of the overload condition of these program settings, they possibly not respond these entities (network entity and sip server etc.).
Summary of the invention
The embodiment of the invention provides a kind of SIP entity that processing method and system, overload handle that transships, and to be implemented under the situation that does not increase the extra system load, improves the accuracy of detection of the entity of overload.
The embodiment of the invention provides a kind of overload processing method, comprising:
The requesting party sends the request message that carries request load head to the recipient, and described request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least, and the repeating transmission coefficient of described request message is used for the number of re-transmission of the request message of definite each determined number;
Receive the response message that carries the responsive load head that said recipient returns, determine whether to exist the overload entity, wherein said responsive load head comprises the repeating transmission number of times of request message, the repeating transmission number of times and the overload entity identification of response message; Perhaps; Receive the response message that does not carry the responsive load head that said recipient returns; Judge whether the repeating transmission coefficient in the described request load head has surpassed the optimization repeating transmission coefficient that described request side itself has; If described request side reduces the quantity forwarded of request message, retransmit coefficient up to obtaining said optimization.
The embodiment of the invention also provides a kind of session initiation protocol entity of handling that transships, and comprising:
Ask load head structure module, be used for structure request load head, described request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least, and the repeating transmission coefficient of described request message is used for the number of re-transmission of the request message of definite each determined number;
First sending module, be used to send carry request load head request message to recipient's session initiation protocol SIP entity;
First receiver module is used to receive the response message that carries the responsive load head that said recipient SIP entity returns, or the response message that does not carry the responsive load head that returns;
Judge module, be used for when said first receiver module receive that said recipient SIP entity returns carry the response message of responsive load head the time, determine whether to exist the overload entity; When said first receiver module receive that said recipient SIP entity returns do not carry the response message of responsive load head the time judge whether repeating transmission coefficient in the described request load head has surpassed the optimization that described request side itself has and retransmitted coefficient; If; Described request side reduces the quantity forwarded of request message, retransmits coefficient up to obtaining said optimization.
The embodiment of the invention also provides a kind of session initiation protocol entity of handling that transships, and comprising:
Second receiver module; Be used to receive the request message of asking the load head that carries of requesting party's transmission; Described request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least, and the repeating transmission coefficient of described request message is used for the number of re-transmission of the request message of definite each determined number;
Responsive load head structure module is used for tectonic response load head, and said responsive load head comprises the repeating transmission number of times of request message, the repeating transmission number of times and the overload entity identification of response message at least;
Second sending module is used to send the response message that carries the responsive load head, or does not carry the response message of responsive load head.
The embodiment of the invention provides a kind of overload treatment system again, comprising:
Requesting party's session initiation protocol SIP entity is used to send the request message that carries request load head, and according to the response message that receives, determines whether to exist the overload entity; Comprise: ask load head structure module, be used for structure request load head, described request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least, and the repeating transmission coefficient of described request message is used for the number of re-transmission of the request message of definite each determined number; First sending module, be used to send carry request load head request message to recipient's session initiation protocol SIP entity; First receiver module is used to receive the response message that carries the responsive load head that said recipient SIP entity returns, or the response message that does not carry the responsive load head that returns; Judge module, be used for when said first receiver module receive that said recipient SIP entity returns carry the response message of responsive load head the time, determine whether to exist the overload entity; When said first receiver module receive that said recipient SIP entity returns do not carry the response message of responsive load head the time judge whether repeating transmission coefficient in the described request load head has surpassed the optimization that described request side itself has and retransmitted coefficient; If; Described request side reduces the quantity forwarded of request message, retransmits coefficient up to obtaining said optimization;
Recipient SIP entity; Be used to receive the request message that SIP entity in described request side sends; And return the response message that carries the responsive load head; Or not carrying the response message of responsive load head, said responsive load head comprises the repeating transmission number of times of request message, the repeating transmission number of times and the overload entity identification of response message.
Can know by above technical scheme; The SIP entity that the overload processing method of the embodiment of the invention and system, overload are handled; Under multiple combination of entities mode, through in request message and response message, adding load head, the quantity forwarded of indicating the overload entity and hoping the information of minimizing; In conjunction with the mechanism of describing, the user agent can learn whether himself transships, or whether other intermediate entities transship; Realized when carrying out effective overload detection, not increasing the load of system, made that the overload detection flexibility is strong, and effectively simple.
Below through specific embodiment and combine accompanying drawing that the present invention is done further detailed description.
Description of drawings
Fig. 1 is the functional entity structural representation of prior art overload processing method;
Fig. 2 is a SIP network architecture sketch map;
Fig. 3 is that the schematic flow sheet of processing method embodiment is transshipped in a present invention;
Fig. 4 transships the functional entity structural representation of processing method embodiment for another the present invention;
Fig. 5 transships the schematic flow sheet of processing method embodiment for another the present invention;
Fig. 6 transships the functional entity structural representation of processing method embodiment for another the present invention;
Fig. 7 transships the structural representation of the SIP physical embodiment handled for the present invention;
Fig. 8 transships the structural representation of treatment system embodiment for the present invention.
Embodiment
In network architecture, the requests/response messages that the entity handles in the system receives needs resource, and its system overload often is meant that current resource can not or be not enough to supply with the request that receives with processing or the situation of response message; Can not treatment S IP request or response the time when the functional entity in the SIP network, overload also can occur in the SIP network.
Overload mainly contains two types: the one, and server overload, the message that can not handle its reception owing to server is transshipped, and perhaps just is being busy with other processing procedure and can not receiving message owing to server, thereby causing overload; The 2nd, network over loading, because the network bandwidth is not enough, can not processing messages; For example; If network bandwidth 256Kbps, but in fact need 2Mbps, in this network, can abandon the great deal of information bag so; The RTP that sip message in this and the SIP session and being similar to is produced by functional entity (Real-time Transport Protocol, hereinafter to be referred as: RTP) message is relevant.
In the SIP network system as shown in Figure 2, the major function entity comprises: sip server, user terminal, aaa server, NM server, application server, name server and media server etc.Virtual network operator can be runed needs according to reality, selects suitable functional entity that business such as voice and video are provided to the user.(1) sip server (SIP Server): the network equipment of providing in the SIP network and call out control, calling out functions such as route, user management.(2) user agent (User Agent): comprise User Agent Client (User Agent Client; Hereinafter to be referred as: UAC) and subscriber proxy server (User Agent Server; Hereinafter to be referred as: UAS) two parts; UAC is used for initiation request, and UAS then is used for response request, and the user agent can realize on entities such as SIP voice terminal, SIP video terminal and SIPIAD.(3) flexible exchanging network: by Softswitch accomplish intra domain user registration, call out the network of functions such as control, route, authentication and accounting.
Among the embodiment, use the repeating transmission/overtime overload detection of carrying out of the requests/response messages of SIP.The embodiment of the invention is mainly considered two kinds of message retransmission types, the i.e. repeating transmission of the repeating transmission of request message and response message.
Concrete, the method that this overload is handled is summarized has two kinds of situations: the one, the user agent (UserAgent, hereinafter to be referred as: UA) be sent to perhaps other UA of particular network with what request message and response message repeated, and with a large amount of overtime; In this case, possibly be the network entity overload, also can be the UA overload at terminal, can also be the middle-agent is transshipped; This situation can solve the problem of system overload through the quantity that minimizing is sent to the request message of UAS.
The 2nd, UA receives a large amount of re-transmission request message and response message from particular network or other UA; In this case, be UA self overload; Can one coefficient of diminution (reducing factor) be sent to UAC through UAS, come requirement UAC to reduce the quantity of the request message of its transmission, UAS helps UAC under overload conditions, to recover in this case, and UAC also can refuse to come from the request of UAS.
How to adopt this dual mode to carry out overload detection through the detailed introduction of concrete embodiment below.In the concrete example, detect overload by in the header of the request message of SIP and response message, adding the load head, and solve the problem of system overload through this load head.
At first explain the implication of each parameter of the new load head that in header, adds, the definition of this header is following:
load:NOR=DIGIT;RETRANS=DIGIT;O=(name-addr/addr-spec);FAC=(″.″*DIGIT);RETFAC=(″.″*DIGIT);FACID=n
name-addr =[display-name]LAQUOT?addr-spec?RAQUOT
addr-spec =SIP-URI/SIPS-URI/absoluteURI
display-name?=*(token?LWS)/quoted-string
SIP-URI =″sip:″[userinfo]hostport
uri-parameters[headers]
SIPS-URI =″sips:″[userinfo]hostport
uri-parameters[headers]
host?port =host[″:″port]
host =hostname/IPv4address/IPv6reference
hostname =*(domainlabel″.″)toplabel[″.″]
domainlabel =alphanum
/alphanum*(alphanum/″-″)alphanum
toplabel =ALPHA/ALPHA*(alphanum/″-″)alphanum
IPv4address =1*3DIGIT″.″1*3DIGIT″.″1*3DIGIT″.″1*3DIGIT
IPv6reference =″[″IPv6address″]″
IPv6address =hexpart[″:″IPv4address]
hexpart =hexseq/hexseq″::″[hexseq]/″::″[hexseq]
hexseq =hex4*(″:″hex4)
hex4 =1*4HEXDIG
port =1*DIGIT
alphanum=ALPHA/DIGIT
" load:NOR=DIGIT wherein; RETRANS=DIGIT; O=(name-addr/addr-spec); FAC=(". " * DIGIT); RETFAC=(". " * DIGIT); FACID=n ", be the load head, each parameter interpretation is following:
1, retransmits number of times (Number of Times Retransmitted is called for short NOR)
Be used to inform the number of times of recipient's request message repeating transmission.When UAS responded, UAS should indicate this value and send to UAC, and it is the n time repeating transmission that is used for response request message.When mutual for the first time, the initial value of NOR is 0, i.e. NOR=0 with specific UA.
2, (Response Retransmission is called for short RETRANS) retransmitted in response
Be used to the number of times of informing that recipient's response message has been retransmitted.
3, reduce coefficient (Reducing Factor is called for short FAC)
Request message after the minimizing that this coefficient sends for other participants of overload entity expectation.For example, if this coefficient is 0.9, UAS requires UAC to reduce the request message that UAC sends with 0.9 multiplier so, in other words, UAC should only send this plan send to UAS request 90%.For example, if UAC sends 100 request/s, then it should reduce to 90 request/s.
4, parameter identifier (Factor Identifier is called for short FACID)
This is an identifier that constantly increases, and it always is added in the load head with FAC.Increase progressively if this value in the current message is compared with FACID in preceding message, the FAC in the so current message will be employed, and promptly reduce request; Otherwise the FAC in the current message is not used, the FAC that still takes in preceding message.If promptly this FACID changes, then explanation should be adopted new FAC; If FACID is constant, then explanation FAC at this moment need not be used, the FAC before also continuing to adopt.
5, retransmit coefficient (Retransmission Factor is called for short RETFAC)
By this coefficient, UA can confirm the number of re-transmission in every certain amount of message.This some can be any natural numbers such as 100,1000,2000,10000.To confirm that the number of re-transmission in per 1000 message is an example:
RETFAC=(NOR in 1000 message before)/1000, wherein NOR should comprise the retransmission count that responds and ask both.
Further, RETFAC=(the maximum NOR of the 1000th message of maximum NOR+...+ of the 2nd message of maximum NOR+ of the 1st message)/1000.For example: in 1000 message before, the NOR=5 of the 5th message, the NOR=2 of the 7th message, the NOR=0 of other message, RETFAC=0.007 so.
If this coefficient is sent by UAS, it is that coefficient is retransmitted in response so; If this coefficient is sent by UAC, then be the request repeat coefficient.If same server serves as UAS and UAC simultaneously; The other server that it is connected to also serves as the entity of UAS and UAC simultaneously, and when sending a request message, this coefficient only is used for the calculating of request message so; And when sending response message, this coefficient only is used for the calculating of response message.
6, overload entity (Overloaded Entity is called for short O)
The overload entity should have this parameter O in the header of response message, will show overload identity of entity sign among this parameter O.This parameter O is essential, because in transmission process, if there is the functional entity of a lot of SIP network systems all possibly relate to overload, can find the entity of overload so through the identify label among this parameter O.
For example: load:NOR=0; RETRANS=5; O=200.10.5.6; FAC=0.9; RETFAC=0.07; FACID=10.Wherein, the repeating transmission times N OR of request message is 0 time, and the repeating transmission number of times RETRANS of response message is 5 times, and the overload identity of entity is designated 200.10.5.6, and the minimizing coefficient FAC of request is 0.9, and retransmitting coefficients R ETFAC is 0.07.
As shown in Figure 3, be that the schematic flow sheet of processing method embodiment is transshipped in a present invention, comprise the steps:
Step 301, requesting party send the request message that carries request load head to the recipient, and this request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least;
The response message that carries the responsive load head that step 302, reception recipient return, this responsive load head comprise the repeating transmission number of times of request message, the repeating transmission number of times and the overload entity identification of response message at least; Perhaps, the response message that does not carry the responsive load head that returns;
Step 303, determine whether to exist the overload entity.
Concrete, the requesting party can be through each parameter in the analysis request load head and each parameter in the responsive load head, and which entity overload draws specifically is, and the quantity forwarded and concrete what request messages that reduce that whether will reduce request message.
The overload controlling mechanism that present embodiment is described can realize overload detection timely and effectively through in request message and response message, adding the load head, to be implemented under the situation that does not increase the extra system load, to possibly detecting of entity overload.
Step 203 in above-mentioned overload processing method embodiment, the requesting party following several kinds of concrete situation may occur through analyzing:
After situation one, requesting party receive response message, determine whether to exist the overload entity to be: after the requesting party receives the response message that does not carry the responsive load head,, to confirm whether the recipient transships through to retransmitting the analysis of coefficients R ETFAC.Be that requesting party itself has its optimized RETFAC, if this value in its request load head has surpassed the optimum value of RETFAC, the requesting party just should attempt reducing the quantity forwarded of request message, up to obtaining optimized RETFAC.
After situation two, requesting party receive response message; Determine whether to exist the overload entity to be: after the requesting party receives the response message that has the responsive load head; Obtain overload entity identification O, this overload entity identification is recipient's identify label, confirms that then the recipient is the overload entity.In this responsive load head, can also comprise and reduce coefficient FAC and parameter identifier FACID; After then the requesting party receives the response message that has the responsive load head; Also obtain the minimizing coefficient, and reduce the request message that the requesting party is sent to the recipient according to reducing coefficient.Wherein parameter identifier FACID is as the sign that reduces coefficient; Be the minimizing coefficient FAC that whether uses in this responsive load head in order to explain; With comparing in the responsive load head of this parameter identifier FACID and last response message; If it is bigger than the value of the FACID of the responsive load head of previous response message also not occur the value of this parameter identifier FACID or current parameter identifier FACID in the response message of front, then use minimizing coefficient FAC in the current responsive load head to reduce the request message that the requesting party is sent to the recipient; If the value of current parameter identifier FACID unlike the value of the FACID of the responsive load head of previous response message, does not then use the minimizing coefficient FAC in the current responsive load head to reduce the request message that the requesting party is sent to the recipient.
After situation three, requesting party receive response message; Determine whether to exist the overload entity to be: if the requesting party receives a plurality of response messages continuously; Each response message all has the responsive load head; And include the overload entity identification in this responsive load head and reduce coefficient, parameter identifier, then the requesting party need confirm the minimizing coefficient that will use through comparing each parameter identifier FACID.For example: the requesting party has received continuously successively three response messages, and the responsive load of first response message 1 comprises FAC=0.9, FACID=10; The responsive load of second response message 2 comprises FAC=0.85, FACID=10; The responsive load of the 3rd response message 3 comprises FAC=0.7, FACID=11.The requesting party receives first response message, with using the FAC=0.9 in the responsive load 1 to reduce the request message that sends; When receiving second response message again; The value of FACID in the value of FACID in its responsive load 2 and the responsive load 1 is compared; Find to equate, then do not use this moment FAC=0.85 to reduce the quantity of the request message that sends, still with before the quantity that reduces to send a request message; When the requesting party receives the 3rd response message once more; The value of FACID in the value of FACID in its responsive load 3 and the responsive load 2 is compared; The value of the FACI D of discovery before comparing has increased progressively, and should use this moment FAC=0.7 in the responsive load 3 to reduce the quantity of the request message of transmission so.
After situation four, requesting party receive response message; Determine whether to exist the overload entity to be: after the requesting party receives the response message that has the responsive load head; Obtain the overload entity identification, this overload entity identification is empty, and does not detect the minimizing coefficient; Confirm that then the recipient is not the overload entity, and according to before the quantity continuation that sends a request message send a request message to the recipient.
After situation five, requesting party receive response message; Determine whether to exist the overload entity to be: after the requesting party receives the response message that has the responsive load head; Analyzing responding load head according to overload entity identification wherein and the numerical value that reduces coefficient, judges whether himself transships.Concrete; If the responsive load head in the response message that the requesting party receives does not transship entity identification, promptly its overload entity identification be empty, and the identity of entity of wherein not transshipping identifies; But include the minimizing coefficient in the responsive load head; Explain that then possibly be requesting party self overload this moment, whether it will promptly reach optimum value through repeating transmission coefficients R ETFAC and judge through calculating and determine whether overload.If the requesting party judges himself overload, then use the minimizing coefficient in the responsive load head, to reduce the request message that sends; If the requesting party judges himself nonoverload, then refusal uses the minimizing coefficient in the responsive load head, still sends a request message with current standard, and the quantity of the request message that promptly sends can not increase or reduce.
The minimizing coefficient of in the above-mentioned several kinds of situation that possibly occur, mentioning is that the requesting party is used for reducing the request message that will send according to it, and the data and the weight of the system capability that can need based on the entity of overload, data volume, processing calculate.
After above-mentioned overload processing method embodiment step 303, possibly also can comprise: step 304, requesting party receive the response message that has the responsive load head once more; And the information in the responsive load head analyzed, to reduce, to recover or keep being sent to recipient's request message.
This step 304 has several kinds of following possibility situation, is specially:
Situation one, if the requesting party receive the response message that has the responsive load head once more; And through comparing; Wherein have the parameter identifier bigger than the value of last parameter identifier; Then requestor application and the corresponding minimizing coefficient of parameter identifier in the current response message, and reduce the request message that the requesting party is sent to the recipient according to reducing coefficient;
Situation two, if the requesting party receive the response message that has the responsive load head once more; Analyzing responding load head; Wherein do not comprise the overload entity identification; The quantity that then is sent to recipient's request message can be recovered standard value, and promptly the requesting party does not have because reduce the quantity that coefficient FAC reduces request message request message before;
Situation three, if the requesting party receive the response message that has the responsive load head once more; Analyzing responding load head is recipient's identify label comprising the overload entity identification, does not comprise the minimizing coefficient; Then the requesting party keeps the current quantity that sends a request message, and sends a request message to the recipient.
The situation of utilizing the entity overload in the system that possibly occur that this overload controlling mechanism handles of foregoing description.Through in message, adding the load head, and the load head is analyzed, can effectively be detected requesting party or recipient's overload situations in the system, and it is applied overload control.If recipient's overload, promptly the recipient can not respond too much request message, and the recipient can inform the requesting party through the responsive load head so, and the request requesting party reduces the request that is sent to the recipient; If the requesting party is transshipped, can learn according to the calculating of himself, and can reduce its request message that will send through recipient's help.Method through above-mentioned overload is handled can be implemented under the situation that does not increase the extra system load, detects and implement effective control to the multiple overload situations of entity in the system.
In addition; The situation of utilizing the entity overload in the system that possibly occur that this overload controlling mechanism handles of foregoing description is all possibilities of limit not; Add the method that the load head carries out overload detection control so long as can utilize; Reaching under the situation that does not increase system load, the entity of overload carried out effectively detect and the purpose of control, all belong to the scope that the embodiment of the invention is protected.
As shown in Figure 4, transship the functional entity structural representation of processing method embodiment for another the present invention, the method that this overload is handled is applied under close-connected two functional entitys, i.e. sip server 410 and sip server 420.Under the situation that request message is retransmitted, carry following request load head in the request message of supposing to send by sip server 410:
load:NOR=5;RETFAC=0.3,
Wherein NOR=5 representes that this request message retransmitted 4 times, and this is that the 5th is retransmitted this request message; In 1000 message before RETFAC=0.3 is illustrated in, this request has been retransmitted 300 times.
After sip server 420 received this request load head, if sip server 420 has the function of identification load head, it can extract this request load head so, and analyzed NOR and RETFAC in this request load head; If RETFAC is bigger, exceeded the numerical value that it can receive, SIP server 420 will draw the conclusion of its overload so, and in response, carry following responsive load head informing sip server 410 its overloads, and expectation can reduce its load:
load:NOR=5;RETRANS=0;O=<SIP?Server?B?Identity>;FAC=0.9;RETFAC=0.004;FACID=10,
Wherein, NOR=5 representes that sip server 420 is that the 5th of request message is retransmitted the response of carrying out, and it is to carry out the transmission of response message for the first time, and " for the first time " this number is drawn by RETRANS=0; This responsive load head explains that also sip server 420 self transships, and draws through its identify label of in O=< SIPServer B Identity >, placing, and this identify label meeting is found by sip server 410; Through coefficient FAC=0.9, the ratio of the request message that sip server 420 hope reduce is described.FAC=0.9 representes that sip server 410 should reduce 10% of its request message, only sends 90% request message, and for example: if sip server 410 per seconds are sent out 10 requests, from now on, it answers per second to send out 9 requests.
This coefficient of FAC need be by calculating based on the inner entity of realizing of functional entity self, and this realization can be based on the quantity and the weight of system capability, data volume, processing, and these values are references that entity need be used to move request message or response message etc.
Some possibility situation below in above-mentioned request process, also comprising:
Extract request load head at sip server 420, and after analyzing the NOR and RETFAC in this request load head, confirmed its not overload, so, then need in the responsive load head, not add O=and FAC=parameter; This moment, sip server 410 analyzing responding load heads as wherein not having O=and FAC=parameter, were then confirmed not overload of sip server 420, the state that sends a request message before continuing.
If sip server 410 is received a plurality of response messages continuously; Each response message all has the responsive load head; Wherein all contain O=and FAC=parameter, 410 of sip servers are checked the FACID parameter so, if with respect to the responsive load head in the previous response message; FACID in the responsive load head in this response message is changed; Value than this original parameter has increased, and sip server 410 can be used the FAC in the responsive load head of this response message once more again so, promptly maybe be for reducing the quantity of the request message that sip server 410 sends once more.
Responsive load head like this moment is: load:NOR=5; RETRANS=0; O=< SIP Server BIdentity >; FAC=0.9; RETFAC=0.004; FACID=11; A FACID is increased to 11 by 10 with respect to last responsive load; Sip server 410 will be used FAC=0.9 once more this moment so; For example: before the request message that sends of sip server 410 in the time per unit 100 be reduced in the time per unit 90, so this moment can be in the time per unit 90 be reduced in the time per unit 81.
Receive the responsive load head that contains O=and FAC=parameter when sip server 410; And after having reduced the quantity that sends a request message; Received the above-mentioned responsive load head that has different FACID once more, sip server 410 will be once more be applied in the FAC in this responsive load head of receiving on the quantity of the current request message that is sent to sip server 420 so.For example, sip server 410 has only sent 81 request messages before, so maybe be less once more to 72 request messages.
Used in the response message after the FAC parameter of responsive load head at sip server 410, reduced the request message that is sent to sip server 420; The possibility that exist sip server 420 no longer to transship this moment, promptly sip server 420 can be handled the quantity of request message this moment, and sip server 420 will no longer carry the O=parameter in the responsive load head of response message so; After sip server 410 was received the responsive load head, finding did not wherein have the O=parameter, then should attempt recovering to reduce request message quantity before and send a request message to sip server 420.
Just can be handled after the quantity of asking is sent in sip server 410 minimizings if sip server 420 is thought, and hope to keep this quantity, can in the responsive load head, carry the O=parameter so, and not carry the FAC parameter by sip server 420; This moment, sip server 410 was through the analysis to the responsive load head, with keeping the current quantity that sends a request message.
If sip server 420 is not discerned the function of load head, after sip server 420 is received the request message that has request load head so, will can not carry the responsive load head in the response message of answer; After this moment, sip server 410 received this response message that does not have the responsive load head, the analysis that can carry out through the RETFAC parameter that it is had judged whether sip server 420 transships.Sip server 410 should have himself optimized RETFAC parameter; If the value of the RETFAC in its request load head has surpassed the value of optimized RETFAC; Sip server 410 will attempt reducing through a coefficient (being similar to FAC) quantity of the request message of sip server 410 transmissions, and the value of the RETFAC of the request load head in the request message of its transmission reaches the value of its optimized RETFAC.
Under the situation that response message is retransmitted; Even the request message of sip server 410 transmissions all can be handled by sip server 420; But sip server 420 is when replying response message; But always retransmit response message, the repeating transmission number of times of this response message can be learnt from the RETRANS parameter the responsive load head that response message carries, and carries the response message of following responsive load head like sip server 420 transmissions this moment:
load:NOR=0;RETRANS=5;FAC=0.9;RETFAC=0.07;FACID=10。
Consider that from another angle can think that sip server 420 recognizes that sip server 410 possibly transship, sip server 420 can only send and have the FAC=parameter so, and not with the responsive load head of O=parameter; Behind the responsive load head of sip server 410 in the response message of analyzing sip server 420 transmissions, know that sip server 420 request sip servers 410 reduce request messages, promptly sip server 420 helps sip servers 410 to reduce its possible overload situations; This moment, sip server 410 was based on himself calculating, determined whether to receive FAC parameter in this responsive load head to reduce the request quantity of its transmission.Even sip server 410 is also thought and self is transshipped through calculating, and then uses the quantity that the FAC parameter reduces the request message that sends, otherwise refusal is used the FAC parameter, still sends a request message according to original standard.
Need to prove, the not all overload detection of limit and the situation of control here, as long as have the parameter of some definition in the load head, and functional entity can analyze again, and is applied on the overload detection, just belongs to the scope that the embodiment of the invention is protected.
As shown in Figure 5, transship the schematic flow sheet of processing method embodiment for another the present invention, comprise the steps:
Step 501, requesting party send first request message that carries the first request load head through intermediate entities to the recipient, and this request load head comprises the repeating transmission number of times and repeating transmission coefficient of first request message;
Step 502, intermediate entities receive first request message, after treatment, return first response message that carries the first responsive load head to the requesting party, and this first responsive load head comprises the overload entity identification and reduces coefficient;
After step 503, requesting party receive first response message, analyze the first responsive load head, and determine whether to exist the overload entity.
The described overload processing method of present embodiment has had more intermediate entities than the foregoing description; If the requesting party at two ends or recipient's overload; Described in its detection case such as the above-mentioned embodiment, different is that its mutual various informational needs are transmitted through intermediate entities, repeats no more at this; If intermediate entities transships, the technical scheme of present embodiment can realize whether middle entity transshipped and detect, and this intermediate entities can be a plurality of.
Further refinement to step 502 and step 503 can explain that this intermediate entities possesses the function of discerning the load head in the example from two examples:
After step 5021, intermediate entities receive first request message; Load header of himself and the information structuring in the first request load head are formed the second request load head together; Second request message that carries the second request load head is sent to the recipient, and the second request load head comprises repeating transmission number of times, the overload entity identification of first request message and retransmits coefficient;
After step 5022, recipient receive second request message; Second response message that carries the second responsive load head is sent to intermediate entities, and the second responsive load head comprises the repeating transmission number of times of first request message, repeating transmission number of times, overload entity identification and the repeating transmission coefficient of second response message;
After step 5023, intermediate entities receive second response message; Through analysis to the second request load head and the second responsive load head; Load header of himself and the information structuring in the second responsive load head are formed the first responsive load head together; First response message that carries the first responsive load head is sent to the requesting party, and the first responsive load head also comprises the repeating transmission number of times of first request message, repeating transmission number of times, repeating transmission coefficient and the parameter identifier of first response message;
After step 5031, requesting party receive first response message, analyze the first responsive load head, if the overload entity identification is the sign of intermediate entities, then the requesting party confirms the intermediate entities overload; Perhaps, if the overload entity identification is the sign of intermediate entities and recipient's sign, then the requesting party confirms intermediate entities and recipient's overload;
Step 5032, use reduce coefficient and reduce first request message that is sent to intermediate entities.
In another example, this intermediate entities does not possess the function of identification load head:
After step 5024, intermediate entities receive first request message, first request message that carries the first request load head is forwarded to the recipient;
After step 5025, recipient receive first request message of forwarding, first response message that carries the first responsive load head is sent to intermediate entities;
After step 5026, intermediate entities receive first response message, first response message that carries the first responsive load head is forwarded to the requesting party;
After step 5033, requesting party receive first response message, analyze the first responsive load head, if the overload entity identification is recipient's a sign, then the requesting party confirms that the recipient transships;
Minimizing coefficient in step 5034, the use first responsive load head reduces first request message that is sent to intermediate entities;
Above-mentioned steps 5033 and 5034 can also for:
Step 5033 ', if the overload entity identification be empty, then, determine whether to exist the situation of intermediate entities overload through calculating the repeating transmission coefficient in the first request load head, if existence, execution in step 5034 ';
Step 5034 ', use the minimizing coefficient calculate to reduce first request message that is sent to intermediate entities.
About the detailed description of these two examples, with describing among the overload processing method embodiment below.
Present embodiment has been introduced the processing method of the intermediate entities overload of a plurality of inter-entity; Structure through a plurality of request load heads and a plurality of responsive load heads; Can realize the overload situations of the entity at middle entity and two ends is detected and controls; With under the situation that does not increase the extra system load, to possibly detecting and control of entity overload.
As shown in Figure 6; Transship the functional entity structural representation of processing method embodiment for another the present invention, the method that this overload is handled is applied to open environment, promptly in this system, possibly comprise a plurality of functional entitys; In the present embodiment; As shown in Figure 6, comprise 5 functional entitys, i.e. sip server 610, SIP server 620, sip server 630, sip server 640 and sip server 650.
In Fig. 6, suppose that sip server 610 sends a request message, this request message is delivered to sip server 620 through sip server 630.If sip server 610 and sip server 620 equal holding load heads; Iff is the phenomenon that overload is arranged in their two entities so; And can not relate to the overload of intermediate entities, they can communicate with one another so, and detect overload situations; As the explanation in above-mentioned Fig. 3 and embodiment shown in Figure 4, intermediate entities only plays the effect of forwarding.
Because present embodiment is the overload detection that is applied under the open environment, functional entity sip server 630 overloads that also might be middle, present embodiment will detect 630 overloads of the functional entity sip server in such cases.
A kind of is that supposition sip server 610 all can be discerned the load head with sip server 620, and therefore sip server 630 be in overload owing to also carrying out information interaction with sip server 640, and also holding load head of sip server 630.
In this case, suppose not overload of sip server 620, sip server 630 transships, and the flow process of overload detection is:
Carry a following request load 1:load:NOR=5 in the request message that step 601, sip server 610 send; RETFAC=0.3, wherein the implication of each parameter such as above-mentioned embodiment are said;
Step 602, sip server 630 after receiving this request message, can send have following request load 2 request message to sip server 620:load:NOR=5; O=< SIP Entity B Identity >; RETFAC=0.4;
Step 603, sip server 620 be overload not, and its response message that will carry responsive load 3 sends to sip server 630:load:NOR=5 so; RETRANS=0; O=< SIP Server BIdentity >; RETFAC=0.004;
After step 604, sip server 630 obtain this responsive load 3,, the response message that carries following responsive load 4 is sent to sip server 610:load:NOR=5 through analysis and the calculating of oneself; RETRANS=0; O=< S IP Server B Identity >; FAC=0.9; RETFAC=0.004; FACID=10;
Step 605, sip server 610 are through analyzing; Obtain O=and FAC=parameter in the responsive load 4; If this moment, sip server 610 was up to the approach that can arrive sip server 620 in addition; As shown in Figure 5 in the present embodiment, it can send by remaining requests message after the FAC=calculation of parameter to sip server 620 through SI P server 650 so; If there is not other approach can arrive sip server 620, sip server 610 needs to reduce through the FAC=parameter quantity of the request message of its transmission so, thereby still all is sent to sip server 620 through sip server 630.
In this case, suppose that sip server 630 transships, and sip server 620 transships also, this is divided into two kinds of situations again:
1. after above-mentioned steps 601~605; Be that sip server 610 possibly still send all request messages to sip server 620 by two paths; Perhaps sip server 610 has reduced through the request of sip server 630 to sip server 620 through the FAC=parameter; But sip server 620 is owing to some reasons, and no longer can handle all request messages of issuing it this moment, and sip server 620 overloads that cause; This moment, the response message that the sip server 620 of overload carries following responsive load 3 with transmission was to sip server 630:load:NOR=5 in the transmission process of sip server 630 and sip server 620; RETRANS=0; O=< SIP Server B Identity, SIP Entity CIdentity >; FAC=0.9; RETFAC=0.004, wherein RETFAC is the factor between sip server 630 and the sip server 620, but not between sip server 610 and the sip server 620; Sip server 630 is after receiving this responsive load 3; If confirming it is necessary further to reduce the request message that sip server 610 sends through another FAC factor; So sip server 630 transmission is carried increase the responsive load 4 of new coefficient FAC of FACID to sip server 610, to reduce the request message that sip server 610 sends.
2. arriving sip server 630 in sip server 610 re-transmission request message, promptly in the beginning of step 601, is exactly that sip server 630 all transships with sip server 620, and the flow process of overload detection is:
Step 601 ', carry a following request load 1:load:NOR=5 in the request message that sends of sip server 610; RETFAC=0.3, wherein the implication of each parameter such as above-mentioned embodiment are said;
Step 602 ', sip server 630 after receiving this request message, can send have following request load 2 request message to sip server 620:load:NOR=5; O=< SIP Entity B Identity >; RETFAC=0.4;
Step 603 ', sip server 620 also transships, its response message that will carry responsive load 3 sends to sip server 630:load:NOR=5 so; RETRANS=0; O=< SIP Server B Identity, SIP Entity C Identity >; FAC=0.9; RETFAC=0.004; FACID=10;
Step 604 ', after sip server 630 obtains this responsive load 3,, the response message that carries following responsive load 4 is sent to sip server 610:load:NOR=5 through analysis and the calculating of oneself; RETRANS=0; O=< SIP Server B Identity, SIP Entity C Identity >; FAC=0.7; RETFAC=0.004; FACID=20;
Step 605 ', sip server 610 is through analyzing; Obtain O=, FAC=and FACID=parameter in the responsive load 4; The O=parameter indicating sip server 620 that this moment, sip server 610 obtained transships with sip server 630; The parameter of FACID=20 has increased before, therefore uses the FAC parameter in this responsive load 4, reduces request message.
In this case; Also might be sip server 620 overloads; And do not have other entities overload, this moment, sip server 630 was to be responsible for the content of transmitted response load 3 to sip server 610, and the various situation of its realization are shown in above-mentioned embodiment; Just also need sip server 630, promptly intermediate entities is transmitted; Perhaps sip server 620 does not pass through the sip server 630 responds SIP servers 610 of overload; Identical with preceding a kind of situation; Promptly passed through not have the intermediate entities response of overload; If this moment, sip server 620 overload was so only sent it self FAC=parameter to sip server 610, the quantity that request reduces request message gets final product.
Another kind is that supposition sip server 610 all can be discerned the load head with sip server 620, and sip server 630 therefore be in overload, but sip server 630 cannot be discerned the load head owing to also carrying out information interaction with sip server 640.
If overload entity sip server 630 does not provide the load head, just can't learn it is that sip server 630 transships, in this case, sip server 630 will be transmitted load head in sip server 610 request messages to sip server 620.If this moment, sip server 620 did not know whether himself transships, the mechanism that does not promptly have its identification whether to transship, sip server 620 will suppose that it transships so; In response message, carry the response message that comprises own identify label; And being forwarded to sip server 610 by sip server 630, sip server 610 is learnt sip server 620 overloads through analyzing; Based on the FAC=parameter in the responsive load head that sends by sip server 620, reduce the quantity of the request of sending.If this moment, sip server 620 can be known itself and nonoverload, it is the identify label of in the responsive load head, not adding oneself, and this responsive load head is forwarded to sip server 610 by sip server 630; Sip server 610 is confirmed not overload of target entity sip server 620; At this moment; It should possess the ability whether the autoanalysis system transships, and sip server 610 is analyzed it why can re-transmission request message, and confirms in transmit path, whether there is the overload entity; The entity that has overload in the path of confirming sending really when sip server 610; It can select other alternative path to share request message so; Perhaps, obtain the FAC=parameter, and reduce the quantity of request message according to this FAC=parameter through self analysis, calculating.
In conjunction with above-mentioned two embodiment; Through this overload controlling mechanism and overload processing method; Information in the response message that UA can receive through its in the responsive load head learn whether himself transships, or whether the entities in the middle of other transship, and after having known which entity overload, can take timely solution route with the control overload situations; For example reduce the request message that himself sends, perhaps telling the part request message does not have the entity of overload to send or the like through other.Realized when carrying out effective overload detection, not increasing the load of system, made that the flexibility of overload detection and control is strong, simple effectively being prone to implemented.
As shown in Figure 7, for the structural representation of the SIP physical embodiment handled is transshipped in the present invention.This SIP entity comprises: request load head structure module 710, be used for structure request load head, and this request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least; First sending module 720, the request message that is used to send the request load head that carries request load head structure module 710 structures is to recipient SIP entity; First receiver module 730 is used to receive the response message that carries the responsive load head that recipient SIP entity returns, or the response message that does not carry the responsive load head that returns; Judge module 740 is used for judging the responsive load head of the response message that first receiver module 730 receives, and determines whether to exist the overload entity.
The SIP entity that this overload is handled is the major function construction module that the requesting party in the above-mentioned overload processing method carries out overload detection and control; Described in overload detection that it is concrete and control method such as the above-mentioned overload processing method embodiment, the determination methods of 740 pairs of several kinds of overload situations of judge module especially.
In the SIP entity that this overload is handled, can also comprise recipient's SIP entity, comprise: second receiver module 750 is used to receive the request message of the request of the carrying load head that first sending module 720 sends; Responsive load head structure module 760 is used for tectonic response load head, and this responsive load head comprises the repeating transmission number of times of request message, the repeating transmission number of times and the overload entity identification of response message at least; Second sending module 770 is used to send the response message that carries the responsive load head, or does not carry response message to the first receiver module 730 of responsive load head.
The SIP entity that the overload that present embodiment provides is handled can construct the load head that is used for overload detection and control through load head structure module wherein; It is added in solicited message and the response message transmit; Through the judge module in the SIP entity; Information in the load head is analyzed, is judged, draws the information and the information content that needs control of overload entity.Can be implemented under the situation that does not increase system load, the entity in the system is carried out effective overload detection and control.
As shown in Figure 8, for the structural representation of treatment system embodiment is transshipped in the present invention.This overload treatment system comprises: requesting party SIP entity 810 is used to send the request message that carries request load head, and according to the response message that receives, determines whether to exist the overload entity; Recipient SIP entity 820 is used to receive the request message that requesting party SIP entity 810 sends, and returns the response message that carries the responsive load head, or do not carry the response message of responsive load head.
This requesting party SIP entity 810 comprises: request load head structure module 811, be used for structure request load head, and this request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least; First sending module 812, the request message that is used to send the request load head that carries request load head structure module 811 structures is to recipient SIP entity; First receiver module 812 is used to receive the response message that carries the responsive load head that recipient SIP entity returns, or the response message that does not carry the responsive load head that returns; Judge module 814 is used for judging the responsive load head of the response message that first receiver module 812 receives, and determines whether to exist the overload entity.
This recipient SIP entity 820 comprises: second receiver module 821 is used to receive the request message of the request of the carrying load head that first sending module 812 sends; Responsive load head structure module 822 is used for tectonic response load head, and this responsive load head comprises the repeating transmission number of times of request message, the repeating transmission number of times and the overload entity identification of response message at least; Second sending module 823 is used to send the response message that carries the responsive load head, or does not carry response message to the first receiver module 813 of responsive load head.
This overload treatment system can also comprise: intermediate entities 830, be used to receive the request message of the request of the carrying load head of requesting party SIP entity 810, and after treatment, be sent to recipient SIP entity 820; Receive the response message that carries the responsive load head of recipient SIP entity 820, after treatment, be sent to requesting party SIP entity 810.
This intermediate entities 830 specifically comprises: the 3rd receiver module 831 is used to receive carrying of requesting party SIP entity request message of asking the load head and the response message that carries the responsive load head that receives recipient SIP entity 820; The nose heave structure module 832 of request load is used for the request load head of requesting party SIP entity 810 is carried out reconstruct, comprising the loading condition of intermediate entities 830; Structure module 833 that responsive load is nose heave is used for the responsive load head of recipient SIP entity 820 is carried out reconstruct, comprising the loading condition of intermediate entities 830; The 3rd sending module 834; Be used to send carry the request load head after the reconstruct request message to recipient SIP entity 820; And the response message that reconstruct responsive load head is afterwards carried in transmission is to requesting party SIP entity 810; The request message of the request of carrying load head that perhaps is used to transmit requesting party SIP entity 810 is to recipient SIP entity 820, and the response message that carries the responsive load head of transmitting recipient SIP entity 820 is to requesting party SIP entity 810.
The overload treatment system that present embodiment provides is through the load head structure module of requesting party SIP entity and recipient SIP entity; Can construct the load head that is used for overload detection and control; It is added in solicited message and the response message transmit; Through the judge module in the SIP entity, the information in the load head is analyzed, judged, draw the information and the information content that needs control of overload entity.Can also detect and control the overload situations of middle entity structure through above-mentioned load head.Realized under the situation that does not increase system load, the entity in the system being carried out effective overload detection and control.
Device embodiment described above only is schematic; Wherein said unit as the separating component explanation can or can not be physically to separate also; The parts that show as the unit can be or can not be physical locations also; Promptly can be positioned at a place, perhaps also can be distributed on a plurality of NEs.Can realize the purpose of present embodiment scheme according to the needs selection some or all of module wherein of reality.Those of ordinary skills promptly can understand and implement under the situation of not paying performing creative labour.
Through the description of above execution mode, those skilled in the art can be well understood to each execution mode and can realize by the mode that software adds essential general hardware platform, can certainly pass through hardware.Based on such understanding; The part that technique scheme contributes to prior art in essence in other words can be come out with the embodied of software product; This computer software product can be stored in the computer-readable recording medium, like ROM/RAM, magnetic disc, CD etc., comprises that some instructions are with so that a computer equipment (can be a personal computer; Server, perhaps network equipment etc.) carry out the described method of some part of each embodiment or embodiment.
What should explain at last is: above embodiment is only in order to explaining technical scheme of the present invention, but not to its restriction; Although with reference to previous embodiment the present invention has been carried out detailed explanation, those of ordinary skill in the art is to be understood that: it still can be made amendment to the technical scheme that aforementioned each embodiment put down in writing, and perhaps part technical characterictic wherein is equal to replacement; And these are revised or replacement, do not make the spirit and the scope of the essence disengaging various embodiments of the present invention technical scheme of relevant art scheme.

Claims (22)

1. an overload processing method is characterized in that, comprising:
The requesting party sends the request message that carries request load head to the recipient, and described request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least, and the repeating transmission coefficient of described request message is used for the number of re-transmission of the request message of definite each determined number;
Receive the response message that carries the responsive load head that said recipient returns, determine whether to exist the overload entity, wherein said responsive load head comprises the repeating transmission number of times of request message, the repeating transmission number of times and the overload entity identification of response message at least;
Perhaps; Receive the response message that does not carry the responsive load head that said recipient returns; Judge whether the repeating transmission coefficient in the described request load head has surpassed the optimization repeating transmission coefficient that described request side itself has; If described request side reduces the quantity forwarded of request message, retransmit coefficient up to obtaining said optimization.
2. overload processing method according to claim 1; It is characterized in that; The said existence overload entity that determines whether specifically comprises: after described request side receives the response message that has said responsive load head; Obtain said overload entity identification, this overload entity identification is said recipient's identify label, confirms that then said recipient is the overload entity.
3. overload processing method according to claim 2; It is characterized in that; Reduce coefficient and parameter identifier if also comprise in the said responsive load head; Then said receive the response message that has said responsive load head after, described request side also obtains said minimizing coefficient, and reduces the described request message that is sent to said recipient according to said minimizing coefficient; Wherein said parameter identifier is used for explaining the minimizing coefficient of whether using said responsive load head as the sign of said minimizing coefficient.
4. overload processing method according to claim 1 is characterized in that, the said existence overload entity that determines whether specifically comprises:
If described request side receives a plurality of said responsive load head corresponding with a plurality of response messages; And comprise said overload entity identification in the said responsive load head and reduce coefficient, parameter identifier; Then described request side compares each parameter identifier; Said parameter identifier is used for explaining the minimizing coefficient of whether using said responsive load head as the sign of said minimizing coefficient;
If the value of the said parameter identifier in the current response message is greater than the said parameter identifier in the last response message; Then use with current response message in the corresponding said minimizing coefficient of said parameter identifier, and be sent to said recipient's described request message according to said minimizing coefficient minimizing.
5. overload processing method according to claim 1; It is characterized in that the said existence overload entity that determines whether specifically comprises: after described request side receives the response message that has said responsive load head, obtain said overload entity identification; This overload entity identification is empty; And do not detect the minimizing coefficient, confirm that then said recipient is not the overload entity, and according to before the quantity continuation that sends a request message send described request message to said recipient.
6. overload processing method according to claim 3; It is characterized in that; The said existence overload entity that determines whether specifically comprises: after described request side receives the response message that has said responsive load head; Analyzing said responsive load head, is the numerical value of empty and said minimizing coefficient according to wherein said overload entity identification, judges whether himself transships.
7. overload processing method according to claim 6 is characterized in that, said basis said overload entity identification wherein is empty and the numerical value of said minimizing coefficient, judge himself whether transship after, said method also comprises:
If its overload is judged by described request side, then use the minimizing coefficient in the said responsive load head, to reduce the request message that sends; If its nonoverload is judged by described request side, then refusal is used the minimizing coefficient in the said responsive load head, still sends described request message with current standard.
8. according to claim 3,4,6 or 7 described overload processing methods, it is characterized in that the data and the weight of the system capability that said minimizing coefficient needs based on said overload entity, data volume, processing calculate.
9. overload processing method according to claim 8 is characterized in that, comprises after the existence overload entity said determining whether:
If described request side receives the response message that has the responsive load head once more; And through comparing; Wherein have the said parameter identifier bigger than the value of the said parameter identifier in the last response message; Then described request side use with current response message in the corresponding said minimizing coefficient of said parameter identifier, and be sent to said recipient's described request message according to said minimizing coefficient minimizing.
10. overload processing method according to claim 8 is characterized in that, comprises after the existence overload entity said determining whether:
If described request side receives the said response message that has the responsive load head once more; Analyze said responsive load head; If wherein said overload entity identification is for sky or do not comprise said overload entity identification; Then the quantity of described request message is recovered standard value, and sends described request message to said recipient.
11. overload processing method according to claim 8 is characterized in that, comprises after the existence overload entity said determining whether:
If described request side receives the said response message that has the responsive load head once more; Analyze said responsive load head; If be said recipient's identify label and do not comprise said minimizing coefficient comprising said overload entity identification; Then described request side keeps the quantity of current transmission described request message, sends described request message to said recipient.
12. overload processing method according to claim 1 is characterized in that,
Described request direction recipient sends the request message that carries request load head and specifically comprises: the requesting party sends first request message that carries the first request load head through intermediate entities to the recipient, and described request load head comprises the repeating transmission number of times of request message and retransmits coefficient;
The response message that carries the responsive load head that said recipient returns specifically comprises: said intermediate entities receives said first request message; After treatment; Return first response message that carries the first responsive load head to described request side, the said first responsive load head comprises the overload entity identification and reduces coefficient;
The said existence overload entity that determines whether specifically comprises: after described request side receives said first response message, analyze the said first responsive load head, and determine whether to exist the overload entity.
13. overload processing method according to claim 12 is characterized in that, said intermediate entities receives said first request message, and after treatment, step from first response message that carries the first responsive load head to described request side that return comprises:
After said intermediate entities receives said first request message; Second request message that carries the second request load head is sent to said recipient, and the said second request load head comprises repeating transmission number of times, the overload entity identification of first request message and retransmits coefficient;
After said recipient receives said second request message; Second response message that carries the second responsive load head is sent to said intermediate entities, and the said second responsive load head comprises the repeating transmission number of times of first request message, repeating transmission number of times, overload entity identification and the repeating transmission coefficient of second response message;
After said intermediate entities receives said second response message; Through analysis to the second request load head and the second responsive load head; First response message that carries the said first responsive load head is sent to described request side, and the said first responsive load head also comprises the repeating transmission number of times of first request message, repeating transmission number of times, repeating transmission coefficient and the parameter identifier of first response message.
14. overload processing method according to claim 13 is characterized in that, after described request side receives said first response message, analyzes the said first responsive load head, and determines whether to exist the overload entity to comprise:
After described request side receives said first response message; Analyze the said first responsive load head; If the sign that said overload entity identification is said intermediate entities; Then described request side confirms said intermediate entities overload, and uses said minimizing coefficient and reduce said first request message that is sent to said intermediate entities; If said overload entity identification is the sign of said intermediate entities and said recipient's sign; Then described request side confirms said intermediate entities and said recipient overload, and uses said minimizing coefficient and reduce said first request message that is sent to said intermediate entities.
15. overload processing method according to claim 12 is characterized in that, said intermediate entities receives said first request message, after treatment, returns first response message that carries the first responsive load head to described request side and comprises:
After said intermediate entities receives said first request message, first request message that carries the said first request load head is forwarded to said recipient;
Said recipient is sent to said intermediate entities with first response message that carries the first responsive load head after receiving said first request message of forwarding;
After said intermediate entities receives said first response message, said first response message that carries the said first responsive load head is forwarded to described request side.
16. overload processing method according to claim 15 is characterized in that, after described request side receives said first response message, analyzes the said first responsive load head, and determines whether to exist the overload entity to comprise:
After described request side receives said first response message; Analyze the said first responsive load head; If the sign that said overload entity identification is said recipient; Then described request side confirms said recipient's overload, and the minimizing coefficient of using in the said first responsive load head reduces said first request message that is sent to said intermediate entities; If said overload entity identification is empty; Then through calculating the repeating transmission coefficient in the said first request load head; Determine whether to exist the situation of intermediate entities overload,, then use the minimizing coefficient that calculates and reduce said first request message that is sent to said intermediate entities if exist.
17. one kind transships the session initiation protocol entity of handling, and it is characterized in that, comprising:
Ask load head structure module, be used for structure request load head, described request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least, and the repeating transmission coefficient of described request message is used for the number of re-transmission of the request message of definite each determined number;
First sending module, be used to send carry request load head request message to recipient's session initiation protocol SIP entity;
First receiver module is used to receive the response message that carries the responsive load head that said recipient SIP entity returns, or the response message that does not carry the responsive load head that returns;
Judge module, be used for when said first receiver module receive that said recipient SIP entity returns carry the response message of responsive load head the time, determine whether to exist the overload entity; When said first receiver module receive that said recipient SIP entity returns do not carry the response message of responsive load head the time judge whether repeating transmission coefficient in the described request load head has surpassed the optimization that described request side itself has and retransmitted coefficient; If; Described request side reduces the quantity forwarded of request message, retransmits coefficient up to obtaining said optimization.
18. one kind transships the session initiation protocol entity of handling, and it is characterized in that, comprising:
Second receiver module; Be used to receive the request message of asking the load head that carries of requesting party's transmission; Described request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least, and the repeating transmission coefficient of described request message is used for the number of re-transmission of the request message of definite each determined number;
Responsive load head structure module is used for tectonic response load head, and said responsive load head comprises the repeating transmission number of times of request message, the repeating transmission number of times and the overload entity identification of response message at least;
Second sending module is used to send the response message that carries the responsive load head, or does not carry the response message of responsive load head.
19. an overload treatment system is characterized in that, comprising:
Requesting party's session initiation protocol SIP entity is used to send the request message that carries request load head, and according to the response message that receives, determines whether to exist the overload entity; Comprise: ask load head structure module, be used for structure request load head, described request load head comprises the repeating transmission number of times and repeating transmission coefficient of request message at least, and the repeating transmission coefficient of described request message is used for the number of re-transmission of the request message of definite each determined number; First sending module, be used to send carry request load head request message to recipient's session initiation protocol SIP entity; First receiver module is used to receive the response message that carries the responsive load head that said recipient SIP entity returns, or the response message that does not carry the responsive load head that returns; Judge module, be used for when said first receiver module receive that said recipient SIP entity returns carry the response message of responsive load head the time, determine whether to exist the overload entity; When said first receiver module receive that said recipient SIP entity returns do not carry the response message of responsive load head the time judge whether repeating transmission coefficient in the described request load head has surpassed the optimization that described request side itself has and retransmitted coefficient; If; Described request side reduces the quantity forwarded of request message, retransmits coefficient up to obtaining said optimization;
Recipient SIP entity; Be used to receive the request message that SIP entity in described request side sends; And return the response message that carries the responsive load head; Or not carrying the response message of responsive load head, said responsive load head comprises the repeating transmission number of times of request message, the repeating transmission number of times and the overload entity identification of response message.
20. overload treatment system according to claim 19 is characterized in that, said recipient SIP entity comprises:
Second receiver module is used to receive the request message of the request of the carrying load head that said first sending module sends;
Responsive load head structure module is used to construct said responsive load head;
Second sending module is used to send the response message that carries the responsive load head, or does not carry the response message of responsive load head.
21. according to claim 19 or 20 described overload treatment systems, it is characterized in that, also comprise: intermediate entities, be used to receive the request message of the request of the carrying load head of described request side SIP entity, after treatment, be sent to said recipient SIP entity; Receive the response message that carries the responsive load head of said recipient SIP entity, after treatment, be sent to described request side SIP entity.
22. overload treatment system according to claim 21 is characterized in that, said intermediate entities comprises:
The 3rd receiver module is used to receive carrying of described request side SIP entity request message of asking the load head and the response message that carries the responsive load head that receives said recipient SIP entity;
The nose heave structure module of request load is used for the request load head of described request side SIP entity is carried out reconstruct, comprising the loading condition of said intermediate entities;
Structure module that responsive load is nose heave is used for the responsive load head of said recipient SIP entity is carried out reconstruct, comprising the loading condition of said intermediate entities;
The 3rd sending module; Be used to send request message to the said recipient SIP entity that carries reconstruct request load head afterwards; And response message to the described request side SIP entity of reconstruct responsive load head is afterwards carried in transmission; Perhaps be used to transmit request message to the said recipient SIP entity that carrying of described request side SIP entity asked the load head, and response message to the described request side SIP entity that carries the responsive load head of transmitting said recipient SIP entity.
CN200810117741A 2008-08-04 2008-08-04 Method, system and SIP entity for overload processing Active CN101645825B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN200810117741A CN101645825B (en) 2008-08-04 2008-08-04 Method, system and SIP entity for overload processing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN200810117741A CN101645825B (en) 2008-08-04 2008-08-04 Method, system and SIP entity for overload processing

Publications (2)

Publication Number Publication Date
CN101645825A CN101645825A (en) 2010-02-10
CN101645825B true CN101645825B (en) 2012-10-17

Family

ID=41657549

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200810117741A Active CN101645825B (en) 2008-08-04 2008-08-04 Method, system and SIP entity for overload processing

Country Status (1)

Country Link
CN (1) CN101645825B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102811197B (en) * 2011-05-30 2016-12-21 中兴通讯股份有限公司 Overload controlling method, device and system
CN102739688A (en) * 2012-07-06 2012-10-17 北京邮电大学 Active detection based SIP (session initiation protocol) network overload control system and method
CN107276729B (en) * 2017-07-21 2019-08-20 中国联合网络通信集团有限公司 Long link service request time-out repeating method and intermediate node

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5898672A (en) * 1994-11-11 1999-04-27 Nokia Telecommunications Oy Overload prevention in a telecommunication network node
CN1918884A (en) * 2004-02-09 2007-02-21 诺基亚公司 Method and system for transmitting a multimedia message to multiple recipients.
CN101005695A (en) * 2006-01-18 2007-07-25 华为技术有限公司 Method and system for connecting contlict aviodance in radio communication
CN101110756A (en) * 2006-07-18 2008-01-23 华为技术有限公司 Application server distribution method and device

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5898672A (en) * 1994-11-11 1999-04-27 Nokia Telecommunications Oy Overload prevention in a telecommunication network node
CN1918884A (en) * 2004-02-09 2007-02-21 诺基亚公司 Method and system for transmitting a multimedia message to multiple recipients.
CN101005695A (en) * 2006-01-18 2007-07-25 华为技术有限公司 Method and system for connecting contlict aviodance in radio communication
CN101110756A (en) * 2006-07-18 2008-01-23 华为技术有限公司 Application server distribution method and device

Also Published As

Publication number Publication date
CN101645825A (en) 2010-02-10

Similar Documents

Publication Publication Date Title
CN101277175B (en) Method and device for improving conversation starting protocol server performance
US8086709B2 (en) Method and apparatus for distributing load on application servers
CN101433019B (en) Method and apparatus for SIP message prioritization
CN110933180B (en) Communication establishment method, device, load equipment and storage medium
US8284661B2 (en) Load balancing session initiation protocol (SIP) servers
US7970828B2 (en) Liveness monitoring in a publish/subscribe messaging system
US7738650B2 (en) Systems and methods for scalable hunt-group management
US6829634B1 (en) Broadcasting network
US20090106389A1 (en) Sharing Multimedia
US20050044127A1 (en) Dynamic load distribution within a session initiation protocol network
WO2005114906A1 (en) Method and system for getting the state of sip network nodes
US9288174B2 (en) Page-mode messaging
EP2282460B1 (en) Document transmission realizing method, apparatus and user device for message business
WO2015180570A1 (en) Data channel establishment method and communications device
CN101645825B (en) Method, system and SIP entity for overload processing
CN102523531A (en) Access entity which processes session in video on demand system and method thereof
US7984110B1 (en) Method and system for load balancing
CN103404106A (en) SIP message transmission and receiving system and method
CN103828322B (en) Media data transmission method and device
CN109088828A (en) server overload control method and system
CN112788348A (en) On-demand method, device, equipment, system and storage medium
US8219610B2 (en) Content providing system, monitoring server, and SIP proxy server
CN112637258A (en) Data processing method and system
KR20060084327A (en) Method for transmitting data in multimedia system
EP3854044A1 (en) Methods of handling an overload situation of a session initiation protocol, sip node in a telecommunication network, as well as related sip nodes

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20201126

Address after: Building 2, No. 3, Fuqian Road, Hailing District, Taizhou City, Jiangsu Province

Patentee after: Taizhou Haitong Asset Management Co.,Ltd.

Address before: Unit 2414-2416, main building, no.371, Wushan Road, Tianhe District, Guangzhou City, Guangdong Province

Patentee before: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd.

Effective date of registration: 20201126

Address after: Unit 2414-2416, main building, no.371, Wushan Road, Tianhe District, Guangzhou City, Guangdong Province

Patentee after: GUANGDONG GAOHANG INTELLECTUAL PROPERTY OPERATION Co.,Ltd.

Address before: 518129 Bantian HUAWEI headquarters office building, Longgang District, Guangdong, Shenzhen

Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd.