[Home]

Summary:ASTERISK-03710: Don't send 100 Trying during registration transaction
Reporter:khb (khb)Labels:
Date Opened:2005-03-19 13:00:16.000-0600Date Closed:2011-06-07 14:11:58
Priority:TrivialRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch_100_trying.txt
Description:Don't send 100 Trying during registration transaction

****** ADDITIONAL INFORMATION ******

Existing behavior violates standard.

disclaimed despite trivial nature, not adding any code.
Comments:By: Olle Johansson (oej) 2005-03-19 15:43:25.000-0600

Where can you find this in the RFC?

"This response indicates that the request has been received by the next-hop server and that some unspecified
action is being taken on behalf of this call (for example, a database is being consulted)."

Which is exactly what we are doing. Section 21.1.1.

Just curious.
By: khb (khb) 2005-03-19 17:09:39.000-0600

Well, you'll find it somewhere,
100 Trying should only be used in dialog creating transactions, so-called INVITE transactions, e.g. INVITE and SUBSCRIBE, (vs. the non-INVITE transactions)


Sorry, Cisco, you too. (still?)  Someone probably copied this from them.
By: Mark Spencer (markster) 2005-03-19 17:23:51.000-0600

Close, but not quite:  Section 8.2.6.1 of RFC3261 says:

  One largely non-method-specific guideline for the generation of
  responses is that UASs SHOULD NOT issue a provisional response for a
  non-INVITE request.  Rather, UASs SHOULD generate a final response to
  a non-INVITE request as soon as possible.

According to RFC 2119, the phrase "SHOULD NOT" is defined as follows:

SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
  there may exist valid reasons in particular circumstances when the
  particular behavior is acceptable or even useful, but the full
  implications should be understood and the case carefully weighed
  before implementing any behavior described with this label.

In the case of Asterisk, when running a REGISTER against a potentially slow database, the 100 Trying allows us to indicate to the other side that the REGISTER request was actually received, even if it takes some time for the database to come back.  My reading of these two specifications permits me to do so, and is not a violation of the SIP protocol.