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.