Hi,

To elaborate further, 415 is not related to just the Content-Type

header, RFC 3261 clearly mentions that:
"If there are any bodies whose type (indicated by the Content-Type),
language (indicated by the Content-Language) or encoding (indicated by
the Content-Encoding) are not understood, and that body part is not
optional (as indicated by the Content-Disposition header field), the UAS
MUST reject the request with a 415(Unsupported Media Type) response."
Similarly, for the 488 response
"means that the user wishes to communicate, but cannot adequately
support the session described."
It may not necessarily because the user *does not understand/ support*
but also due to the fact that the user is currently unable to proceed
with this call based on the offered parameters. A typical example is
that many fax machines do not allow simultaneous SIP-T.38 fax calls so
the 2nd INVITE is typically rejected with a 488.
Regards,
Gaurav
-----Original Message----From: SIP-IMPLEMENTORS-BOUNCES AT CS.COLUMBIA.EDU
[mailto:SIP-IMPLEMENTORS-BOUNCES AT CS.COLUMBIA.EDU ] On Behalf Of Attila
Sipos
Sent: Friday, February 10, 2006 3:51 PM
To: Neeraj Chowdhury; SIP-IMPLEMENTORS AT CS.COLUMBIA.EDU
Subject: Re: [Sip-implementors] Query about 415 and 488 responses //

>> 1) 415 Unsupported Media Type

This means that it does not know about the Content-Type
in the incoming request.
>> 2) 488 Not Acceptable Here
Used when there is nothing in the session description
which this UA can understand or support.
e.g. they offer you the g723 codec only but your UA
can't support g723 then you use 488 as the response.
Regards,
Attila
Attila Sipos
HTTP://WWW.VEGASTREAM.COM

>> -----Original Message---->> From: SIP-IMPLEMENTORS-BOUNCES AT CS.COLUMBIA.EDU

>> [mailto:SIP-IMPLEMENTORS-BOUNCES AT CS.COLUMBIA.EDU]On Behalf Of Neeraj
>> Chowdhury
>> Sent: 10 February 2006 09:51
>> To: SIP-IMPLEMENTORS AT CS.COLUMBIA.EDU
>> Subject: [Sip-implementors] Query about 415 and 488 responses //
>>
>>
>> Please give me the details about when the UAS generates the following
>> responses and what is the difference between both of them :

>>
>> 1) 415 Unsupported Media Type
>> 2) 488 Not Acceptable Here

RFC 3261 Says that 400 Bad Request should be formed if there is an
error in Mandatory headers like To,From,Via and Callid etc or if the
Mandatory headers are missing.
>
When is it appropriate to use 501 Not Implemented response
> instead of 405
> Method Not Allowed for a Method which is not supported in an
endpoint?
>
> The RFC (3261) seems ambiguous in this regard.
>
> <<21.5.2 501 Not Implemented
>
>
The server does not support the functionality required to
> fulfill the
>
request. This is the appropriate response when a UAS does not
>
recognize the request method and is not capable of
> supporting it for
>
any user. (Proxies forward all requests regardless of method.)
>
>
Note that a 405 (Method Not Allowed) is sent when the server
>
recognizes the request method, but that method is not allowed or
>
supported.>>
>
>
> Since both 501 and 405 can be used for functionality that is
> not supported,
> is it appropriate to always use 405 for unsupported Methods?
Well, if your stack understands method Foo, but doesn't want to allow
the request, send a 405 Method Not Allowed. (Say, your stack knows what
to do with REFERs but doesn't allow REFERs from certain domains, or
something.) If your stack has no idea what a Foo method is, or what to
do with it, return a 501 Not Implemented.
In other words, 405 means "I know what you want but I don't allow that"
while 501 means "I don't understand what you want".
frank
406
As far as I can tell, a 406 is returned when the UAS on the other side
cannot formulate a response with content-type acceptable to the sender (as
indicated in the Accept-header it sent). A 488 is returned when the UAS
can satisfy the Accept-header but the session description in the request
is not acceptable. There is also a 606 which tells that ALL UASs for that
user don't accept the session description (a 488 only rejects the request
to that particular R-URI).

408
Hi,
I am slightly confused about 408 request timeout
response.
When a UAC send an Invite and it doesn't get back any
response, the UAC transaction generates a 408
response.

>>Correct. Internally it treats/processes the call as though a 408

response has been received.
The 408 response never comes from the UAS.
Hope this helps...

8.2.2.1 To and Request-URI ( from RFC 3261 )

A UAS MAY apply any
policy it wishes to determine whether to accept requests when the To
header field is not the identity of the UAS. However, it is
RECOMMENDED that a UAS accept requests even if they do not recognize
the URI scheme (for example, a tel: URI) in the To header field, or
if the To header field does not address a known or current user of
this UAS. If, on the other hand, the UAS decides to reject the
request, it SHOULD generate a response with a 403 (Forbidden) status
code and pass it to the server transaction for transmission.
However, the Request-URI identifies the UAS that is to process the
request. If the Request-URI uses a scheme not supported by the UAS,
it SHOULD reject the request with a 416 (Unsupported URI Scheme)
response. If the Request-URI does not identify an address that the
UAS is willing to accept requests for, it SHOULD reject the request
with a 404 (Not Found) response. Typically, a UA that uses the
REGISTER method to bind its address-of-record to a specific contact
address will see requests whose Request-URI equals that contact
address. Other potential sources of received Request-URIs include
the Contact header fields of requests and responses sent by the UA
that establish or refresh dialogs.
-----Original Message----From: Ramya Jothi [mailto:rjyoti at kodiaknetworks.com]
Sent: Tuesday, January 03, 2006 11:28 AM
To: 'Asheesh Joshi'
Cc: sip-implementors at cs.columbia.edu
Subject: RE: [Sip-implementors] Request Uri and Uri in To header
Hi Asheesh
The earlier query was a syntax error in to header.
400 would bad request would be sent in case of syntax error in the
received message where as here it's the request uri and to uri are
syntactically correct but semantically incorrect
I want to know , when a request is received at UAS what would be checked
is it the user part of request uri or the to - uri

-Regards
Ramya
" Failure is not when you fall down

Its only when you don't get up again "

-----Original Message----From: Asheesh Joshi [mailto:asjoshi at varaha.com]
Sent: Tuesday, January 03, 2006 10:53 AM
To: Ramya Jothi
Cc: sip-implementors at cs.columbia.edu
Subject: RE: [Sip-implementors] Request Uri and Uri in To header
You are posting the same query again which you posted couple of days
back.
400 Bad request should be returned in all the 3 cases you have
mentioned.
-Asheesh.
-----Original Message----From: sip-implementors-bounces at cs.columbia.edu
[mailto:sip-implementors-bounces at cs.columbia.edu]On Behalf Of Ramya
Jothi
Sent: Tuesday, January 03, 2006 9:28 AM
To: sip-implementors at cs.columbia.edu
Subject: [Sip-implementors] Request Uri and Uri in To header
Hi
What should be the behavior of a UA for the below 3 combinations of
request uri and uri in to header
1. A valid Request uri and an invalid uri in to header
2. A invalid Request uri and a valid uri in to header
3. Both are having invalid uri
Example:
Below Message contains a invalid uri in Request uri and a valid uri in
to header
INVITE sip:Bob at 192.168.2.237:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.36:5080; branch=z9hG4bK2281757680-35326200
Max-Forwards: 70
Allow:
INVITE,BYE,CANCEL,ACK,INFO,PRACK,COMET,OPTIONS,SUBSCRIBE,NOTIFY,MESSAGE,
REFER,REGISTER,UPDATE
From: Alice <sip:Alice at 192.168.2.36:5080>;tag=hssUA_1793538136-2085
To: John <sip:John at 192.168.2.237:5060>
Call-ID: 2281757680-0
CSeq: 1 INVITE
Contact: Alice <sip: Alice @192.168.2.36:5080>
Content-Type: application/sdp
Content-Length: 276
-Regards
Ramya
" Failure is not when you fall down
Its only when you don't get up again "

_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
ACCORDING TO RFC3261 , 401 IS ISSUED BY UAS AND REGISTRAR AND 407 BY
SERVER IS IN PROXY MODE , IN ORDER TO AUTHENTICATE UA.

I suppose 415 indicates

contained media types of SIP message "body" is not supported.
If request SIP message contain "application/sdp" ,
415 response indicates UA2 dose not support "application/sdp".
In this case, I think that 488 response is good,
because UA2 probably understand SDP,
simply UA2 dose not support "m=audio" media type.
It's better that UA2 responses 488 error response with
304 warn-code in Warning header.
488 response indicates
"Not Acceptable Here"
and 304 warn-code in Warning header indicates
"Media type not available: One or more media types contained in
the session description are not available."
reference from RFC3261, 20.43 Warning
THE CALLER'S UA MAY SEND A BYE FOR EITHER CONFIRMED OR
EARLY DIALOGS, AND THE CALLEE'S UA MAY SEND A BYE ON
CONFIRMED DIALOGS, BUT MUST NOT SEND A BYE ON EARLY DIALOGS