sip_util.c

Sofia SIP is an open-source SIP User-Agent library, compliant with the IETF RFC3261 specification.

      not the subscription.
    */
    *return_graceful_terminate_usage = 0;
    return 0;
    
  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.
    */
    switch (method) {
    case sip_method_notify:
    case sip_method_subscribe:
    case sip_method_invite:
      return terminate_usage;
    default:
      *return_graceful_terminate_usage = 0;
      return 0;
    }

  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 417:
    /** @par 417 Uknown Resource-Priority
      The effect of this response on usages
      and dialogs is analgous to that for 420 and 488.  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.
    */

  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.
    */

  case 422: /** @par 422 Session Interval Too Small

      This response will not be returned to
      a NOTIFY in our example scenario.  This response is non-sensical
      for any mid-usage request.  If it is received, an element in the
      path of the request is violating protocol, and the recipient
      should treat this as it would an unknown 4xx response.  If the
      response came to a request that was attempting to establish a new
      usage in an existing dialog, no new usage is created and existing
      usages are unaffected.
    */

  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.
    */

  case 428: /** @par 428 Use Identity Header

      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. */

  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.
    */

  case 436: case 437: case 438:
    /** @par 436 Bad Identity-Info, 437 Unsupported Certificate, 438 Invalid \
     *  Identity Header 
     *
     * These responses object 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 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 @RetryAfter 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.

      The dialog
      itself should not be destroyed unless this was the last usage.
      The effects of a 481 on a dialog and its usages are the most
      ambiguous of any final response.  There are implementations that
      have chosen the meaning recommended here, and others that destroy
      the entire dialog without regard to the number of outstanding
      usages.  Going forward with this clarification will allow those
      deployed implementations that assumed only the usage was destroyed
      to work with a wider number of implementations.  Those that made
      the other choice will continue to function as they do now,
      suffering at most the same extra messages needed for a peer to
      discover that that other usages have gone away that they currently
      do.  However, the necessary clarification to @RFC3261 needs to
      make it very clear that the ability to terminate usages
      independently from the overall dialog using a 481 is not
      justification for designing new applications that count on
      multiple usages in a dialog.
    */
    return terminate_usage;


  case 482: /** @par 482 Loop Detected 

      This response is aberrant mid-dialog.  It will
      only occur if the @RecordRoute 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
      @MaxForwards (assuming that the requester did something strange
      like using a smaller value for @MaxForwards in mid-dialog requests
      than it used for an initial request).  If the request isn't tried
      with an increased @MaxForwards, 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, @RFC3265 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 @RetryAfter 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 @RetryAfter 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
      @RecordRoute 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 @RFC3263, 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 @RFC3261) 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 @RetryAfter 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 @RetryAfter 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;
}