[Sip] 180 for PRACK
"suryakanta mandal" <suryakanta.mandal@gmail.com> Mon, 28 January 2008 21:12 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJbHA-00064Y-NZ; Mon, 28 Jan 2008 16:12:20 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JIMt7-0008M9-NK for sip-confirm+ok@megatron.ietf.org; Fri, 25 Jan 2008 06:38:25 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JIMt7-0008Jo-AD for sip@ietf.org; Fri, 25 Jan 2008 06:38:25 -0500
Received: from an-out-0708.google.com ([209.85.132.246]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JIMt6-0002gG-Ua for sip@ietf.org; Fri, 25 Jan 2008 06:38:25 -0500
Received: by an-out-0708.google.com with SMTP id d11so263660and.122 for <sip@ietf.org>; Fri, 25 Jan 2008 03:38:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=cJdL7PdW9lA5W+6HkYIqEy+0Rw3QehlK7dW8FqFD6xA=; b=IzAJZcb+TFAbRG5MmjWJEwAggZKBW4K32fzMFYQ/Iwcqx0Z7oZFS4L728yTkP6f/QT3s9DkHn/jax0xwPZuaD51fU+t9dN0bh3SQKpjtoQcWi/DHaHdHj9uAP7ZkgUSaejeKtOU8wOeyuWSPrDWvsrD+l/nZvVwdkeNVnXgEEH8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=RZinQ/toYA95BjUoagG0jT9AuEC9g0mERcgArkBCUF6UR7PGCcQR673Xak54ilcAH32PoEysdDXlaQ5bQ+Gk8auHC1DxU4rXd1MxZ+ICGMzN56oY+utjVcfXKu7EzjYC1/XuQ+xbJ/Wd2C4vR+L6XjhGqnD7ZRp87i7rHJorLHQ=
Received: by 10.100.112.6 with SMTP id k6mr3918462anc.110.1201261104591; Fri, 25 Jan 2008 03:38:24 -0800 (PST)
Received: by 10.100.9.5 with HTTP; Fri, 25 Jan 2008 03:38:24 -0800 (PST)
Message-ID: <24e80f870801250338w7df91a20s26d78a61cfd619aa@mail.gmail.com>
Date: Fri, 25 Jan 2008 17:08:24 +0530
From: suryakanta mandal <suryakanta.mandal@gmail.com>
To: sip-implementors-request@lists.cs.columbia.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
X-Mailman-Approved-At: Mon, 28 Jan 2008 16:12:19 -0500
Cc: sip@ietf.org
Subject: [Sip] 180 for PRACK
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
Hi , If you look at the RFC 3262, it says in Section 4: UAC behaviour Header field where PRACK ___________________________________ Alert-Info 180 - Contact 1xx - Contact 3xx o Error-Info 300-699 o Record-Route 2xx,18x o and If you look at the functionality of these column from RFC 3261 "The "where" column describes the request and response types in which the header field can be used. Values in this column are: R: header field may only appear in requests; r: header field may only appear in responses; 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used; c: header field is copied from the request to the response. An empty entry in the "where" column indicates that the header field may be present in all requests and responses. The "proxy" column describes the operations a proxy may perform on a header field: a: A proxy can add or concatenate the header field if not present. m: A proxy can modify an existing header field value. d: A proxy can delete a header field value. r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. The next six columns relate to the presence of a header field in a method: c: Conditional; requirements on the header field depend on the context of the message. m: The header field is mandatory. m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. o: The header field is optional. t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. If a stream-based protocol (such as TCP) is used as a transport, then the header field MUST be sent. *: The header field is required if the message body is not empty. See Sections 20.14, 20.15 and 7.4 for details. -: The header field is not applicable. " I got struck on these above points. Can you let me know the scenario when the UAS will generate 180 for PRACK ? and when UAS will generate 3xx response for PRACK because their it mentioned optional means UAS may or may not generate 3xx response. Surya Aricent _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] 180 for PRACK suryakanta mandal