Is SIP header fields are similar to HTTP header fields in both syntax and semantics? Also explain the Header Field Definitions? michaeldavid23 18-July-2008 02:15:36 PMComments www.scribd.com/doc/6544836/Sip-Error-Codes Posted by crouse www.scribd.com/doc/6544836/Sip-Error-Codes Posted by crouse www.faqs.org/rfcs/rfc3864.htm Posted by saqlain231 plz visit this site www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Posted by crouse yes & for header field explanation see link below http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Posted by Hash007 SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the syntax for message-header as described in [H4.2]. The rules for extending header fields over multiple lines, and use of multiple message-header fields with the same field-name, described in [H4.2] also apply to SIP. The Global-F | "600" ; Busy Everywhere | "603" ; Decline | "604" ; Does not exist anywhere | "606" ; Not Acceptable rules in [H4.2] regarding ordering of header fields apply to SIP, with the exception of Via fields, see below, whose order matters. Additionally, header fields which are hop-by-hop MUST appear before any header fields which are end-to-end. Proxies SHOULD NOT reorder header fields. Proxies add Via header fields and MAY add other hop-by-hop header fields. They can modify certain header fields, such as Max-Forwards (Section 6.23) and "fix up" the Via header fields with "received" parameters as described in Section 6.40.1. Proxies MUST NOT alter any fields that are authenticated. The header fields required, optional and not applicable for each method are listed in Table 4 and Table 5. The table uses "o" to indicate optional, "m" mandatory and "-" for not applicable. A "*" indicates that the header fields are needed only if message body is not empty. See sections 6.15, 6.16 and 8 for details. The "where" column describes the request and response types with which the header field can be used. "R" refers to header fields that can be used in requests (that is, request and general header fields). "r" designates a response or general-header field as applicable to all responses, while a list of numeric values indicates the status codes with which the header field can be used. "g" and "e" designate general (Section 6.1) and entity header (Section 6.2) fields, respectively. If a header field is marked "c", it is copied from the request to the response. The "enc." column describes whether this message header field MAY be encrypted end-to-end. A "n" designates fields that MUST NOT be encrypted, while "c" designates fields that SHOULD be encrypted if encryption is used. The "e-e" column has a value of "e" for end-to-end and a value of "h" for hop-by-hop header fields. where enc. e-e ACK BYE CAN INV OPT REG __________________________________________________________ Accept R e - - - o o o Accept 415 e - - - o o o Accept-Encoding R e - - - o o o Accept-Encoding 415 e - - - o o o Accept-Language R e - o o o o o Accept-Language 415 e - o o o o o Allow 200 e - - - - m - Allow 405 e o o o o o o Authorization R e o o o o o o Call-ID gc n e m m m m m m Contact R e o - - o o o Contact 1xx e - - - o o - Contact 2xx e - - - o o o Contact 3xx e - o - o o o Contact 485 e - o - o o o Content-Encoding e e o - - o o o Content-Length e e o - - o o o Content-Type e e * - - * * * CSeq gc n e m m m m m m Date g e o o o o o o Encryption g n e o o o o o o Expires g e - - - o - o From gc n e m m m m m m Hide R n h o o o o o o Max-Forwards R n e o o o o o o Organization g c h - - - o o o Other header fields can be added as required; a server MUST ignore header fields not defined in this specification that it does not understand. A proxy MUST NOT remove or modify header fields not defined in this specification that it does not understand. A compact form of these header fields is also defined in Section 9 for use over UDP when the request has to fit into a single packet and size is an issue. A lists those header fields that different client and server types MUST be able to parse. Posted by yogendra Yes SIP header fields are similar to HTTP header fields in both syntax and semantics. SIP Header Field basically Specifies the header information. This header field must be used with any SIP method to limit the number of proxies Posted by sagitraz |
Posted: 19-July-2008 09:22:25 AM By: sagitraz Yes SIP header fields are similar to HTTP header fields in both syntax and semantics. SIP Header Field basically Specifies the header information. This header field must be used with any SIP method to limit the number of proxies | |
Posted: 21-July-2008 12:24:53 PM By: yogendra SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the syntax for message-header as described in [H4.2]. The rules for extending header fields over multiple lines, and use of multiple message-header fields with the same field-name, described in [H4.2] also apply to SIP. The Global-F | "600" ; Busy Everywhere | "603" ; Decline | "604" ; Does not exist anywhere | "606" ; Not Acceptable rules in [H4.2] regarding ordering of header fields apply to SIP, with the exception of Via fields, see below, whose order matters. Additionally, header fields which are hop-by-hop MUST appear before any header fields which are end-to-end. Proxies SHOULD NOT reorder header fields. Proxies add Via header fields and MAY add other hop-by-hop header fields. They can modify certain header fields, such as Max-Forwards (Section 6.23) and "fix up" the Via header fields with "received" parameters as described in Section 6.40.1. Proxies MUST NOT alter any fields that are authenticated. The header fields required, optional and not applicable for each method are listed in Table 4 and Table 5. The table uses "o" to indicate optional, "m" mandatory and "-" for not applicable. A "*" indicates that the header fields are needed only if message body is not empty. See sections 6.15, 6.16 and 8 for details. The "where" column describes the request and response types with which the header field can be used. "R" refers to header fields that can be used in requests (that is, request and general header fields). "r" designates a response or general-header field as applicable to all responses, while a list of numeric values indicates the status codes with which the header field can be used. "g" and "e" designate general (Section 6.1) and entity header (Section 6.2) fields, respectively. If a header field is marked "c", it is copied from the request to the response. The "enc." column describes whether this message header field MAY be encrypted end-to-end. A "n" designates fields that MUST NOT be encrypted, while "c" designates fields that SHOULD be encrypted if encryption is used. The "e-e" column has a value of "e" for end-to-end and a value of "h" for hop-by-hop header fields. where enc. e-e ACK BYE CAN INV OPT REG __________________________________________________________ Accept R e - - - o o o Accept 415 e - - - o o o Accept-Encoding R e - - - o o o Accept-Encoding 415 e - - - o o o Accept-Language R e - o o o o o Accept-Language 415 e - o o o o o Allow 200 e - - - - m - Allow 405 e o o o o o o Authorization R e o o o o o o Call-ID gc n e m m m m m m Contact R e o - - o o o Contact 1xx e - - - o o - Contact 2xx e - - - o o o Contact 3xx e - o - o o o Contact 485 e - o - o o o Content-Encoding e e o - - o o o Content-Length e e o - - o o o Content-Type e e * - - * * * CSeq gc n e m m m m m m Date g e o o o o o o Encryption g n e o o o o o o Expires g e - - - o - o From gc n e m m m m m m Hide R n h o o o o o o Max-Forwards R n e o o o o o o Organization g c h - - - o o o Other header fields can be added as required; a server MUST ignore header fields not defined in this specification that it does not understand. A proxy MUST NOT remove or modify header fields not defined in this specification that it does not understand. A compact form of these header fields is also defined in Section 9 for use over UDP when the request has to fit into a single packet and size is an issue. A lists those header fields that different client and server types MUST be able to parse. | |
Posted: 31-December-2008 10:26:02 AM By: Hash007 yes & for header field explanation see link below http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html | |
Posted: 09-February-2009 10:08:32 AM By: crouse plz visit this site www.w3.org/Protocols/rfc2616/rfc2616-sec14.html | |
Posted: 26-June-2009 01:40:55 PM By: saqlain231 www.faqs.org/rfcs/rfc3864.htm | |
Posted: 27-September-2009 04:54:04 AM By: crouse www.scribd.com/doc/6544836/Sip-Error-Codes | |
Posted: 27-September-2009 05:03:45 AM By: crouse www.scribd.com/doc/6544836/Sip-Error-Codes |