Subject: [Sip] What error response to Naked Invite?

From: [email-masked]
Date: Mon, 5 Jun 2006 16:24:38 -0400

If a UAS doesn't support naked INVITEs, what error response should it
generate? Is there a preferred response? Is it 415 unsupported media type?

Thanks in advance for your help.

-Steve

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 05 Jun 2006 17:02:13 -0400

> generate? Is there a preferred response? Is it 415 unsupported media type?

488 Not Acceptable Here, unless it is a clothing-optional location ;-)

Seriously -- what do you mean by "naked INVITE"?

If you mean INVITE without SDP, a UAS is required to support that.  See
RFC 3261, section 13.2.1, page 80, 5th paragraph: "Concretely, the above
rules specify two exchanges for UAs compliant to this specification
alone - [...], or the offer is in the 2xx, and the answer is in the ACK.
All user agents that support INVITE MUST support these two exchanges"

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Jun 2006 17:31:05 -0400

> All user agents that support INVITE MUST support these two exchanges"

If your assumption about the meaning of "naked INVITE" is correct, then 
I guess it would be appropriate for this server to respond with a 500, 
because the server clearly has experienced an internal error by not 
being able to process this.

Just include a Retry-After that is large enough to give time for the 
implementation to be corrected. :-)

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 5 Jun 2006 23:49:39 -0500

> generate? Is there a preferred response? Is it 415 unsupported  

The "Naked INVITE" is a phenomenon wlosely related to the East  
African "Naked Mole Rat", Heterocephalus Glaber, and if you can't  
figure out the relationship, I suggest using Google. Oh, heck, I'll  
spell it out -- they're both nominally ugly, occur primarily in  
eusocial structures, and are believed to be coprophagic, but only one  
is a rodent.

See: http://www.bbc.co.uk/nature/wildfacts/factfiles/614.shtml

But let's assume we're talking about an INVITE request without an SDP  
body carrying the "offer" of the offer/answer model documented in RFC  
3264.

One might argue that an improperly socialized UAS that rejected an  
INVITE request on the basis of the media (or lack thereof) specified  
therein might do so with a 415, which RFC 3261 describes as:

    If a 415 (Unsupported Media Type) response is received (Section
    21.4.13), the request contained media types not supported by the  
UAS.
    The UAC SHOULD retry sending the request, this time only using
    content with types listed in the Accept header field in the  
response,
    with encodings listed in the Accept-Encoding header field in the
    response, and with languages listed in the Accept-Language in the
    response.

  and 8.2.3 Content Processing goes on to say:

    Assuming the UAS understands any extensions required by the client,
    the UAS examines the body of the message, and the header fields that
    describe it.  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.  The response MUST contain an
    Accept header field listing the types of all bodies it understands,
    in the event the request contained bodies of types not supported by
    the UAS.  If the request contained content encodings not understood
    by the UAS, the response MUST contain an Accept-Encoding header  
field
    listing the encodings understood by the UAS.  If the request
    contained content with languages not understood by the UAS, the
    response MUST contain an Accept-Language header field indicating the
    languages understood by the UAS.  Beyond these checks, body handling
    depends on the method and type.  For further information on the
    processing of content-specific header fields, see Section 7.4 as  
well
    as Section 20.11 through 20.15.

However, we have, in RFC 3261 13.2.1

       o  The initial offer MUST be in either an INVITE or, if not  
there,
          in the first reliable non-failure message from the UAS back to
          the UAC.  In this specification, that is the final 2xx
          response.

and, a few paragraphs later:

    Concretely, the above rules specify two exchanges for UAs compliant
    to this specification alone - the offer is in the INVITE, and the
    answer in the 2xx (and possibly in a 1xx as well, with the same
    value), or the offer is in the 2xx, and the answer is in the ACK.
    All user agents that support INVITE MUST support these two  
exchanges.

So it would seem that our UAS here is behaving in a fashion somewhat  
inconsistent with RFC 3261 by rejecting the INVITE-without-SDP. The  
correct response to such a request is to respond with an offer in the  
200 OK.

Now, let's say this just doesn't work, because we're using  
preconditions as per RFC 3312, which would be indicated by a  
"Require: precondition" in the request, probably along with a  
"Supported: 100-rel". This lets us extend the offer/answer model of  
RGC 3261 by placing the offer into a PRACK, which is now a reliable  
message and therefore capable of meeting the requirements of RFC 3261  
13.2.1.

So, since we've already established it's non-compliant with RFC 3261,  
the UAS might as well come back with a 418 "I'm a teapot" message,  
because it's broken.

--
Dean