CN100556040C - A kind of method of sending and receiving of conversation launch protocol message - Google Patents
A kind of method of sending and receiving of conversation launch protocol message Download PDFInfo
- Publication number
- CN100556040C CN100556040C CNB2006100334332A CN200610033433A CN100556040C CN 100556040 C CN100556040 C CN 100556040C CN B2006100334332 A CNB2006100334332 A CN B2006100334332A CN 200610033433 A CN200610033433 A CN 200610033433A CN 100556040 C CN100556040 C CN 100556040C
- Authority
- CN
- China
- Prior art keywords
- message
- conversation launch
- launch protocol
- protocol message
- head
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention belongs to the communications field, a kind of method of sending and receiving of conversation launch protocol message is provided, described sending method comprises: A. is provided with conversation launch protocol message, comprises message separation head in the described conversation launch protocol message, and described message is separated head and comprised a separation opening flag; B. send described conversation launch protocol message.The present invention delimits message and separates by adding message separation head between sip message, has improved demarcation and the decoding efficiency of receiving terminal sip message decoder to sip message, having reduced decoding and having realized difficulty, has improved the SIP systematic function simultaneously.
Description
Technical field
The invention belongs to the communications field, relate in particular to a kind of method of sending and receiving of the conversation launch protocol message based on transmission control protocol.
Background technology
Session initiation Protocol (Session Initiation Protocol, SIP) be Interne engineering duty group (TheInternet Engineering Task Force, IETF) one of multimedia communications system framework agreement of Zhi Dinging, it is a text based application layer control protocol, is used to set up, revise and stops both sides or Multimedia session in many ways on the IP network.Session Initiation Protocol is independent of underlying protocol, be that its agreement itself can be based on transmission control protocol (Transmission Control Protocol, TCP), User Datagram Protoco (UDP) (User DatagramProtocol, UDP) and stream control transfer protocol (Stream Control Transport Protocol SCTP) waits transport layer protocol.Major part all was based on insecure UDP transport layer protocol transmission during present Session Initiation Protocol was used, but when message packet surpasses network MTU (Maximum Transmission Unit, MTU) time, the i.e. maximum UDP message length of the UDP message not being unpacked and can transmit under the situation, the transmitting terminal transport layer just must be unpacked to message, after receiving terminal just must be received all message fragments, could organize bag again, report application layer process.Because UDP's itself is unreliable, makes a certain fragment of message lose and will cause transmitting terminal must wait for that the application layer timer expiry just can resend.In case therefore the message packet length does not adopt UDP to carry out the transmission of data above MTU usually.Session Initiation Protocol requires to know that message packet surpasses MTU or do not knowing that message packet surpasses 1400 bytes under the situation of MTU that the transmission of Session Initiation Protocol must be adopted reliably that when transmit leg connection-oriented transport layer protocol carries out transfer of data, as TCP, SCTP etc.
Increasing and professional becoming increasingly abundant along with the SIP application, the information that needs in the business request information to carry also gets more and more, the length of sip message becomes more and more longer, particularly along with SIP and XML (eXtensible Markup Language, extend markup language) combination, the length of message has increased much especially.Therefore also more and more based on the realization of connection-oriented SIP such as TCP.
TCP is connection-oriented reliable transport layer protocol based on streaming service, and it has defined a series of mechanism and has guaranteed reliable orderly transmission of business datum between the communicating pairs, for example message retransmission mechanism etc.The data that it sends application-level request one by one, reliably, the orderly opposite equip. that sends to.Yet in TCP carrying application layer business, do not provide the demarcation between the different application layer data message or the function of separation, Session Initiation Protocol and all present agreements to the SIP expansion provide demarcation or the separation function to multiple messages when also all not being carried on TCP for sip message.This can't know easily that a sip message is to begin wherefrom and where finish after just making receiving terminal receive the byte stream that the opposite end sends over by the TCP layer, and the way of a solution is to learn that according to the information such as original position of the message body of the length of the message body of the specific header field indication of syntax format, the message of Session Initiation Protocol message and message syntax formal definition a sip message is to begin wherefrom and where finish in the prior art.Concrete handling process is as follows:
1, first byte of the application layer data of receiving from the opposite end is thought the starting position of a sip message.
2, from the starting position of sip message data stream is attempted decoding according to the syntax format of Session Initiation Protocol message:
If successfully and obtained some information (original position of the message body of the length of the message body of the specific header field indication of message and message syntax formal definition etc.) as previously mentioned 2.1 decode, receiving terminal just can be known the end position of message body according to these information so.
If 2.1a all data before the end position receive all and decode that receiving terminal is handled message according to Session Initiation Protocol so.
If 2.1b all data before the end position do not receive all that receiving terminal must wait for that all data before the end position all receive and decode so, according to Session Initiation Protocol message is handled again.
If 2.2 decoding failure, perhaps according to the information that has obtained can't accurate positioning end of message position, repeated attempt was handled after receiving terminal must be waited for again and receive more data so.Because must wait for more data, receiving terminal can be handled in the following manner:
2.2a abandon current decoded state, the untreated data of buffer memory are also decoded to message after receiving more data again.
2.2b the current decoded state of buffer memory continues decode procedure after more data is received in wait.
3, the next byte of the end position of a message is thought the starting position of next message, repeats second step from this original position.
In the implementation of 2.2a, because decoder can't be known the length and the end position of message, receiving terminal can only be decoded to the data that received.If current just do not have all to arrive in the buffering area of receiving terminal and decoder at the follow-up data of decode messages, decoder must be attempted decoding again after getting access to more data so.What this trial took place when the message bag is long is very frequent, attempts for the response speed that improves system needs also that usually the message fragment is carried out frequent decoding when the message packet length is smaller.Like this message fragment that receives is attempted the performance that decoding can reduce the SIP system repeatedly.
Adopt the mode of 2.2b to decode again to all message contents of having received at every turn, only need decode to the new data that the last time receives, but this kind decoder is realized very complicated, and the reliability of the resource occupation of the extra increase of buffer memory decoded state meeting system and reduction system.
Summary of the invention
The object of the present invention is to provide a kind of sending method of conversation launch protocol message, be intended to solve in the prior art when the original position of the message body of the length of the message body that does not obtain the specific header field indication of message and message syntax formal definition, the receiving terminal decoder is not known the end position of a sip message and is frequently attempted the decoding that decoding efficiency is low and the buffer memory decoded state causes that decoding causes and realize complicated problems.
Another object of the present invention is to provide a kind of method of reseptance of conversation launch protocol message.
The object of the present invention is achieved like this:
A kind of sending method of conversation launch protocol message, described method comprises the steps:
A., conversation launch protocol message is set, comprises message separation head in the described conversation launch protocol message, described message is separated head and is comprised a separation opening flag, and wherein adjacent two parts of cutting apart between the opening flag are conversation launch protocol message;
B. send described conversation launch protocol message.
Described message is separated the length that head further comprises conversation launch protocol message length information, this information of message separation front page, separates an optional parameters or a separation optional parameters.
Further comprise before the described steps A:
F. inquire about the ability information that can receiving terminal decode to described conversation launch protocol message.
Described step F further may further comprise the steps:
F11. the dynamic host configuration protocol DHCP server is provided for identifying the sub-option of the described ability information of receiving terminal;
F12. transmitting terminal sends query requests to the dynamic host configuration protocol DHCP server;
F13. the dynamic host configuration protocol DHCP server returns the response message that has described sub-option.
Described step F further may further comprise the steps:
F21. be provided for identifying the resource record types of the described ability information of receiving terminal;
F22. transmitting terminal sends the query requests of described resource record types to the domain name system DNS server;
F23. the domain name system DNS server returns and described resource record types corresponding response message.
Described step F further may further comprise the steps:
F31. be provided for identifying the header field or the message body type of the described ability information of receiving terminal;
F32. transmitting terminal sends the OPTIONS request to receiving terminal;
F33. receiving terminal returns the response message that carries described header field or message body type.
Described method further comprises the step of the ability information that can receiving terminal initiatively decode to described conversation launch protocol message to sender report self in message interaction process.
Can described receiving terminal carry by the unified resource sign URI parameter of expansion Contact header field or the parameter of Via header field the ability information that described conversation launch protocol message is decoded.
Described ability information comprises that message separates support information, and described message is separated support information and comprised and support and enable decoding to described conversation launch protocol message, support but do not enable the decoding of described conversation launch protocol message or do not support decoding to described conversation launch protocol message.
When described message is separated support information for supporting and when enabling decoding to described conversation launch protocol message, described ability information comprises that further the message of support separates the version of head, separates an opening flag or separate an opening flag length.
A kind of method of reseptance of conversation launch protocol message, described method comprises the steps:
A. receive conversation launch protocol message, comprise message separation head in the described conversation launch protocol message, described message is separated head and is comprised a separation opening flag, and wherein adjacent two parts of cutting apart between the opening flag are conversation launch protocol message;
B. separate head according to described message, described conversation launch protocol message is decoded.
Described step B further may further comprise the steps:
B1. in the described conversation launch protocol message that receives, find after two adjacent message separate an opening flag, the message content that two message are separated between the opening flag is decoded.
Described message is separated head and is further comprised the conversation launch protocol message length information.
Described step B further may further comprise the steps:
B2. read the message content of respective length according to message-length information in the separation head, described message content is decoded.
Described message is separated the length information that head further comprises this information of message separation front page, separates an optional parameters or a separation optional parameters.
The present invention delimits message and separates by adding message separation head between sip message, has improved demarcation and the decoding efficiency of receiving terminal sip message decoder to sip message, having reduced decoding and having realized difficulty, has improved the SIP systematic function simultaneously.
Description of drawings
Fig. 1 is the sip message form schematic diagram that adds after message is separated head;
Fig. 2 is the one section byte stream segment exemplary plot that adds after message is separated head;
Fig. 3 is the realization flow figure of first embodiment provided by the invention;
Fig. 4 is the realization flow figure that adopts OPTIONS inquiry opposite end ability;
Fig. 5 is the realization flow figure of second embodiment provided by the invention.
Embodiment
In order to make purpose of the present invention, technical scheme and advantage clearer,, the present invention is further elaborated below in conjunction with drawings and Examples.Should be appreciated that specific embodiment described herein only in order to explanation the present invention, and be not used in qualification the present invention.
The present invention separates message by add message separation head between sip message, has improved demarcation and the decoding efficiency of receiving terminal sip message decoder to sip message.
Fig. 1 shows the sip message form that adds after message is separated head.
It is a special code stream that comprises one or more bytes fixing or that the intercommunication both sides make an appointment that message is separated head, comprises and separates an opening flag.Below be a simple 0xC0C0 of separation:
After receiving terminal receives data flow by Transmission Control Protocol, just can at first search and separate an opening flag, find and continue to search a next message separation opening flag after message is separated an opening flag, adjacent two parts of separating between the leader will are sip message.Like this, the message sink end is determined a complete sip message by the search characteristics byte, improves the decoding efficiency to sip message.
More excellent, message is separated head can also comprise following information:
1, message is separated the version of head, and for example version number is 0;
2, message-length indication, it is the signless integer value of a regular length, perhaps adopt ASN.1 (AbstractSyntax Notation one, abstract syntax notation one) integer value behind the technology for encoding such as integer coding, the message sink end finds message and separates the starting position of determining sip message behind the opening flag, determine the end position of sip message then according to message-length, the data flow that the retrieval that receiving terminal does not need not stop is as previously mentioned received realizes demarcation to sip message further having improved the decoding efficiency to sip message to obtain next separator;
3, separate an optional parameters, for example separate an error-checking code or be used to finish the parameter of message being carried out functions such as ciphered compressed, TCP connection maintenance;
4, the length of separating optional parameters in the head, when there not being this parameter, it is 1 joint that acquiescence is separated an optional parameters.
In specific implementation, the implementor can carry out suitable screening and replacement etc. to above information as required, below is a typical head of separating:
One section byte stream segment more than Fig. 2 shows and adds behind the separation head, wherein 6 elements of dash area are the content that message is separated head, the part that message is separated before the head is the end part message content of previous sip message, begins the part message content for next sip message after the separation head.
As the first embodiment of the present invention, the sip message transmitting terminal is judging when the opposite end sends message the decoding of sip message being separated head is supported and enabled in the opposite end whether, if, message sending end generated message separation head and sends to the opposite end by TCP before sending each sip message so, and receiving terminal is separated head by message can disposable decoding after receiving a complete message to the demarcation of sip message.Otherwise message sending end only need send to the opposite end with message to be sent by the TCP connection, and receiving terminal is constantly attempted decoding to the packet that receives, and up to the end position that finds message, just decodes a complete message, as previously mentioned.
A typical case under present embodiment uses as shown in Figure 3, and to terminal b (user_b) initiation session, details are as follows for the specific implementation flow process by acting server (Proxy.domain_a.com, Proxy.domain_b.com) for terminal a (user_a):
1.user_a and user_b adopted DHCP respectively before registration (Dynamic HostConfiguration Protocol, DHCP) Cha Xun mode is dynamically obtained the information such as address, ability and intercommunication parameter of acting server Proxy.domain_a.com and Proxy.domain_b.com.
So in the record of Dynamic Host Configuration Protocol server, add the ability information whether acting server supports sip message is separated header decode, just this ability information of acting server can be returned to terminal in query script, terminal is using TCP and acting server just can make a strategic decision before carrying out intercommunication whether to send the sip message that has message separation.Defined form among the IETF document draft-lijun-dhc-clf-nass-option-01.txt, be designated 1 and 2 the parameter and the implication of each bit but only defined sub-option by DHCP inquiry back return information.Because its form has autgmentability very flexibly, so the implementor can carry more option information by defining more parameter.The new parameter of the present invention's definition is as follows:
SubOpt?Len Sub-option?Value
+-----+-----+-----.........................................----+
| TBD | N|SIP message is separated support information | version | separate an opening flag length | separate an opening flag |
+-----+-----+-----.........................................----+
Wherein, SubOpt is that (Internet Assigned NumbersAuthority IANA) distributes to the parameter type of this parameter in the internet numbering distribution committee, it is sub-option sign, can be 3 or 4 etc., but can not be existing 1 or 2, be (TBD) undetermined herein;
Len is the length of real messages;
Whether sip message is separated support information, promptly support to separate the sign that the sip message of head is decoded to containing message, and its value comprises support but do not enable, supports and enable and do not support three kinds of possibilities;
Version, the sip message of current support is separated the version of head;
Separate an opening flag length, sip message is separated an opening flag length;
Separate an opening flag, sip message is separated an opening flag, for example 0xC0C0.
The user can carry out suitable screening to above information as required, and it is multiplexing also can to carry out suitable value according to the relation between the parameter.
In another embodiment of the present invention, (Domain Name System, DNS) Cha Xun mode is obtained the opposite end and whether is supported and enable the ability information of sip message being separated header decode can also to pass through domain name system.RFC3263 has defined in the Session Initiation Protocol positioning service (the Service location by dns server, SRV) and title authority pointer (Naming Authority Pointer, NAPTR) two kinds of resource record (ResourceRecord, RR) the type mechanism of locating the Next Hop Server address and obtaining some intercommunication parameters, the present invention is provided with a kind of new resource record types SIP-MSG-SEPARATOR and is used for the ability information whether search purposes equipment supports sip message is separated header decode.(RecordData, RDATA) sip message that comprises is as previously described separated information such as support information, version, a separation opening flag length and a separation opening flag to the physical record data of this resource record.
In another embodiment of the present invention, the OPTIONS that can also define by Session Initiation Protocol before sending message inquires about the opposite end and whether supports and enable the decoding of sip message being separated head.As shown in Figure 4, in 200 OK response messages of OPTIONS request message, can or define a kind of new message body type and be used to return information such as sip message separation support information, version, a separation opening flag length and a separation opening flag by a newly-increased expansion header field.
The ABNF of expansion header field (Augmented Backus Normal Form, expansion Backus normal form) is defined as follows:
msg-separator-hdr-header＝″msg-separator″HCOLON?msg-separator-hdr-val*(COMMA?msg-separator-hdr-param)
msg-separator-hdr-val＝″enabled″/″disabled″/″unsupported″
msg-separator-hdr-param＝msg-separator-hdr-version/msg-separator-hdr-len/msg-separator-hdr-data
msg-separator-hdr-version＝″version″″＝″1*DIGIT
msg-separator-hdr-len＝″separator-len″″＝″1*DIGIT
msg-separator-hdr-data＝″separator″″＝″1*msg-separator-hdr-data-char
msg-separator-hdr-data-char＝DIGIT/″A″/″B″/″C″/″D″/″E″/″F″/″a″/″b″/″c″/″d″/″e″/″f″
Wherein, the value of msg-separator-hdr-val comprises that enabled (express support for and enable and separate the decoding of the sip message of head to containing message), disabled (express support for but do not enable and separate the decoding of the sip message of head to containing message) and unsupported (expression is not supported to separate the decoding of the sip message of head to containing message) three kinds may; When this parameter value was " enabled ", the value of msg-separator-hdr-ver, msg-separator-hdr-len and msg-separator-hdr-data was meaningful and can be used; When this parameter value was " disabled ", the value of msg-separator-hdr-ver, msg-separator-hdr-len and msg-separator-hdr-data was meaningful but can not be used; When this parameter value was " unsupported ", the value of msg-separator-hdr-ver, msg-separator-hdr-len and msg-separator-hdr-data was meaningless.
Msg-separator-hdr-ver represents that this URI resource supports sip message to separate the highest version of head, and default value is not 1 when having this parameter.
Msg-separator-hdr-len represents the byte number of the separation opening flag that this URI resource suggestion is used.As this parameter but during printenv msg-separator-hdr-data, separate an opening flag and be the designated word joint number, each byte is the special separation opening flag of 0xC0.
Msg-separator-hdr-data represents the separation opening flag that this URI resource suggestion is used.As this parameter but during printenv sip-msg-separator-hdr-len, the length of separating the opening flag length of parameter is thus determined.
For example:
msg-separator：enabled；version＝2；separator-len＝2；separator＝C0C0
Expression message sink end support is also enabled and is separated the decoding of the sip message of head to containing message, and its message header version number is 2, and separating the head length degree is 2 bytes, and separating a beginning label is 0xC0C0.
msg-separator：disabled
Expression message sink end support but do not enable and separate the decoding of the sip message of head to containing message.
msg-separator：unsupported
Expression message sink end is not supported to separate the decoding of the sip message of head to containing message.
When defining new message body type and being used to return foregoing sip message and separating support information, version, a separation opening flag length and separate information such as an opening flag, message body content and formal definition are as follows:
MIME media type name (MIME medium type): application
MIME subtype name (MIME medium subtype): message-separator
Required parameters (mandatory parameter): none (nothing)
Optional parameters (optional parameters): none (nothing)
Encoding scheme coded system: ABNF (text ABNF mode)
According to above rule, the ABNF coded format of a message body msg-separator-body is defined as follows:
msg-separator-body＝msg-separator-body-param
*(CRLF?msg-separator-body-param)
msg-separator-body-param＝msg-separator-body-flag
/msg-separator-body-ver
/msg-separator-body-len
/msg-separator-body-data
msg-separator-body-flag＝″flag″″＝″msg-separator-body-val
msg-separator-body-val＝″enabled″/″disable?d″/″unsupported″
msg-separator-body-ver＝″ver″＝″1*DIGIT
msg-separator-body-len＝″separator-len″″＝″1*DIGIT
msg-separator-body-data＝″separator″″＝″1*msg-separator-body-data-char
msg-separator-body-data-char＝DIGIT/″A″/″B″/″C″/″D″/″E″/″F″
/″a″/″b″/″c″/″d″/″e″/″f″
Wherein, the value of msg-separator-body-val comprises that enabled, disabled and unsupported three kinds may; When this parameter value was " enabled ", the value of msg-separator-body-ver, msg-separator-body-len and msg-separator-body-data was meaningful and can be used; When this parameter value was " disabled ", the value of msg-separator-body-ver, msg-separator-body-len and msg-separator-body-data was meaningful but can not be used; When this parameter value was " unsupported ", the value of msg-separator-body-ver, msg-separator-body-len and msg-separator-body-data was meaningless.
Msg-separator-body-ver represents that this URI resource supports sip message to separate the highest version of head, and default value is not 1 when having this parameter.
Msg-separator-body-len represents the byte number of the separation opening flag that this URI resource suggestion is used.As this parameter but to separate an opening flag during printenv msg-separator-body-data be the designated word joint number, each byte is the special separation opening flag of 0xC0.
Msg-separator-body-data represents the separation opening flag that this URI resource suggestion is used.As this parameter but the length of separating an opening flag during printenv msg-separator-body-len thus the length of parameter determine.
For example:
Content-Type：application/message-separator
flag＝enabled
ver＝2
separator-len＝2
separator＝C0C0
Expression message sink end support is also enabled and is separated the decoding of the sip message of head to containing message, and its version number is 2, and separating the head length degree is 2 bytes, and separating a beginning label is 0xC0C0.
2.user_a and user_b initiates login request message (REGISTER) to Proxy.domain_a.com and Proxy.domain_b.com respectively.
Whether the present invention carries in the URI of the Contact header field of REGISTER message parameter and self supports and enable and separate the ability information that the sip message of head is decoded to containing message, and whether Proxy.domain_b.com just can send the sip message that contains message separation according to its ability information of the parameter acquiring in its registered address and decision-making when called user_b sends out message like this.
3.Proxy.domain_a.com and Proxy.domain_b.com is respectively 200 success response signal (OK) to user_a and user_b return state sign indicating number.
4.user_a ability information according to the Proxy.domain_a.com that gets access to, just can local decision-making whether send the sip message that contains message separation head, send call setup request message (INVITE), the user_b in request call domain_b.com territory to Proxy.domain_a.com.
Whether support and enable the ability information that the sip message that contains message separation head is decoded 5.Proxy.domain_a.com adopt OPTIONS to inquire about Proxy.domain_b.com.
6.Proxy.domain_b.com whether to Proxy.domain_a.com return state sign indicating number is 200 success response message, and carry and support and enable and separate the ability information that the sip message of head is decoded to containing message.
7.Proxy.domain_a.com whether get access to Proxy.domain_b.com supports and enables after containing message and separating the ability information that the sip message of head decodes, just can local decision-making whether send the sip message that contains message separation head, and transmit INVITE to Proxy.domain_b.com.
8.Proxy.domain_b.com determine according to the parameter in the user_b registered address whether user_b supports and enable the ability that the sip message that contains message separation head is decoded, whether local decision-making sends contains the sip message that message is separated head, and transmits INVITE to user_b.
9.user_b be 180 Temporary Response message (Ringing) to Proxy.domain_b.com return state sign indicating number.
……
In follow-up signalling interactive process, identical about ability information how to obtain the opposite end and the principle that sends corresponding message, repeat no more.
The present invention is in the repeating process of the transmission of REGISTER message and INVITE, each equipment can be by the expansion Contact header field the parameter of URI parameter, Via header field and some other some header fields relevant or the parameter in the header field with SIP physical address or sign carry and self whether support and enable and separate the ability information that the sip message of head is decoded containing message, so just can in follow-up message sink process, be convenient to the opposite end and determine whether to send the sip message that contains message separation.The ABNF of this expansion sip message URI parameter is described below:
uri-parameter＝transport-param/user-param/method-param/ttl-param/maddr-param/lr-param/sip-msg-separator-param/other-param
Wherein sip-msg-separator-param is the parameter of the present invention's expansion, and remainder is the definition of uri-parameter among the RFC3261, and the present invention quotes at this, repeats no more.
sip-msg-separator-param＝sip-msg-separator-flag/sip-msg-separator-version/sip-msg-separator-len/sip-msg-separator-data
sip-msg-separator-param-flag＝″msg-separator-flag″″＝″sip-msg-separator-val
sip-msg-separator-val＝″enabled″/″disabled″/″unsupported″
sip-msg-separator-version＝″msg-separator-ver″″＝″1*DIGIT
sip-msg-separator-len＝″msg-separator-len″″＝″1*DIGIT
sip-msg-separator-data＝″msg-separator″″＝″1*sip-msg-separator-data-char
sip-msg-separator-data-char＝DIGIT/″A″/″B″/″C″/″D″/″E″/″F″/″a″/″b″/″c″/″d″/″e″/″f″
Similar about the parameter among the msg-separator-body-param in the definition of each parameter among the sip-msg-separator-param and the precedent, repeat no more.
For example:
sip：proxy.example.com；msg-separator-flag＝enabled
Expression sip:proxy.example.com entity support is also enabled and is separated the sip message of head and decode containing message, and it separates front page this shop and be defaulted as 1, separates the head length degree and is defaulted as 2 bytes, separates a beginning label and is defaulted as 0xC0C0.
Below for having some common SIP header fields of spreading parameter:
Record-Route：<sips:ssl.example.com；lr；msg-separator-flag＝enabled>
Route：<sips:ssl.example.com；lr；msg-separator-flag＝enabled>
Contact：<sips:alice@client.atlanta.example.com；msg-separator-flag＝enabled>
Refer-To：sip:alice@atlanta.example.com；msg-separator-flag＝enabled
In-Reply-To：70710@saturn.bell-tel.com；msg-separator-flag＝enabled
Reply-To：Bob<sip:bob@biloxi.com；msg-separator-flag＝enabled>
Service-Route：sip:orig@scscfl.example.com；msg-separator-flag＝enabled
Service-Route：sip:orig@scscfl.example.com；lr；msg-separator-flag＝enabled
Path：sip:pcscfl.example.com；lr；msg-separator-flag＝enabled
The ABNF of corresponding expansion sip message Via header field parameter is described below:
Via：SIP/2.0/TCPclient.atlanta.example.com：5061；branch＝z9hG4bK7；msg-separator-flag＝enabled
In a preferred embodiment of the present invention, whether transmitting terminal obtains the opposite end and supports and enable and preserve after message is separated the ability information that the sip message of head decodes containing, before the opposite end sends message, just can directly make a strategic decision whether to send in next time and contain the sip message that message is separated, and not need to send before the message at every turn again to opposite end query capability information.
As the second embodiment of the present invention, the sip message transmitting terminal does not judge the ability that the sip message that contains message separation head is decoded is supported and enabled in the opposite end whether, ability according to self sends the sip message that message separation head is arranged or do not have message separation head, and the message that sends by sip message receiving terminal adaptive reception message sending end, comprising a separation opening flag, a separation optional parameters and conversation launch protocol message length information with message separation head below is that example describes, concrete decoding realization flow as shown in Figure 5, details are as follows:
In step S501, the sip message receiving terminal judges that whether the current byte stream of receiving is to separate an opening flag with message to begin (for example 0xC0C0), is execution in step S502 then, otherwise execution in step S505;
In step S502, receiving terminal is done corresponding processing to a separation optional parameters of supporting according to related specifications to after separating an optional parameters decoding;
The present invention is undefined any optional parameters temporarily, but along with increasing of using, might need provides more enhancement function by optional parameters.Each optional parameters all will be by the document definition of definition optional parameters to mode and other operation of receiving terminal processing messages.
In step S503, begin from the byte stream buffering area of decoder, to read the message content of respective length according to sip message length first byte behind message header of separating indication in the head, described message content is decoded, and handle according to the Session Initiation Protocol standard back then;
In step S504, from the byte stream buffering area of decoder, read the subsequent words throttling and repeat step 501;
In step S505, constantly read the byte stream in the buffering area, decode up to decoding a complete sip message as the repeated attempt that background technology is introduced, continue execution in step S504.
The above only is preferred embodiment of the present invention, not in order to restriction the present invention, all any modifications of being done within the spirit and principles in the present invention, is equal to and replaces and improvement etc., all should be included within protection scope of the present invention.
Claims (15)
1, a kind of sending method of conversation launch protocol message is characterized in that, described method comprises the steps:
A., conversation launch protocol message is set, comprises message separation head in the described conversation launch protocol message, described message is separated head and is comprised a separation opening flag, and wherein adjacent two parts of cutting apart between the opening flag are conversation launch protocol message;
B. send described conversation launch protocol message.
2, the sending method of conversation launch protocol message as claimed in claim 1, it is characterized in that described message is separated the length that head further comprises conversation launch protocol message length information, this information of message separation front page, separates an optional parameters or a separation optional parameters.
3, the sending method of conversation launch protocol message as claimed in claim 1 is characterized in that, further comprises before the described steps A:
F. inquire about the ability information that can receiving terminal decode to described conversation launch protocol message.
4, the sending method of conversation launch protocol message as claimed in claim 3 is characterized in that, described step F further may further comprise the steps:
F11. the dynamic host configuration protocol DHCP server is provided for identifying the sub-option of the described ability information of receiving terminal;
F12. transmitting terminal sends query requests to the dynamic host configuration protocol DHCP server;
F13. the dynamic host configuration protocol DHCP server returns the response message that has described sub-option.
5, the sending method of conversation launch protocol message as claimed in claim 3 is characterized in that, described step F further may further comprise the steps:
F21. be provided for identifying the resource record types of the described ability information of receiving terminal;
F22. transmitting terminal sends the query requests of described resource record types to the domain name system DNS server;
F23. the domain name system DNS server returns and described resource record types corresponding response message.
6, the sending method of conversation launch protocol message as claimed in claim 3 is characterized in that, described step F further may further comprise the steps:
F31. be provided for identifying the header field or the message body type of the described ability information of receiving terminal;
F32. transmitting terminal sends the OPTIONS request to receiving terminal;
F33. receiving terminal returns the response message that carries described header field or message body type.
7, the sending method of conversation launch protocol message as claimed in claim 3, it is characterized in that described method further comprises the step of the ability information that can receiving terminal initiatively decode to described conversation launch protocol message to sender report self in message interaction process.
8, the sending method of conversation launch protocol message as claimed in claim 7, it is characterized in that can described receiving terminal carry by the unified resource sign URI parameter of expansion Contact header field or the parameter of Via header field the ability information that described conversation launch protocol message is decoded.
9, as the sending method of the described conversation launch protocol message of the arbitrary claim of claim 3 to 8, it is characterized in that, described ability information comprises that message separates support information, and described message is separated support information and comprised and support and enable decoding to described conversation launch protocol message, support but do not enable the decoding of described conversation launch protocol message or do not support decoding to described conversation launch protocol message.
10, the sending method of conversation launch protocol message as claimed in claim 9, it is characterized in that, when described message is separated support information for supporting and when enabling decoding to described conversation launch protocol message, described ability information comprises that further the message of support separates the version of head, separates an opening flag or separate an opening flag length.
11, a kind of method of reseptance of conversation launch protocol message is characterized in that, described method comprises the steps:
A. receive conversation launch protocol message, comprise message separation head in the described conversation launch protocol message, described message is separated head and is comprised a separation opening flag, and wherein adjacent two parts of cutting apart between the opening flag are conversation launch protocol message;
B. separate head according to described message, described conversation launch protocol message is decoded.
12, the method for reseptance of conversation launch protocol message as claimed in claim 11 is characterized in that, described step B further may further comprise the steps:
B1. in the described conversation launch protocol message that receives, find after two adjacent message separate an opening flag, the message content that two message are separated between the opening flag is decoded.
13, the method for reseptance of conversation launch protocol message as claimed in claim 11 is characterized in that, described message is separated head and further comprised the conversation launch protocol message length information.
14, the method for reseptance of conversation launch protocol message as claimed in claim 13 is characterized in that, described step B further may further comprise the steps:
B2. read the message content of respective length according to message-length information in the separation head, described message content is decoded.
15, the method for reseptance of conversation launch protocol message as claimed in claim 11 is characterized in that, described message is separated the length information that head further comprises this information of message separation front page, separates an optional parameters or a separation optional parameters.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100334332A CN100556040C (en) | 2006-01-26 | 2006-01-26 | A kind of method of sending and receiving of conversation launch protocol message |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100334332A CN100556040C (en) | 2006-01-26 | 2006-01-26 | A kind of method of sending and receiving of conversation launch protocol message |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101009696A CN101009696A (en) | 2007-08-01 |
| CN100556040C true CN100556040C (en) | 2009-10-28 |
Family
ID=38697825
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2006100334332A Expired - Fee Related CN100556040C (en) | 2006-01-26 | 2006-01-26 | A kind of method of sending and receiving of conversation launch protocol message |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100556040C (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102036232B (en) * | 2010-12-17 | 2015-12-09 | 中兴通讯股份有限公司 | A kind of base station data sending, receiving method and device |
| WO2017008203A1 (en) * | 2015-07-10 | 2017-01-19 | 华为技术有限公司 | Protocol frame transmission method, device, node apparatus and system |
-
2006
- 2006-01-26 CN CNB2006100334332A patent/CN100556040C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CN101009696A (en) | 2007-08-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10855585B2 (en) | Session initiation protocol stack optimisation | |
| EP1929712B1 (en) | Sip header reduction | |
| US8001189B2 (en) | Routing of network messages | |
| US6888828B1 (en) | System and method for providing at least one service obtained from a service network for a user in a packet switched communication network | |
| EP1266503B1 (en) | Processing network communication control messages | |
| KR100487124B1 (en) | method for processing session information of session initiation protocol system and recorded medium thereof | |
| Camarillo et al. | The session description protocol (SDP) grouping framework | |
| JP5043392B2 (en) | Method for setting up a SIP communication session, system and computer program thereof | |
| US20050111467A1 (en) | Method and apparatus for configuring and controlling network resources in content delivery with distributed rules | |
| US20050185672A1 (en) | IPv6/IPv4 translator | |
| CN106850681B (en) | Method and system for communicating messages | |
| JP2009105903A (en) | Employment of session service based on packet flow | |
| JP2007128503A (en) | Method of discovering network resource | |
| JP4927101B2 (en) | Method and system for characterizing heterogeneous communication nodes | |
| EP2245534B1 (en) | System and method for resolving extensions for the sip session policy framework | |
| Cha et al. | A mobility link service for ndn consumer mobility | |
| EP2068524A1 (en) | A method and a system for acquiring the transmission path of the sip message | |
| CN101090398A (en) | Detection of loops within a sip signalling proxy | |
| Camarillo | Compressing the Session Initiation Protocol (SIP) | |
| US20090106428A1 (en) | Service intermediary Addressing for real time composition of services | |
| CN100556040C (en) | A kind of method of sending and receiving of conversation launch protocol message | |
| KR100544195B1 (en) | Method and system of initiating session using session initiation protocol under mobile IPv6 | |
| Herrero et al. | Application layer | |
| Nesser et al. | Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents | |
| JP4839620B2 (en) | Call control system, call control method, and call control program |
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: 20091028 Termination date: 20150126 |
|
| EXPY | Termination of patent right or utility model |