anchor.diff:  %%
   %% -------------------------------------------------------------------
   
  -%% @doc SipApp callback behaviour and callbacks default implementation.
  -%%
  -%% WARNING Documentation is fully obsolete
  -%%
  -%% All of the available functions you can implement in your callback module are described 
  -%% here, along with the default implementation of each one.
  -%%
  -%% Every <b>SipApp</b> must define a <i>callback module</i>, using this module's behaviour. 
  -%% This behaviour works in a very similar way to any standard Erlang `gen_server' 
  -%% callback module, but only {@link init/1} is mandatory.
  -%%
  -%% Depending on the phase of the request processing, different functions will be called. 
  -%% Some of these calls expect an answer from the SipApp to continue the processing, 
  -%% and some others are called to inform the SipApp about a specific event and don't 
  -%% expect any answer. As in `gen_server', the current SipApp state (created in the call
  -%% to `init/1') will be sent in every call, and can be updated by the SipApp
  -%% implementation in every function return.
  -%%
  -%% Except for `init/1', all defined functions belong
  -%% to one of two groups: <i>expected answer</i> functions and 
  -%% <i>no expected answer</i> functions.
  -%%
  -%% The supported return values for <i>expected answer functions</i> are:
  -%% ```
  -%%   call_reply() :: 
  -%%       {noreply, State} | {noreply, State, Timeout} | 
  -%%       {reply, Reply, State} | {reply, Reply, State, Timeout} | 
  -%%       {stop, Reason, State} | {stop, Reason, Reply, State}
  -%%       when State :: term(), Timeout :: infinity | non_neg_integer(), Reason :: term()
  -%% '''     
  -%%
  -%% The function is expected to return `State' as new SipApp user's state and a `Reply', 
  -%% whose meaning is specific to each function and it is described bellow. 
  -%% If a `Timeout' is defined the SipApp process will receive a `timeout' message 
  -%% after the indicated milliseconds period (you must implement {@link handle_info/2}
  -%% to receive it). 
  -%% If the function returns `stop' the SipApp will be stopped. 
  -%% If the function does not want to return a reply just know, it must return 
  -%% `{noreply, State}' and call {@link nksip:reply/2} later on, 
  -%% possibly from a different spawned process.
  -%%
  -%% The supported return values for <i>no expected answer functions</i> are:
  -%% ```
  -%%   call_noreply() :: 
  -%%       {noreply, State} | {noreply, State, Timeout} | 
  -%%       {stop, Reason, State} 
  -%%       when State :: term(), Timeout :: infinity | non_neg_integer(), Reason :: term()
  -%% '''     
  -%%
  -%% Some of the callback functions allow the SipApp to send a response back
  -%% to the calling party. See the available responses in {@link nksip_reply}.
  -%%
  -%% A typical call order would be the following:
  -%% <ol>
  -%%  <li>When starting the SipApp, {@link init/1} is called to initialize the 
  -%%      application state.</li>
  -%%  <li>When a request is received having an <i>Authorization</i> or 
  -%%      <i>Proxy-Authorization</i> header, {@link sip_get_user_pass/3} is called to check
  -%%      the user's password.</li>
  -%%  <li>NkSIP calls {@link sip_authorize/4} to check is the request should be
  -%%      authorized.</li>
  -%%  <li>If authorized, it calls {@link route/6} to decide what to do with the 
  -%%      request: reply, route or process locally.</li>
  -%%  <li>If the request is going to be processed locally, {@link invite/3},
  -%%      {@link options/3}, {@link register/3} or {@link bye/3} are called,
  -%%      and the user must send a reply. 
  -%%      If the request is a valid <i>CANCEL</i>, belonging to an active <i>INVITE</i>
  -%%      transaction, the INVITE is cancelled and {@link cancel/2} is called.</li>
  -%%  <li>After sending a successful response to an <i>INVITE</i> request,
  -%%      the other party will send an <i>ACK</i> and {@link ack/3} will be called.</li>
  -%%  <li>If the request creates or modifies a dialog and/or a SDP session, 
  -%%      {@link dialog_update/3} and/or {@link session_update/3} are called.</li>
  -%%  <li>If the remote party sends an in-dialog invite (a <i>reINVITE</i>),
  -%%      NkSIP will call {@link reinvite/3}.</li>
  -%%  <li>If the user has set up an automatic ping or registration, 
  -%%      {@link ping_update/3} or {@link register_update/3} are called on each
  -%%      status change.</li>
  -%%  <li>When the SipApp is stopped, {@link terminate/2} is called.</li>
  -%% </ol>
  -%%
  -%%
  -%% It is <b>very important</b> to notice that, as in using normal `gen_server', 
  -%% there is a single SipApp core process, so you must not spend a long time in any of 
  -%% the callback functions. If you do so, new requests arriving at your SipApp will be 
  -%% blocked and the other party will start to send retransmissions. As no transaction 
  -%% has been created yet, NkSIP will see them as new requests that will be also blocked, 
  -%% and so on.
  -%%
  -%% If the expected processing time of any of your callback functions is high 
  -%% (more than a few milliseconds), you must spawn a new process, return `{noreply, ...}' 
  -%% and do any time-consuming work there. If the called function spawning the process is 
  -%% in the expected answer group, it must call {@link nksip:reply/2} from the spawned 
  -%% process when a reply is available. 
  -%% Launching new processes in Erlang is a very cheap operation, 
  -%% so in case of doubt follow this recommendation.
  -%%
  -%% Many of the callback functions receive a `RequestId' ({@link nksip:id()}) 
  -%% and a `Meta' (a list of properties) parameters.
  -%% Depending on the function, `Meta' will contain the most useful parameters you
  -%% will need to process the request (like de content-type and body). 
  -%% You can use `ReqId' to obtain any oher parameter from the request or dialog, 
  -%% using the helper funcions in {@link nksip_request} and {@link nksip_dialog}.
  -%%
  -%% <b>Inline functions</b>
  -%%
  -%% NkSIP offers another option for defining callback functions. Many of them have
  -%% an <i>inline</i> form, which, if defined, it will be called instead of 
  -%% the <i>normal</i> form.
  -%%
  -%% Inline functions have the same name of normal functions, but they don't have the
  -%% last `State' parameter. 
  -%% They are called in-process, inside the call processing process and
  -%% not from the SipApp's process like the normal functions.
  -%%
  -%% Inline functions are much quicker, but they can't modify the SipApp state. 
  -%% They received a full {@link nksip:request()} object in `Meta', so it can use
  -%% the functions in {@link nksip_sipmsg} to process it.
  -%% See `inline_test' for an example of use
  -
  +%% @doc SipApp callback behaviour and default implementation.
   -module(nksip_sipapp).
   -author('Carlos Gonzalez <carlosj.gf@gmail.com>').
   
  --export([init/1, sip_get_user_pass/4, sip_authorize/3, sip_route/5]).
  +-export([sip_get_user_pass/4, sip_authorize/3, sip_route/5]).
   -export([sip_invite/2, sip_reinvite/2, sip_cancel/3, sip_ack/2, sip_bye/2]).
   -export([sip_options/2, sip_register/2, sip_info/2, sip_prack/2, sip_update/2]).
   -export([sip_subscribe/2, sip_resubscribe/2, sip_notify/2, sip_message/2]).
  
positive.code: 
  
  %% @doc This function is called by NkSIP to process a new incoming SUBSCRIBE
  %% request that has an allowed Event type.
  %%
  %% If you reply a 2xx response like `ok'  or `accepted', a dialog and a subscription
  %% will start, and you must inmeditaly send a NOTIFY using 
  %% {@link nksip_uac:notify/3}.
  %%
  %% You can use the option `{expires, integer()}' to override the expires present
  %% in the request, but the new value must be lower, or even 0 to cancel the
  %% subscription.
  %%
  %% `Meta' will include at least the following parameters: aor, dialog_id, event,
  %% subscription_id and parsed_expires (see {@link nksip_request} for details).
  %%
  -spec sip_subscribe(Req::nksip:request(), Call::nksip:call()) ->
      {reply, nksip:sipreply()} | noreply.
  
  
negative.code: 
  
  %% @doc Called for every incoming request to be authorized or not.
  -spec sip_authorize(AuthList, Req::nksip:request(), Call::nksip:call()) ->
      ok | forbidden | authenticate | {authenticate, Realm::binary()} |
      proxy_authenticate | {proxy_authenticate, Realm::binary()}
  