Subject: [sip-overload] draft-ietf-soc-overload-control-02

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 29 Mar 2011 15:58:06 +0200

OK so you asked me to look at section 12 in the soc meeting and I have done so.

12.  100-Trying provisional response and overload control  parameters

   The overload control information sent from a SIP server to a client
   is transported in the responses.  While implementations can insert
   overload control information in any response, special attention
   should be accorded to overload control information transported in a
   100-Trying response.

   Traditionally, the 100-Trying response has been used in SIP to quench
   retransmissions.  In some implementations, the 100-Trying message may
   not be generated by the transaction user (TU) nor consumed by the TU.
   In these implementations, the 100-Trying response is generated at the
   transaction layer and sent to the upstream SIP client.  At the
   receiving SIP client, the 100-Trying is consumed at the transaction
   layer by inhibiting the retransmission of the corresponding request.
   Consequently, implementations that insert overload control
   information in the 100-Trying cannot assume that the upstream SIP
   client passed the overload control information in the 100-Trying to
   their corresponding TU.  For this reason, implementations that insert
   overload control information in the 100-Trying MUST re-insert the
   same (or updated) overload control information in the first non-100
   response being sent to the upstream SIP client.

My understanding for allowing this is simplicity in the sender (to treat all 100 and 1xx in a similar manner at the sender), rather than expectation that the receiver will receive it. I think this point needs to be made clearer.

Regards

Keith

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 30 Mar 2011 08:48:13 -0500

> OK so you asked me to look at section 12 in the soc meeting and I
[...]
> My understanding for allowing this is simplicity in the sender (to
> treat all 100 and 1xx in a similar manner at the sender), rather than
> expectation that the receiver will receive it. I think this point
> needs to be made clearer.

Keith: Well ... Section 12 considers simplicity in the receiver
as well as the sender.  The sender of the response does not need to
couple TU-provided information (oc) with the response being
generated at the transaction layer (100), and on the
receiving side, the receiver does not have to provide the
oc information from the 100 to the TU.

If this is not clear, I will make another stab at this.
I have to update Section 12 to incorporate Victor's comment
regarding 100rel anyway.  So, stay tuned for the next revision.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/