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

[Klaus Darilion]

Ok. Thanks. I have extended the documentation:
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#set_forward_no_connect

regards
klaus

Andrei Pelinescu-Onciul schrieb:
> 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