CN101547222A - Method for transmitting SIP request history information in VoIp Network - Google Patents
Method for transmitting SIP request history information in VoIp Network Download PDFInfo
- Publication number
- CN101547222A CN101547222A CN200910136696A CN200910136696A CN101547222A CN 101547222 A CN101547222 A CN 101547222A CN 200910136696 A CN200910136696 A CN 200910136696A CN 200910136696 A CN200910136696 A CN 200910136696A CN 101547222 A CN101547222 A CN 101547222A
- Authority
- CN
- China
- Prior art keywords
- sip
- history
- header field
- info
- 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.)
- Granted
Links
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
Method for transmitting SIP request history information in VoIP network is as follows: 1 defining extended parameters digest for History-Info header 2 when a SIP application receives SIP request, SIP application adds the history information in header, then computes abstract information of the header and then puts it in digest parameter, forwards the SIP request to next hop; 3 SIP application of next hop extracts abstract information carried by digest parameter from header, then computes abstract information of header again, determines if the header information is credible according to abstract information. The method of the invention computes abstract of request history information for SIP message, thereby effectively avoids problem that the request history information is forged, falsified, deleted and rearranged, enables independence for safe network from TLS so that the function can be applied in ordinary IP network.
Description
Technical field
The present invention relates to the communications field, a kind of specifically in voip network the method for transmitting SIP request history information.
Background technology
Session initiation protocol (Session Initiation Protocol, Session Initiation Protocol) is the signaling control protocol of supporting Multimedia session that IETF (Internet engineering duty group) proposes, be mainly used in the signaling control that realizes on the IP network, the voice conversation process that comprises foundation, management and stop participating in by in many ways.Session Initiation Protocol has been used for reference agreements such as HTTP, SMTP, supports the agency, is redirected and registers functions such as consumer positioning, supports that the user moves.By cooperating Session Initiation Protocol support voice, video, data, E-mail, state, IM, chat, recreation etc. with agreements such as RTP/RTCP, SDP, RTSP and DNS.
Session Initiation Protocol is a text based application layer control protocol, is independent of bottom host-host protocol TCP/UDP/SCTP.Session Initiation Protocol is divided into request and responds two types, and request comprises types such as REGISTER, INVITE, ACK, BYE and OPTION.The basic network element of Session Initiation Protocol comprises UA (User Agent, user agent), Proxy (acting server), Registrar (registrar) and Redirect Server (Redirect Server) etc.
VoIP (Voice over Internet Protocol) is meant that the sound signal of will simulate is after overcompression and package, form with data packet is carried out the transmission of speech sound signal at the environment of IP network, the meaning of popular Internet Protocol telephone just, the networking telephone or abbreviation IP phone.The basic principle of VoIP is: the compression algorithm by voice is compressed processing to encoded speech data, then these speech datas are packed by the TCP/IP standard, through IP network packet is delivered to reception ground, again these VoPs are stringed together, through after the decompression processing, revert to original voice signal, thereby reach the purpose that transmits voice by the Internet.
TLS (Transport Layer Security, Transport Layer Security) is based on a kind of agreement of SSL (secure port layer, Secure Socket Layer).SSL is that design is used for protecting webpage communication, and is applied to now in most browsers.TLS is more general than SSL, and it can be used to protect the reliable connection of any kind.TLS provides the integrality and the confidentiality of data for reliable connection the (connecting as a TCP).TLS comprises two-layer: TLS shake hands the layer (TLS handshake layer) and a TLS recording layer (TLS record layer).The TLS layer of shaking hands is handled the authentication of peer users, has used public keys and certificate at this one deck, and the key of negotiation algorithm and encryption actual data transfer.The encryption of TLS recording layer deal with data, it uses the algorithm of a symmetry usually, and the key of this algorithm is produced by the value that the layer of shaking hands provides.TLS is the safety measure of a hop-by-hop (hop by hop), in the application of SIP, and SIP entity of TLS protection and and its information exchange between another entity of a long-jump apart.
Provide the mode of historical requests record to be illustrated in fig. 1 shown below in the existing SIP network.The groundwork process is as follows:
1. user agent 1 sends an INVITE and asks acting server 1;
2. acting server 1 is transmitted this INVITE and is asked acting server 2, and acting server 2 increases the information of acting server 1 and acting server 2 in the History-Info header field in the INVITE request before forwarding; With Fig. 1 is example, increases following information in the History-Info header field in the INVITE request:
<sip:Bob@Pl.example.com>；index＝1，
<sip:Bob@P2.example.com>；index＝1.1；
Increase＜sip:User2@UA2.example.com in the History-Info header field of the INVITE request that is forwarded to user agent 2 〉; Index=1.1.1,
Increase＜sip:User3@UA3.example.com in the History-Info header field of the INVITE request that is forwarded to user agent 3 〉; Index=1.1.2,
Increase＜sip:User4@UA4.example.com in the History-Info header field of the INVITE request that is forwarded to user agent 4 〉; Index=1.1.3;
4. when user agent 2, user agent 3,4 pairs of above-mentioned INVITE request responding of user agent when all being unsuccessful or unavailable, acting server 2 sends one 480 response to acting server 1, each user agent's that increase was attempted in the 3rd step in the History-Info header field of 480 responses information and failure cause etc.; With Fig. 1 is example, user agent 2, user agent 3,4 pairs of INVITE request responding of user agent all are unsuccessful or unavailable, at this moment, acting server 2 sends one 480 response to acting server 1, and increase information is as follows in the History-Info header field of 480 responses:
<sip:User2@UA2.example.com？Reason＝SIP；\
cause＝408；text＝″RequestTimeout″>；index＝1.1.1，
<sip:User3@UA3.example.com？Reason＝SIP；\
cause＝487；text＝″Request?Terminated″>；index＝1.1.2，
<sip:User4@UA4.example.com？Reason＝SIP；\
cause＝603；text＝″Decline″>；index＝1.1.3；
5. receive this 480 when response when acting on behalf of server 1, acting server 1 detect INVITE another route approach---the user agent 5, so acting server 1 is transmitted to user agent 5 to this INVITE request.In the History-Info header field of this INVITE request, increase user agent 5 information; With Fig. 1 is example, and acting server 1 is transmitted to user agent 5 to this INVITE request, and increase information is as follows in the History-Info header field of the INVITE request that is forwarded to user agent 5:
<sip:User2@UA2.example.com？Reason＝SIP；cause＝408；\
text＝″RequestTimeout″>；index＝1.1.1，
<sip:User3@UA3.example.com？Reason＝S?IP；cause＝487；\
text＝″Request?Terminated″>；index＝1.1.2，
<sip:User4@UA4.example.com？Reason＝SIP；cause＝603；\
text＝″Decline″>；index＝1.1.3
<sip:User5@UA5.example.com>；index＝1.2；
6. user agent's 5 transmissions 200 OK respond to acting server 1, and acting server 1 is transmitted to user agent 1 to this 200 OK response, and user agent 1 sends ACK to user agent 5, sets up this call session between user agent 1 and user agent 5.
Though the History-Info header field provides the record of request history information, but because Session Initiation Protocol is based on the agreement of text, represent that with textual form the morphology of message and syntactic analysis are fairly simple, be very easy to the victim imitation, distort, illegally utilize.The History-Info header field also has following several defective:
● an incredible application program may be inserted the request history information clauses and subclauses of a forgery.
● an incredible application program may have been reset request history information.
● an incredible application program may be deleted some request history information clauses and subclauses.
Therefore in RFC4244, having proposed the History-Info header field must transmit in this class secure network of TLS.If do not use TLS, then must before transmitting, delete the History-Info header field; Perhaps, require the client user to act on behalf of and initiate the request that this comprises the History-Info header field by the approach of safety to being redirected this request message.
But because TLS network construction cost height, large-scale application has not just caused the mechanism of History-Info header field not widely apply in common IP network yet.
Summary of the invention
At the defective that exists in the prior art, the object of the present invention is to provide a kind of in voip network the method for transmitting SIP request history information, by being the computes abstract of request history information of sip message, can effectively evade problems such as request history information is forged, distorts, deletes and rearranges, and can break away from dependence to this class secure network of TLS, this function can be employed in common IP network.
For reaching above purpose, the technical scheme that the present invention takes is:
A kind of in voip network the method for transmitting SIP request history information, it is characterized in that: its concrete steps are:
Of the present invention in voip network the method for transmitting SIP request history information, by being the computes abstract of request history information of sip message, can effectively evade problems such as request history information is forged, distorts, deletes and rearranges, and can break away from dependence to this class secure network of TLS, this function can be employed in common IP network.
Description of drawings
The present invention has following accompanying drawing:
The flow process of record request historical record in the existing IP network of Fig. 1;
Fig. 2 the present invention program schematic diagram;
Fig. 3 embodiment 1: through the session flow process of Redirect Server and acting server;
Fig. 4 embodiment 2: serial fork session flow process.
Embodiment
Below in conjunction with accompanying drawing the present invention is described in further detail.
Fig. 2 be of the present invention in voip network the method for transmitting SIP request history information, the present invention is by expanding existing SIP header field, a kind of method of in common IP network the History-Info header field being protected is provided, has made the History-Info header field in common IP network, to transmit; The message flow of extended mode provided by the invention and present SIP network does not conflict, can exist simultaneously, and replenish as the fine of existing procedure, use the method that a kind of historical information of record request more flexibly is provided for SIP, make its restriction of having broken away from the TLS network, expanded the application scenarios of the request history information function of sip message greatly.Method of the present invention is used on the basis of RFC4244 (An Extension to theSession Initiation Protocol (SIP) for Request HistoryInformation) definition, and practice is in the message flow of SIP network, the History-Info header field is to define in RFC4244, but this patent is not limited to RFC4244.Defined the optional spreading parameter of History-Info header field in RFC4244, this spreading parameter satisfies the generic-param form, and it is defined as follows:
History-Info＝″History-Info″HCOLON
hi-entry*(COMMA?hi-entry)
hi-entry＝hi-targeted-to-uri*(SEMI?hi-param)
hi-targeted-to-uri＝name-addr
hi-param＝hi-index/hi-extension
hi-index＝″index″EQUAL?1*DIGIT*(DOT?1*DIGIT)
hi-extension＝generic-param
The present invention has utilized this spreading parameter exactly, for the History-Info header field has defined a new spreading parameter digest.Specifically, its concrete steps are:
Step 3, the SIP of next jumping uses when receiving the SIP request of transmitting, at first from the History-Info header field, extract the summary info that the digest parameter is carried, from the History-Info header field, delete the digest parameter then, use the digest algorithm identical to recomputate the summary info of the full content that current History-Info header field comprises then with step 2, the summary info that the summary info that recalculates and digest parameter are carried compares, if comparative result unanimity, think that then this History-Info header field is believable, after this moment, current SIP application joined the History-Info header field to the information of oneself, the new summary info of the full content that the History-Info header field that makes new advances with digest algorithm calculating comprises, in new History-Info header field, increase the digest parameter then, described new summary info is put in the digest parameter; Transmitting current SIP asks the SIP of next jumping to use; If comparative result is inconsistent, think that then this History-Info header field is incredible, the incredible History-Info header field of deletion before transmitting SIP that current SIP asks next jumping and using, perhaps the SIP that jumps of request last uses and initiates again to ask and do not transmit.
The method of described calculating summary can adopt MD5 or SHA-1 algorithm.
Fig. 2 uses each step after the method for the invention for Fig. 1, specifically:
<sip:Bob@P1.example.com>；index＝1，
<sip:Bob@P2.example.com>；index＝1.1；
digest＝d41d8cd98f00b204e9800998ecf8427e
Increase＜sip:User2@UA2.example.com in the History-Info header field of the INVITE request that is forwarded to user agent 2 〉; Index=1.1.1,
digest＝Occ175b9c0f1b6a831c399e269772661
Increase＜sip:User3@UA3.example.com in the History-Info header field of the INVITE request that is forwarded to user agent 3 〉; Index=1.1.2,
digest＝900150983cd24fb0d6963f7d28e17f72
Increase＜sip:User4@UA4.example.com in the History-Info header field of the INVITE request that is forwarded to user agent 4 〉; Index=1.1.3;
digest＝f96b697d7cb7938d525a2f31aaf161dO
<sip:User2@UA2.example.com？Reason＝SIP；\
cause＝408；text＝″RequestTimeout″>；index＝1.1.1，
<sip:User3@UA3.example.com？Reason＝SIP；\
cause＝487；text＝″Request?Terminated″>；index＝1.1.2，
<sip:User4@UA4.example.com？Reason＝SIP；\
cause＝603；text＝″Decline″>；index＝1.1.3；
digest＝c3fcd3d76192e4007dfb496cca67e13b
<sip:User2@UA2.example.com？Reason＝SIP；cause＝408；\
text＝″RequestTimeout″>；index＝1.1.1，
<sip:User3@UA3.example.com？Reason＝SIP；cause＝487；\
text＝″Request?Terminated″>；index＝1.1.2，
<sip:User4@UA4.example.com？Reason＝SIP；cause＝603；\
text＝″Decline″>；index＝1.1.3
<sip:User5@UA5.example.com>；index＝1.2；
digest＝d174ab98d277d9f5a5611c2c9f419d9f
This shows that the summary info that spreading parameter digest carries is different and different along with History-Info header field content, can make things convenient for, judges accurately and fast by summary info whether this History-Info header field is credible.By being the computes abstract of request history information of sip message, can effectively evade problems such as request history information is forged, distorts, deletes and rearranges, and can break away from dependence to this class secure network of TLS, this function can be employed in common IP network.
The embodiment that Fig. 3 provides mainly describes according to the inventive method, the SIP session during through Redirect Server and acting server to the processing procedure of request history information.Concrete processing procedure is as shown in Figure 3:
1. user A initiates an INVITE request to user B, and this request at first is sent to Redirect Server.In this request, comprise the request historical record, and calculated a summary for this request historical record.
History-Info:<sip:bob@biloxi.example.com>；index＝1；\
digest＝6c652063616c6c7320746f2062652072
2. Redirect Server returns 302 responses, has comprised the current sip address of user B in the Contact header field of this response.In this response, can comprise entrained History-Info header field in the INVITE request.
History-Info:<sip:bob@biloxi.example.com>；index＝1；\
digest＝6c652063616c6c7320746f2062652072
3. user A generates an ACK request and sends to Redirect Server, finishes the process that is redirected.
4. user A uses the current sip address of user B to generate a new INVITE request, and this request is sent to acting server.After acting server receives the INVITE request, from the History-Info header field, extract the entrained summary of digest parameter, recomputate the summary of the request historical record in the former History-Info header field, and summary that newly calculates and the summary that carries are compared.After more qualified, in the History-Info header field of this INVITE request, increased the data entries of acting server, and put into the digest parameter for this request historical record has calculated a new summary.
History-Info:<sip:bob@biloxi.example.com？Reason＝SIP；cause＝302>\
text＝″Moved?Temporarily″>；index＝1，
<sip:bob@chicago.example.com>；index＝2；\
digest＝43b8fcb8c4d2bbb8f6c7ebc7f3b5c455
5. acting server is transmitted to user B to this INVITE request.After user B receives the INVITE request, from the History-Info header field, extract the entrained summary of digest parameter, recomputate the summary of the request historical record in the former History-Info header field, and summary that newly calculates and the summary that carries are compared.After more qualified, in this INVITE request, increased the data entries of user B, and put into the digest parameter for this request historical record has calculated a new summary.
History-Info:<sip:bob@biloxi.example.com？Reason＝SIP；cause＝302>\
text＝″Moved?Temporarily″>；index＝1，
<sip:bob@chicago.example.com>；index＝2，
<sip:bob@client.chicago.example.com>；index＝2.1；\
digest＝c4bfbleab5d8d6b7ala3d5e2b8f6caf5
The embodiment that Fig. 4 provides mainly describes according to the inventive method, in the session of SIP serial fork to the processing procedure of request history information, concrete processing procedure as shown in Figure 4:
1. the user A that is positioned at user agent 1 initiates an INVITE request to user B.This request at first is sent to acting server 1.
2. after acting server 1 receives the INVITE request, the data entries of user A and acting server 1 is joined in the History-Info header field, and put into the digest parameter for this request historical record has calculated a summary.Then this request is transmitted to one of them user agent (user agent 2) of user B.
History-Info:<sip:UserA@example.com>；index＝1，
<sip:UserA@ims.example.com>；index＝1.1；\
digest＝accbfcccelb9a9d2bbb8f6cfecd3a6bb
3. after transmitting the INVITE request, acting server 1 sends to user agent 1 for this INVITE request produces one 100 response.
4. user agent 2 receives INVITE request back and produces one 302 response to acting server 1, informs the sip address that user B is current.
5. after acting server 1 receives 302 responses, use the current sip address of user B, this INVITE request is transmitted to the user agent (user agent 3) of user B.In the History-Info header field of this INVITE request, increased user agent 3 data entries, delete former summary, and recomputate a new summary for this request history information.
History-Info:<sip:UserA@example.com>；index＝1，
<sip:UserA@ims.example.com？Reason＝SIP；\
cause＝302；text＝″Moved?Temporarily″>；index＝1.1，
<sip:UserB@example.com>；index＝1.2；\
digest＝205468652072756c657320666f722064
6. after user agent 3 receives the INVITE request, for this INVITE request produces one 180 response.
7. after acting server 1 receives 180 responses of user agent's 3 generations, this 180 response is transmitted to user agent 1.
8. hypothesis user agent 3 is unavailable, and it is overtime that re-send request may sends repeatedly the back, and acting server 1 continues the INVITE request is transmitted to another user agent (user agent 4) of user B.In the History-Info header field of this INVITE request, increased user agent 4 data entries, delete former summary, and recomputate a new summary for this request history information.
History-Info:<sip:UserA@example.com>；index＝1，
<sip:UserA@ims.example.com？Reason＝SIP；\
cause＝302；text＝″Moved?Temporarily″>；index＝1.1，
<sip:UserB@example.com？Reason＝SIP；cause＝480；\
text＝″Temporarily?Unavailable″>；index＝1.2，
<sip:UserC@example.com>；index＝1.3；\
digest＝d5d5b9e6b6a8c2b7d3c9b5bdccd8b6a8
9. user agent 4 is busy, for this INVITE request produces one 486 response.
10. after acting server 1 receives user agent 4 486 responses, produce an ACK and ask to user agent 4.
11. acting server 1 is transmitted to user agent 1 to user agent 4 486 responses.In this 486 response, comprised the History-Info header field in the INVITE request.
History-Info:<sip:UserA@example.com>；index＝1，
<sip:UserA@ims.example.com？Reason＝SIP；\
cause＝302；text＝″Moved?Temporarily″>；index＝1.1，
<sip:UserB@example.com？Reason＝SIP；cause＝480；\
text＝″Temporarily?Unavailable″>；index＝1.2，
<sip:UserC@example.com>；index＝1.3；\
digest＝d5d5b9e6b6a8c2b7d3c9b5bdccd8b6a8
12. after user agent 1 receives 486 responses, produce an ACK request, finish this INVITE request flow process.
In the foregoing description, be credible with the entrained summary info of each digest parameter be basic description.If the entrained summary info of each digest parameter is insincere, sip proxy server directly abandons this sip message, no longer continues to handle.When sip proxy server receives this type of insincere message, can produce error log and generate warning information, concrete fault processing flow process is not described in this patent.
Claims (1)
1. the method for a transmitting SIP request history information in voip network, it is characterized in that: its concrete steps are:
Step 1 is History-Info header field definition spreading parameter digest;
Step 2, when the SIP request is received in a SIP application, behind request history information adding History-Info header field, calculate the summary info of the full content that the History-Info header field comprises with digest algorithm, in the History-Info header field, increase the digest parameter then, described summary info is put in the digest parameter; Transmitting this SIP asks the SIP of next jumping to use;
Step 3, the SIP of next jumping uses when receiving the SIP request of transmitting, at first from the History-Info header field, extract the summary info that the digest parameter is carried, from the History-Info header field, delete the digest parameter then, use the digest algorithm identical to recomputate the summary info of the full content that current History-Info header field comprises then with step 2, the summary info that the summary info that recalculates and digest parameter are carried compares, if comparative result unanimity, think that then this History-Info header field is believable, after this moment, current SIP application joined the History-Info header field to the information of oneself, the new summary info of the full content that the History-Info header field that makes new advances with digest algorithm calculating comprises, in new History-Info header field, increase the digest parameter then, described new summary info is put in the digest parameter; Transmitting current SIP asks the SIP of next jumping to use; If comparative result is inconsistent, think that then this History-Info header field is incredible, the incredible History-Info header field of deletion before transmitting SIP that current SIP asks next jumping and using, perhaps the SIP that jumps of request last uses and initiates again to ask and do not transmit.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910136696XA CN101547222B (en) | 2009-05-14 | 2009-05-14 | Method for transmitting SIP request history information in VoIp Network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910136696XA CN101547222B (en) | 2009-05-14 | 2009-05-14 | Method for transmitting SIP request history information in VoIp Network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101547222A true CN101547222A (en) | 2009-09-30 |
| CN101547222B CN101547222B (en) | 2012-07-25 |
Family
ID=41194103
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200910136696XA Expired - Fee Related CN101547222B (en) | 2009-05-14 | 2009-05-14 | Method for transmitting SIP request history information in VoIp Network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101547222B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102143010A (en) * | 2010-08-24 | 2011-08-03 | 华为软件技术有限公司 | Method for detecting message revision, sender equipment and receiver equipment |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100466549C (en) * | 2006-08-30 | 2009-03-04 | 中国科学院计算技术研究所 | Method of identifing VOIP flow based on SIP protocol process performance |
| CN101039327A (en) * | 2007-04-24 | 2007-09-19 | 中兴通讯股份有限公司 | Method and system for supporting multiple services using SIP protocol |
-
2009
- 2009-05-14 CN CN200910136696XA patent/CN101547222B/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102143010A (en) * | 2010-08-24 | 2011-08-03 | 华为软件技术有限公司 | Method for detecting message revision, sender equipment and receiver equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101547222B (en) | 2012-07-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Campbell et al. | The message session relay protocol (MSRP) | |
| CN1838590B (en) | Method and system for supporting internet key exchange in SIP signal process | |
| JP5043392B2 (en) | Method for setting up a SIP communication session, system and computer program thereof | |
| JP5169362B2 (en) | Session information replication method, call control server for executing the method, and program for the method | |
| Mazurczyk et al. | Covert Channels in SIP for VoIP signalling | |
| Wang et al. | A dependable privacy protection for end-to-end VoIP via Elliptic-Curve Diffie-Hellman and dynamic key changes | |
| WO2011131051A1 (en) | Method and device for security communication negotiation | |
| CN101547222B (en) | Method for transmitting SIP request history information in VoIp Network | |
| KR101121230B1 (en) | Sip base voip service protection system and the method | |
| CN108924142A (en) | A kind of secure voice intercommunication means of communication based on Session Initiation Protocol | |
| WO2014000429A1 (en) | Method and device for realizing terminal mobile service in internet protocol (ip) multimedia subsystem architecture | |
| Chen et al. | Research on man-in-the-middle denial of service attack in sip voip | |
| Gongjian | The study and implementation of voip intelligent voice communication system based on SIP protocol | |
| Sonkar et al. | A review paper: security on voice over internet protocol from spoofing attacks | |
| CA2653663C (en) | Method for securing ip connections for network operator interconnections | |
| Chakraborty et al. | VoIP Protocol Fundamentals | |
| CN101640669B (en) | Method, system and device for SIP policy control authentication | |
| Ashouri et al. | VoIP performance comparison in wireless networks with different encryption methods | |
| JP2004363941A (en) | Relaying device with voice guidance function | |
| Negussie | Securing Confidentiality and Integrity of SIP Based VoIP System in Reduced Call Setup Time | |
| Campbell et al. | RFC 4975: The Message Session Relay Protocol (MSRP) | |
| CN114726958A (en) | Identity authentication method and device, electronic equipment and readable storage medium | |
| Singh et al. | Algorithm for Elimination of Clipping Effects and Ghost Ringing in SIP initiated IPSec based VoIP | |
| Kapoor et al. | Security on voice over Internet protocol from spoofing attacks | |
| Holmberg et al. | UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) |
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 | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20120725 Termination date: 20210514 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |