SIP Header - Revision history

Pchero: /* Session-Expires */

2023-04-20T08:25:27Z

Session-Expires

@@ Line 96: / Line 96: @@
 <pre>
 Session-Expires: 1800
 </pre>

Pchero: /* CSeq */

2020-11-26T15:58:58Z

CSeq

← Older revision		Revision as of 15:58, 26 November 2020
Line 19:		Line 19:
	CSeq: 4711 INVITE		CSeq: 4711 INVITE
	</pre>		</pre>

			CSeq 는 메시지의 순서를 파악하는데 사용된다. 각각의 request 메시지마다 1씩 증가하게 되며, 이를 통해서 메시지의 순서를 확인할 수 있다. 만약 이전에 처리한 CSeq 보다 낮은 숫자의 Request 가 오게된다면 500 response 를 보내야 한다. 하지만 CSeq 는 종종 한번에 1 이상씩 증가할 수도 있다. 하지만 이는 에러가 아니며, 메시지는 정상적으로 처리되게 된다.

	=== UAC behavior ====		=== UAC behavior ====

Pchero: /* Max-Forwards */

2020-11-26T15:55:44Z

Max-Forwards

← Older revision		Revision as of 15:55, 26 November 2020
Line 13:		Line 13:

	The user parameter is used by parsers to determine if a telephone number is present in the username portion of the URI. The assumed default is that it is not, indicated by the value ip. If a telephone. number is present, it is indicated by the value phone. This parameter must not used to guess at the characteristics or capabilities of the user agent. For example, the presence of a user=phone parameter must not be interpreted that the user agent is a SIP telephone(which may have limited display and processing capabilties). In a telephone environment, IP telephones and IP/PSTN gateways may in fact use the reverse assumption, interpreting any digits in a username as digits regardless of the presence of user=phone.		The user parameter is used by parsers to determine if a telephone number is present in the username portion of the URI. The assumed default is that it is not, indicated by the value ip. If a telephone. number is present, it is indicated by the value phone. This parameter must not used to guess at the characteristics or capabilities of the user agent. For example, the presence of a user=phone parameter must not be interpreted that the user agent is a SIP telephone(which may have limited display and processing capabilties). In a telephone environment, IP telephones and IP/PSTN gateways may in fact use the reverse assumption, interpreting any digits in a username as digits regardless of the presence of user=phone.

			== CSeq ==
			The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values.
			<pre>
			CSeq: 4711 INVITE
			</pre>

			=== UAC behavior ====
			The Call-ID of the request MUST be set to the Call-ID of the dialog. Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or canceled). Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. If the local sequence number is empty, an initial value MUST be chosen using the guidelines.

			=== UAS behavior ===
			If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than remote sequence number, the request is out of order and MUST be rejected with a 500 (Server internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence umber by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request.

			: If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice a gap in the CSeq number space. Such a gap does not represent any error condition.

			When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in the request, if present.

	== Max-Forwards ==		== Max-Forwards ==

Pchero: /* Request line URI */

2020-09-11T23:35:48Z

Request line URI

@@ Line 54: / Line 54: @@
 == Request line URI ==
 The Request line URI includes the destination of the call. It contains the same information as the To field, omitting the display name.
 == Session-Expires ==

Pchero: /* Request line URI */

2020-09-11T23:28:04Z

Request line URI

@@ Line 36: / Line 36: @@
 </pre>
 * https://i3forum.org/wp-content/uploads/2019/06/i3f_CLI_management_guidelines_rev-1.pdf
 == Request line URI ==

Pchero: /* P-Asserted-Identity */

2020-04-21T14:20:35Z

P-Asserted-Identity

← Older revision		Revision as of 14:20, 21 April 2020
Line 35:		Line 35:
	P-Asserted-Identity: "sungtae kim" <sip:pchero@pchero21.com>		P-Asserted-Identity: "sungtae kim" <sip:pchero@pchero21.com>
	</pre>		</pre>
			* https://i3forum.org/wp-content/uploads/2019/06/i3f_CLI_management_guidelines_rev-1.pdf

	== Request line URI ==		== Request line URI ==

Pchero at 07:29, 11 March 2020

2020-03-11T07:29:26Z

← Older revision		Revision as of 07:29, 11 March 2020
Line 35:		Line 35:
	P-Asserted-Identity: "sungtae kim" <sip:pchero@pchero21.com>		P-Asserted-Identity: "sungtae kim" <sip:pchero@pchero21.com>
	</pre>		</pre>

			== Request line URI ==
			The Request line URI includes the destination of the call. It contains the same information as the To field, omitting the display name.

	== Session-Expires ==		== Session-Expires ==
Line 46:		Line 49:
	</pre>		</pre>

	== ~~Request line URI~~ ==		== To ==
	The ~~Request line URI includes~~ the ~~destination~~ of the call. ~~It contains~~ the ~~same information as~~ the To field, ~~omitting~~ the display name.		The To header field is required header field in every SIP message used to indicate the recipient of the request. Any responses generated by a UA will contain this header field with the addition of a tag. (Note tha t an RFC 2543 client will typically only generate a tag if more than one Via header field is present in the request.) Any response generated by a proxy must have a tag added to the To header field. A tag added to the header field in a 200 OK response is used throughout the call and incorporated into the dialog. The To header field URI is never used for routing - the request-URI is used for this purpose. An optional display name can be present in the header field, in which case the SIP URI is enclosed in < >. If the URI contains any parameters or username parameters, the URI must be enclosed in < > even if no display name is present. The compact form of the header fields is t.

	== Via ==		== Via ==

Pchero: /* SIP and SIPS URIs */

2020-03-09T08:22:02Z

SIP and SIPS URIs

← Older revision		Revision as of 08:22, 9 March 2020
Line 10:		Line 10:
	sip:pchero.sungtae@pchero21.com:5060;transport=udp;user=ip;method=INVITE;ttl=1;maddr=240.101.102.103?Subject=FFT		sip:pchero.sungtae@pchero21.com:5060;transport=udp;user=ip;method=INVITE;ttl=1;maddr=240.101.102.103?Subject=FFT
	</pre>		</pre>
			Note that URIs may not contain spaces or line breaks, so this example would be on a single line. Some SIP URIs, such as REGISTER Request-URI do not have a username, but begin with the host or IP address. In this example, the port number is shown as 5060, the well-known port number for SIP. For a SIP number 5061 is assumed. The transport parameter indicates UDP is to be used, which is the default. TCP, TLS, and SCTP are alternative transport parameters.

			The user parameter is used by parsers to determine if a telephone number is present in the username portion of the URI. The assumed default is that it is not, indicated by the value ip. If a telephone. number is present, it is indicated by the value phone. This parameter must not used to guess at the characteristics or capabilities of the user agent. For example, the presence of a user=phone parameter must not be interpreted that the user agent is a SIP telephone(which may have limited display and processing capabilties). In a telephone environment, IP telephones and IP/PSTN gateways may in fact use the reverse assumption, interpreting any digits in a username as digits regardless of the presence of user=phone.

	== Max-Forwards ==		== Max-Forwards ==

Pchero at 08:15, 9 March 2020

2020-03-09T08:15:33Z

← Older revision		Revision as of 08:15, 9 March 2020
Line 1:		Line 1:
	== Overview ==		== Overview ==
	SIP headers 내용 정리		SIP headers 내용 정리

			== Basic ==
			=== SIP and SIPS URIs ===
			SIP URIs are used in a number of places including the To, From, and Contact headers, as well as in the Request-URI, which indicates the destination. SIP URIs are similar to the mailto URL and can be used in hyperlinks on Web page, for example. They can also include telephone numbers. The information in a SIP URL incidates the way in which the resource (user) should be contacted using SIP.

			An example SIP URI contains the scheme '''sip''' a ''':''', then a '''username@host''' or IPv4 or IPv6 address followed by an optional ''':''', then port number, or a list of ''';''' separated URI parameters.
			<pre>
			sip:pchero.sungtae@pchero21.com:5060;transport=udp;user=ip;method=INVITE;ttl=1;maddr=240.101.102.103?Subject=FFT
			</pre>

	== Max-Forwards ==		== Max-Forwards ==
Line 13:		Line 22:
	P-Asserted-Identity is a special type of UA identity implying "This is the proven ID for me within this trusted network".		P-Asserted-Identity is a special type of UA identity implying "This is the proven ID for me within this trusted network".

	Usually UA ID is set in 'From' header, but the From header does not necessarily contain the actual identity. Actually, you can put any kind of string for 'From' header. Therefore, once the authentication is complete for a UA, a proxy can add P-Asserted-Identity to inform other proxies saying 'Hey, this is a proven ID. So you can trust'.		Usually, UA ID is set in 'From' header, but the From header does not necessarily contain the actual identity. Actually, you can put any kind of string for 'From' header. Therefore, once the authentication is complete for a UA, a proxy can add P-Asserted-Identity to inform other proxies saying 'Hey, this is a proven ID. So you can trust'.

	From the RFC 3325, 9.1 The P-Asserted-Identity header:		From the RFC 3325, 9.1 The P-Asserted-Identity header:

Pchero: /* See also */

2020-03-09T08:08:01Z

← Older revision		Revision as of 08:08, 9 March 2020
Line 41:		Line 41:

	== See also ==		== See also ==
	* https://www.3cx.com/blog/voip-howto/sip-invite-header-fields/		* https://www.3cx.com/blog/voip-howto/sip-invite-header-fields - The main SIP INVITE Header Fields explained

	[[category:SIP protocol]]		[[category:SIP protocol]]