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 PM

Comments


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