[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