Udit,
      Use of the warning codes seems the best way then, section 27.2 in
3261is pretty specific about blocks within this range being reserved for
certain responses. The two options therefore seem to be use the 390 - 399
miscellaneous range, although I am not clear if you can define their use in
a draft or it literally means they are 'reserved' for ad-hoc /
miscellaneous warning codes (?) OR create a new draft for review containing
definitions for the warning codes you desire in hogher number range.

- Wayne.

Udit said:
************************************************
Hi Wayne,

I agree that for Warning header field, the scope is limited because of the
codes already defined in 3261
Moreover, they mainy defines the failures induced by the SDP

Giving more error status information in the reason phrase is also ok but it
is more like implementation dependent as per RFC 3261.
It does not define any standard error phrases for this purpose.

Even we cant use "Reason" header (RFC 3326) for this purpose because it
defines cause to be the SIP status code so it will also not serve any
purpose.

What I think is providing more error warning codes for failure cases will
be better as error codes are always better than reason phrases because of
ease of automatic action.
Cant we have something like 4xx warning codes too.. or is it like 3xx is
only available for SIP.

-Udit


                                                                           
 [EMAIL PROTECTED]                                               
                                                                           
 Sent by:                                                                  
 [EMAIL PROTECTED]                                            To 
 .columbia.edu                      Udit Goyal/C/US/[EMAIL PROTECTED]           
   
                                                                        cc 
                                    [EMAIL PROTECTED] 
 04/19/2005 01:43 AM                du, [email protected]   
                                                                   Subject 
                                    Re: [Sip-implementors] Busy condition  
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           









Udit,
Both methods of communicating more detail for the error condition
seem valid / ok to me.

It appears the main difference in their use is that the Warning
header entries are mandated in 3261 and furthered by IANA registered ones.
The warning codes range for SIP is stated as being the 3xx block which are
already divided up into categories, currently there seems limited scope in
using this range (390 - 399 for miscellaneous).

3261 supports extending the default reason phrase for responses and
gives some specific examples of this is advocated 261 gives examples of
doing this for specific responses (182, 400, 480). Advocating a standard
for the wording for common conditions like your examples below might be a
good idea.

Regards - Wayne.


Udit asked:
*************************************************************
Hi,

I was just wondering that are there any ways to give different indications
when user is not able to take the call.
There are error responses like 480, 486 used to indicate the busy
condition but still they are not able to indicate the exact failure
status.
However, there can be scenarios like:
i)   User rejects the call.
ii)  All lines are busy and user cant take the call.
iii) Ringing timeout occur: No Answer and more....

I feel there are possibilities of indicating to the end user by using
error response status text, "Warning" header, or "Reason" header.
Please let me know which is more standard approach followed.

Thanks,
Udit
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors


**********************************************************************
Any personal or sensitive information contained in this email and
attachments must be handled in accordance with the Victorian Information
Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
(Commonwealth), as applicable.

This email, including all attachments, is confidential.  If you are not the
intended recipient, you must not disclose, distribute, copy or use the
information contained in this email or attachments.  Any confidentiality or
privilege is not waived or lost because this email has been sent to you in
error.  If you have received it in error, please let us know by reply
email, delete it from your system and destroy any copies.
**********************************************************************


_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

**********************************************************************
Any personal or sensitive information contained in this email and
attachments must be handled in accordance with the Victorian Information
Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
(Commonwealth), as applicable.

This email, including all attachments, is confidential.  If you are not the
intended recipient, you must not disclose, distribute, copy or use the
information contained in this email or attachments.  Any confidentiality or
privilege is not waived or lost because this email has been sent to you in
error.  If you have received it in error, please let us know by reply
email, delete it from your system and destroy any copies.
**********************************************************************


_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to