Common use of SIP Response Headers Clause in Contracts

SIP Response Headers. All SIP 1XX responses support the following headers :- TO, FROM, VIA, CALL-ID, CSEQ & CONTENT-LENGTH. The following table details which additional headers are carried in specific 1XX responses :- Content Type N/A O Contact O M Supported O O RSeq N/A C Require O O Content Disposition N/A C Session Expires O O Record- Route N/A O Allow O O Note :- M – Mandatory, O – Optional, C – Conditional (i.e. if SDP present, then M), N/A – Not applicable. All 2XX responses other than 200 response are treated as for a 200 response for the corresponding transaction. A 200 OK response will be sent to INVITE,PRACK,INFO,BYE, CANCEL& UPDATE if the request is properly processed. It may contain a body to exchange the callee’s capabilities. The 200 OK response to a BYE or CANCEL may carry an embedded ISUP RLC message. Note that since CANCEL is hop-by-hop, there is no guarantee that the contents of a 200 OK CANCEL will reach a remote CA. The 200 OK response always contains the following :- TO, FROM, VIA, CALL-ID, CSEQ, CONTACT & CONTENT-LENGTH. In addition, the following headers may be present :- CONTENT-TYPE (if SDP / encapsulated ISUP present), REQUIRE, SUPPORTED, SESSION-EXPIRES, RECORD-ROUTE, CONTENT-DISPOSITION (if encapsulated ISUP present) & ALLOW (to enable advertising of UPDATE support). Any SIP failure reason (3XX, 4XX, 5XX, 6XX) should be allowed in the profile. 3XX responses will contain the following headers :- TO, FROM, VIA, CALL_ID, CSEQ, CONTENT- LENGTH & CONTACT. It is assumed that a 3XX response will cause the call to be released (i.e. redirection shall be done via ISUP call forwarding). 4XX/5XX/6XX responses will contain the following headers :- TO, FROM, VIA, CALL_ID, CSEQ, & CONTENT-LENGTH. In general, the headers identified in this section are intended to be a minimum set to support the encapsulation of ISUP signalling with appropriate session control. Embedded ISUP messages may be present in the following responses :- 100 Trying None Never present 180 Ringing ACM, CPG Always present 18X (i.e. other than 180) ACM, CPG Always present 200 ANM, CON Always present for 200 response to INVITE

SIP Response Headers. All SIP 1XX responses support the following headers :- TO, FROM, VIA, CALL-ID, CSEQ & CONTENT-LENGTH. The following table details which additional headers are carried in specific 1XX responses :- Content Type N/A O Contact O M Supported O O RSeq N/A C Require O O Content Disposition N/A C Session Expires O O Record- Route N/A O Allow O O Note :- M – Mandatory, O – Optional, C – Conditional (i.e. if SDP present, then M), N/A – Not applicable. All 2XX responses other than 200 response are treated as for a 200 response for the corresponding transaction. A 200 OK response will be sent to INVITE,PRACK,INFO,BYE, CANCEL& UPDATE if the request is properly processed. It may contain a body to exchange the callee’s capabilities. The 200 OK response to a BYE or CANCEL may carry an embedded ISUP RLC message. Note that since CANCEL is hop-by-hop, there is no guarantee that the contents of a 200 OK CANCEL will reach a remote CA. The 200 OK response always contains the following :- TO, FROM, VIA, CALL-ID, CSEQ, CONTACT & CONTENT-LENGTH. In addition, the following headers may be present :- CONTENT-TYPE (if SDP / encapsulated ISUP present), REQUIRE, SUPPORTED, RECORD-ROUTE, SESSION-EXPIRES, RECORD-ROUTE, CONTENT-DISPOSITION (if encapsulated ISUP present) & ALLOW (to enable advertising of UPDATE supportsupported Methods). Any SIP failure reason (3XX, 4XX, 5XX, 6XX) should be are allowed in the profile. 3XX responses will contain the following headers :- TO, FROM, VIA, CALL_ID, CSEQ, CONTENT- LENGTH & CONTACT. It is assumed that An entity MAY redirect the call on receipt of a 3XX response will cause – else it is treated as a 4XX response and the call to be released (i.e. redirection shall be done via ISUP call forwarding)call/session is released. 4XX/5XX/6XX responses will contain the following headers :- TO, FROM, VIA, CALL_ID, CSEQ, & CONTENT-LENGTH. In general, the headers identified in this section are intended to be a minimum set to support the encapsulation of ISUP signalling with appropriate session control. Embedded ISUP messages and other headers may be present in the following responses :- 100 Trying None Never present 180 Ringing ACM, CPG Always present 18X (i.e. other than 180) ACM, CPG Always present 200 ANM, CON Always present for 200 response to INVITEpresent.