msg_parser.xml 3.3 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
  3. "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
  4. <section id="msg_parser" xmlns:xi="http://www.w3.org/2001/XInclude">
  5. <sectioninfo>
  6. <revhistory>
  7. <revision>
  8. <revnumber>$Revision$</revnumber>
  9. <date>$Date$</date>
  10. </revision>
  11. </revhistory>
  12. </sectioninfo>
  13. <title>The SIP Message Parser</title>
  14. <para>
  15. In this section we will discuss internals of the <acronym>SIP</acronym>
  16. message header parser implemented in the server. Message parsing is
  17. very important and one of the most time consuming operations of a
  18. <acronym>SIP</acronym> server. We have been trying to make the parser
  19. as fast as possible.
  20. </para>
  21. <para>
  22. A header field parser can be either in the server core or in a
  23. module. By convention, parser that is needed by the core itself or is
  24. needed by at least two modules will be in the core. Parsers contained
  25. in modules will be not described in this section.
  26. </para>
  27. <para>
  28. There is a <filename>parser</filename> subdirectory that contains all
  29. the parsers and related stuff.
  30. </para>
  31. <para>
  32. The following parsers can be found under <filename>parser</filename>
  33. subdirectory:
  34. </para>
  35. <section id="sip_msg_structure">
  36. <title>Structure of a <acronym>SIP</acronym> Message</title>
  37. <para>
  38. A <acronym>SIP</acronym> message consists of message header and
  39. optional message body. The header is separated from the body with
  40. a empty line (containing CRLF only).
  41. </para>
  42. <para>
  43. Message header consists of the first line and one or more header
  44. fields. The first line determines type of the message. Header
  45. fields provide additional information that is needed by clients and
  46. servers to be able to process the message.
  47. </para>
  48. <para>
  49. Each header field consists of header field name and header field
  50. body. Header field name is delimited from header field body by a
  51. colon (":"). For example, "Server: SIP Express Router" - in this
  52. case "Server" is header field name and "SIP Express Router" is
  53. header field body.
  54. </para>
  55. </section> <!-- sip-msg-structure -->
  56. <section id="parser_structure">
  57. <title>Parser Structure</title>
  58. <para>
  59. The server implements what we call <emphasis>incremental
  60. parsing</emphasis>. It means that a header field will be not
  61. parsed unless it is really needed. There is a minimal set of
  62. header that will be parsed every time. The set includes:
  63. <itemizedlist>
  64. <listitem>
  65. <para>
  66. The first line - the server must know if the message is
  67. request or response
  68. </para>
  69. </listitem>
  70. <listitem>
  71. <para>
  72. Via header field - Via will be needed for sure. We must
  73. add ourself to Via list when forwarding the message.
  74. </para>
  75. </listitem>
  76. </itemizedlist>
  77. </para>
  78. <xi:include href="fline_parser.xml"/>
  79. <xi:include href="hfname_parser.xml"/>
  80. <xi:include href="to_parser.xml"/>
  81. <xi:include href="from_parser.xml"/>
  82. <xi:include href="cseq_parser.xml"/>
  83. <xi:include href="event_parser.xml"/>
  84. <xi:include href="expires_parser.xml"/>
  85. <xi:include href="via_parser.xml"/>
  86. <xi:include href="contact_parser.xml"/>
  87. <xi:include href="digest_parser.xml"/>
  88. </section> <!-- parser-organization -->
  89. </section>