[sr-dev] git:andrei/send_flags: core: new close after send and reuse only script functions

Andrei Pelinescu-Onciul andrei at iptel.org
Tue Sep 22 11:43:25 CEST 2009


On Sep 21, 2009 at 14:41, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> Hi Andrei!
> 
> I'm still not sure for the correct usage.
> 
> If I got it right, set_forward_* is for relaying of messages (regardless 
> if it is a request or reponse) and set_reply_* is for local generated 
> replies (explicit in script or implicit somewhere in a module)

set_reply_* is for local generated replies and replies forwarded by tm
, but depends in which route you use it:

- normal route, e.g. set_reply_no_connect(); t_relay();
 => affects all replies sent back on the transaction (either local or
  "forwarded") and all local stateless replies (sl_reply()).

- onreply_route: affects the current reply (so the send_flags set in the
  onreply_route will be used if the reply for which they were set is the
  winning final reply or it's a provisional reply that is forwarded)

- branch_route: ignored.

- onsend_route: ignored

set_forward_*:

- normal route: affects stateless forwards and tm (for tm it affects all
  the branches and the possible retransmissions).

- onreply_route[0] (stateless) and stateless reply forwarding: equivalent
to set_reply_*() (it's better to use set_rpl_* though)

- onreply_route[!=0] (tm): ignored

- branch_route: affects the current branch (all messages sent on this
  branch, like possible retransmissions and cancels).

- onsend_route: current message and current branch (like branch route).


Note that right now we have only 2 send flags, that both deal only with
connections on tcp/tls (and in the future sctp) and thus they won't
affect retransmission because tm doesn't retransmit on them (with the
only exception of 2xx local replies).
However in the future I will add the possibility to set blacklist flags
(e.g. set_no_blst(...) or something like set_blacklist_ignore_503()) and
this will do something even on udp.


Andrei



More information about the sr-dev mailing list