sip_util.c

sip协议栈

      its usages equally.  In our example scenario, both the
      subscription and the invite usage would be redirected by this
      single response.
  */
  if (response_code < 400) 
    return *return_graceful_terminate_usage = 0;

  if (response_code < 500) switch (response_code) {
  default:
  case 400: /** @par 400 and unrecognized 4xx responses 

      These responses affect only the NOTIFY transaction, not the
      subscription, the dialog it resides in (beyond affecting the local
      CSeq), or any other usage of that dialog. In general, the response
      is a complaint about this transaction, not the usage or dialog the
      transaction occurs in.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 401: 
  case 407: /** @par 401 Unauthorized and 407 Proxy Authentication Required

      This request, not the subscription or dialog, is being challenged. The
      usages and dialog are not terminated.
    */ 
    *return_graceful_terminate_usage = 0;
    return 0;

  case 402: /** @par 402 Payment Required 

      This is a reserved response code. If encountered, it should be
      treated as an unrecognized 4xx.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 403: /** @par 403 Forbidden 

      This response terminates the subscription, but has no effect on
      any other usages of the dialog. In our example scenario, the
      invite usage continues to exist. Similarly, if the 403 came in
      response to a re-INVITE, the invite usage would be terminated, but
      not the subscription.
    */
    return terminate_usage;
    
  case 404: /** @par 404 Not Found 

      This response destroys the dialog and all usages sharing it. The
      Request-URI that is being 404ed is the remote target set by the
      Contact provided by the peer. Getting this response means
      something has gone fundamentally wrong with the dialog state.
    */
    return terminate_dialog;

  case 405: /** @par 405 Method Not Allowed 

      In our example scenario, this response destroys the subscription,
      but not the invite usage or the dialog. It's an aberrant case for
      NOTIFYs to receive a 405 since they only come as a result to
      something that creates subscription. In general, a 405 within a
      given usage affects only that usage, but does not affect other
      usages of the dialog.
    */
    return terminate_usage;

  case 406: /** @par 406 Not Acceptable 

      These responses concern details of the message in the transaction. 
      Subsequent requests in this same usage may succeed. Neither the
      usage nor dialog is terminated, other usages sharing this dialog
      are unaffected.
      */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 408: /** @par 408 Request Timeout 

      Receiving a 408 will have the same effect on
      usages and dialogs as a real transaction timeout as described in
      Section 3.2.
    */
    return terminate_usage;

  case 410: /** @par 410 Gone 

      This response destroys the dialog and all usages sharing
      it.  The Request-URI that is being rejected is the remote target
      set by the Contact provided by the peer.  Similar to 404, getting
      this response means something has gone fundamentally wrong with
      the dialog state, its slightly less aberrant in that the other
      endpoint recognizes that this was once a valid URI that it isn't
      willing to respond to anymore.
    */
    return terminate_dialog;

  case 412: /* Conditional Request Failed: */ 
  case 413: /* Request Entity Too Large: */
  case 414: /* Request-URI Too Long: */
  case 415: /* Unsupported Media Type: */
    /** @par 412, 413, 414 and 415 

      These responses concern details of the message in the transaction. 
      Subsequent requests in this same usage may succeed. Neither the usage
      nor dialog is terminated, other usages sharing this dialog are
      unaffected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 416: /** @par 416 Unsupported URI Scheme 

      Similar to 404 and 410, this response
      came to a request whose Request-URI was provided by the peer in a
      Contact header field.  Something has gone fundamentally wrong, and
      the dialog and all of its usages are destroyed.
    */
    return terminate_dialog;

  case 420: /* Bad Extension */ 
  case 421: /* Extension Required */

    /** @par 420 Bad Extension and 421 Extension Required

      These responses are objecting to the request, not the usage. The
      usage is not affected. The dialog is only affected by a change in
      its local CSeq. No other usages of the dialog are affected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 423: /** @par 423 Interval Too Brief 

      This response won't happen in our example
      scenario, but if it came in response to a re-SUBSCRIBE, the
      subscribe usage is not destroyed (or otherwise affected).  No
      other usages of the dialog are affected.
    */
    *return_graceful_terminate_usage = 0;
    return sip_method_subscribe == method ? terminate_usage : no_effect;

  case 429: /** @par 429 Provide Referrer Identity 

      This response won't be returned to a NOTIFY as in our example
      scenario, but when it is returned to a REFER, it is objecting to
      the REFER request itself, not any usage the REFER occurs within. 
      The usage is unaffected. Any other usages sharing this dialog are
      unaffected. The dialog is only affected by a change in its local
      CSeq.
    */
    *return_graceful_terminate_usage = 0;
    return 0;


  case 480: /** @par 480 Temporarily Unavailable

      @RFC3261 is unclear on what this response means for mid-usage
      requests. Clarifications will be made to show that this response
      affects only the usage in which the request occurs. No other usages
      are affected. If the response included a Retry-After header field,
      further requests in that usage should not be sent until the indicated
      time has past. Requests in other usages may still be sent at any time.
    */
    return terminate_usage;


  case 481: /** @par 481 Call/Transaction Does Not Exist 

      This response indicates that the peer has lost its copy of the dialog
      state. The dialog and any usages sharing it are destroyed.

      OPEN ISSUE: There has been some list discussion indicating a need
      for a response code that only terminates the usage, but not the
      dialog (Motivation: being able to destroy a subscription by
      refusing a NOTIFY without destroying the dialog that that
      subscription exists in, particularly when the susbcription exists
      because of an in-dialog REFER).
    */
    return terminate_dialog;


  case 482: /** @par 482 Loop Detected 

      This response is aberrant mid-dialog.  It will
      only occur if the Record-Route header field was improperly
      constructed by the proxies involved in setting up the dialog's
      initial usage, or if a mid-dialog request forks and merges (which
      should never happen).  Future requests using this dialog state
      will also fail.  The dialog and any usages sharing it are
      destroyed.  
    */
    return terminate_dialog;


  case 483: /** @par 483 Too Many Hops 

      Similar to 482, receiving this mid-dialog is
      aberrant.  Unlike 482, recovery may be possible by increasing
      Max-Forwards (assuming that the requester did something strange
      like using a smaller value for Max-Forwards in mid-dialog requests
      than it used for an initial request).  If the request isn't tried
      with an increased Max-Forwards, then the agent should attempt to
      gracefully terminate this usage and all other usages that share
      its dialog.  
    */
    *return_graceful_terminate_usage = 1;
    return 0;

  case 484: /* Address Incomplete */
  case 485: /* Ambiguous */
    /** @par 484 Address Incomplete and 485 Ambiguous

      Similar to 404 and 410, these
      responses came to a request whose Request-URI was provided by the
      peer in a Contact header field.  Something has gone fundamentally
      wrong, and the dialog and all of its usages are destroyed.
    */
    return terminate_dialog;

  case 486: /** @par 486 Busy Here 

      This response is non-sensical in our example scenario,
      or in any scenario where this response comes inside an established
      usage.  If it occurs in that context, it should be treated as an
      unknown 4xx response.  The usage, and any other usages sharing its
      dialog are unaffected.  The dialog is only affected by the change
      in its local CSeq.  If this response is to a request that is
      attempting to establish a new usage within an existing dialog
      (such as an INVITE sent within a dialog established by a
      subscription), the request fails, no new usage is created, and no
      other usages are affected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 487: /** @par 487 Request Terminated 

      This response speaks to the disposition of a
      particular request (transaction).  The usage in which that request
      occurs is not affected by this response (it may be affected by
      another associated request within that usage).  No other usages
      sharing this dialog are affected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 488: /** @par 488 Not Acceptable Here 

      This response is objecting to the request,
      not the usage.  The usage is not affected.  The dialog is only
      affected by a change in its local CSeq.  No other usages of the
      dialog are affected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 489: /** @par 489 Bad Event 

      In our example scenario, [3] declares that the
      subscription usage in which the NOTIFY is sent is terminated.  The
      invite usage is unaffected and the dialog continues to exist.
      This response is only valid in the context of SUBSCRIBE and
      NOTIFY.  UAC behavior for receiving this response to other methods
      is not specified, but treating it as an unknown 4xx is a
      reasonable practice.
    */
    *return_graceful_terminate_usage = 0;
    return method == sip_method_notify ? terminate_usage : no_effect;

  case 491: /** @par 491 Request Pending 

      This response addresses in-dialog request glare.
      Its affect is scoped to the request.  The usage in which the
      request occurs is not affected.  The dialog is only affected by
      the change in its local CSeq.  No other usages sharing this dialog
      are affected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 493: /** @par 493 Undecipherable 

      This response objects to the request, not the
      usage.  The usage is not affected.  The dialog is only affected by
      a change in its local CSeq.  No other usages of the dialog are
      affected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 494: /** @par 494 Security Agreement Required 

      This response is objecting to the
      request, not the usage.  The usage is not affected.  The dialog is
      only affected by a change in its local CSeq.  No other usages of
      the dialog are affected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;
  }

  if (response_code < 600) switch (response_code) {
  case 500: /* 500 and 5xx unrecognized responses */
  default:
    /** @par 500 and 5xx unrecognized responses

      These responses are complaints against the request (transaction),
      not the usage. If the response contains a Retry-After header field
      value, the server thinks the condition is temporary and the
      request can be retried after the indicated interval. This usage,
      and any other usages sharing the dialog are unaffected. If the
      response does not contain a Retry-After header field value, the UA
      may decide to retry after an interval of its choosing or attempt
      to gracefully terminate the usage. Whether or not to terminate
      other usages depends on the application. If the UA receives a 500
      (or unrecognized 5xx) in response to an attempt to gracefully
      terminate this usage, it can treat this usage as terminated. If
      this is the last usage sharing the dialog, the dialog is also
      terminated.
    */
    /* Do not change *return_graceful_terminate_usage */
    return 0;

  case 501: /** @par 501 Not Implemented 

      This would be a degenerate response in our
      example scenario since the NOTIFY is being sent as part of an
      established subscribe usage.  In this case, the UA knows the
      condition is unrecoverable and should stop attempting to send
      NOTIFYs on this usage.  (It may or may not destroy the usage.  If
      it remembers the bad behavior, it can reject any refresh
      subscription).  In general, this response may or may not affect
      the usage (a 501 to an unknown method or an INFO will not end an
      invite usage).  It will never affect other usages sharing this
      usage's dialog.
    */
    /* Do not change *return_graceful_terminate_usage */
    return 0;

  case 502: /** @par 502 Bad Gateway 

      This response is aberrant mid-dialog. It will only occur if the
      Record-Route header field was improperly constructed by the
      proxies involved in setting up the dialog's initial usage. Future
      requests using this dialog state will also fail. The dialog and
      any usages sharing it are destroyed.
    */
    return terminate_dialog;

  case 503: /** @par 503 Service Unavailable 

      As per [2], the logic handling locating SIP servers for
      transactions may handle 503 requests (effectively sequentially
      forking at the endpoint based on DNS results). If this process
      does not yield a better response, a 503 may be returned to the
      transaction user. Like a 500 response, the error is a complaint
      about this transaction, not the usage. Because this response
      occurred in the context of an established usage (hence an existing
      dialog), the route-set has already been formed and any opportunity
      to try alternate servers (as recommended in [1] has been exhausted
      by the RFC3263 logic. The response should be handled as described
      for 500 earlier in this memo.
    */
    /* Do not change *return_graceful_terminate_usage */
    return 0;

  case 504: /** @par 504 Server Time-out 

      It is not obvious under what circumstances this
      response would be returned to a request in an existing dialog.  If
      it occurs it should have the same affect on the dialog and its
      usages as described for unknown 5xx responses.
    */
    /* Do not change *return_graceful_terminate_usage */
    return 0;

  case 505: /* Version Not Supported */
  case 513: /* Message Too Large */
    /** @par 505 Version Not Supported and 513 Message Too Large

      These responses are objecting to the request, not the usage. The
      usage is not affected. The dialog is only affected by a change in
      its local CSeq. No other usages of the dialog are affected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 580: /** @par 580 Precondition Failure 

      This response is objecting to the request,
      not the usage.  The usage is not affected.  The dialog is only
      affected by a change in its local CSeq.  No other usages of the
      dialog are affected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;
  }

  if (response_code < 700) switch (response_code) {
  case 600: /* 600 and 6xx unrecognized responses */
  default:
    /** @par 600 and 6xx unrecognized responses

      Unlike 400 Bad Request, a 600 response code says something about
      the recipient user, not the request that was made. This end user
      is stating an unwillingness to communicate. 

      If the response contains a Retry-After header field value, the
      user is indicating willingness to communicate later and the
      request can be retried after the indicated interval. This usage,
      and any other usages sharing the dialog are unaffected. If the
      response does not contain a Retry-After header field value, the UA
      may decide to retry after an interval of its choosing or attempt
      to gracefully terminate the usage. Whether or not to terminate
      other usages depends on the application. If the UA receives a 600
      (or unrecognized 6xx) in response to an attempt to gracefully
      terminate this usage, it can treat this usage as terminated. If
      this is the last usage sharing the dialog, the dialog is also
      terminated.
    */
    /* Do not change graceful_terminate */
    return 0;

  case 603: /** @par 603 Decline 

      This response declines the action indicated by the
      associated request.  It can be used, for example, to decline a
      hold or transfer attempt.  Receiving this response does NOT
      terminate the usage it occurs in.  Other usages sharing the dialog
      are unaffected.
    */
    *return_graceful_terminate_usage = 0;
    return 0;

  case 604: /** @par 604 Does Not Exist Anywhere 

      Like 404, this response destroys the
      dialog and all usages sharing it.  The Request-URI that is being
      604ed is the remote target set by the Contact provided by the
      peer.  Getting this response means something has gone
      fundamentally wrong with the dialog state.
    */
    return terminate_dialog;

  case 606: /** @par 606 Not Acceptable 

      This response is objecting to aspects of the
      associated request, not the usage the request appears in.  The
      usage is unaffected.  Any other usages sharing the dialog are
      unaffected.  The only affect on the dialog is the change in the
      local CSeq.
    */
    *return_graceful_terminate_usage = 0;
    return 0;
  }

  /* Do not change graceful_terminate */

  return 0;
}