Subject: [Sip] Constraints on MESSAGE responses

From: Cuda Alberto <[email-masked]>
Date: Wed, 07 Sep 2005 12:36:52 +0200

Hi everybody,
I need some clarification about semantic in MESSAGE response.
I've tried to find some discussion in the archives, but I did not
succeed.

According to RFC 3428, paragraph 7, an UAS must send a final response
immediately after receiving a MESSAGE request. What does "immediately"
actually mean? 

I am thinking of a SIP <-> non-SIP gateway: when processing a MESSAGE
coming from a SIP interface, the rough list of operations it must
perform is:

1. Parse SIP headers;
2. Parse SIP body (in case it is not text/plain);
3. Build non-SIP translation of the message
4. Send non-SIP message
5. Wait for an acknowledgment from the non-SIP side (assuming the other
  protocol guarantees that ackowledge to be received in less that 200ms)
  
All these steps may encounter some error, for instance in the format
of the message, or due to lack of resources (e.g. memory). It may
also fail because a negative acknowledgment is received from the
non-SIP network. However, none of these steps introduces a significative
latency which may cause retransmissions: which is the last step
that can be performed before the response must be sent?

Another question is: in case of a 4xx or 5xx response code is generated,
are there any restrictions on their content type?

     Thanks, cheers.
	   Alberto.

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

_______________________________________________
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: Hisham Khartabil <[email-masked]>
Date: Wed, 7 Sep 2005 16:01:59 +0200

I would say after step 2.x: when the UAC Core has received the MESSAGE 
request. It sends a 2xx response before the gatewaying process takes 
place (step 3).

Regards,
Hisham

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 07 Sep 2005 11:04:56 -0500

> request. It sends a 2xx response before the gatewaying process takes 

I am curious: is there any harm in waiting 200ms before sending
the 2xx response.  In certain cases, 200ms may be enough for the
gateway to get some indication -- positive or negative -- from
its processing.  I agree that the response should not pend beyond
200ms, though.  If the gateway takes longer, a 202 seems
appropriate.

- vijay

---

From: Dean Willis <[email-masked]>
Date: Wed, 7 Sep 2005 16:30:28 -0500

> immediately after receiving a MESSAGE request. What does "immediately"

MESSAGE is a non-invite transaction, so the constraints from:
	draft-sparks-sip-nit-problems-02.txt
and
	draft-sparks-sip-nit-actions-03.txt
apply. Note that both of these documents are approved and in the RFC 
editor queue.

Clearly you need to respond before the retransmit timer occurs. That 
retransmit timer can be delayed by a 100-class provisional response, so 
if the final response requires some "pending" time, then one should 
send a 100 within the first retransmit window (but not before timer E 
lapses if a non-reliable transport is used).

This is more completely spelled out in action 1 of the nit-actions 
draft:

    A SIP element MUST NOT send any provisional response with a
    Status-Code other than 100 to a non-INVITE request.

    A SIP element MUST NOT respond to a non-INVITE request with a
    Status-Code of 100 over any unreliable transport, such as UDP, before
    the amount of time it takes a client transaction's Timer E to be
    reset to T2.

    A SIP element MAY respond to a non-INVITE request with a Status-Code
    of 100 over a reliable transport at any time.

    Without regard to transport, a SIP element MUST respond to a
    non-INVITE request with a Status-Code of 100 if it has not otherwise
    responded after the amount of time it takes a client transaction's
    Timer E to be reset to T2.

--
Dean