Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs
On 03/15/2016 05:29 AM, Daniel-Constantin Mierla wrote: Tracking only some routing info for invite to help with cancels can eventually done easier as suggested previously, even now. After considering what you have had to say on the complexities in TM, I agree. So, let's drop this item. -- Alex Balashov | Principal | Evariste Systems LLC 1447 Peachtree Street NE, Suite 700 Atlanta, GA 30309 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs
Hello, On 15/03/16 09:16, Alex Balashov wrote: > [...] > > However, I don't know what other dependencies it would have; are > branches not a part of TM state as well? Or is it just a question of > far too many data structures to dump/restore? It is a ton of stuff there, from avps, xavps, flags, branch flags, the list with changes done in request route, the list of changes done in each branch_route, the list of changes per responses, last most relevant response per branch. Those and other fields use shortcuts point in existing buffers in memory, so they need to be converted in a form suitable for storage and then restore ... So storing full transaction info and restoring is not going to be easy, of course, doable, it's open source, but will costs significant resources. Also, there can be performance penalty if done for each transaction and each change of state/content... Tracking only some routing info for invite to help with cancels can eventually done easier as suggested previously, even now. Cheers, Daniel > >> This is a thing of investing a lot of resources to get a solution >> for 0.01% or less, which in most of the cases sort out themselves >> fairly nice. > > Fair enough. I think you're probably right on that, I just wondered if > maybe there was a lower-hanging fruit option. > > I do think you're right that the best mitigation for this problem is > probably to have two Kamailio servers and an externally settable (i.e. > via MI/RPC) $shv that allows one to take it "out of service", i.e. > reject all new requests. Let the calls bleed off, then restart it. > > -- Alex > -- Daniel-Constantin Mierla http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs
On 15/03/16 09:31, Juha Heinanen wrote: > Alex Balashov writes: > >> I don't know about that. Granted, I work largely within the >> intra-carrier/intra-industrial space, not so much with end-user >> endpoints, but to me it seems UDP is still the overwhelming norm. > In that space I would assume that SIP over TLS is mandatory. Anything > else is a big security risk to users. If carriers exchange SIP requests > over the Internet over UDP, they should be sued for not protecting their > customers privacy. > Actually became quite common deployment here to use TLS from end user to an edge proxy and then switching to private network (or vpn) for core network routing, where UDP is still used given its lightweight design and native async communication. I agree that a professional service should not use anything than TLS on public internet, but there is still a lot of demand for UDP for private links. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs
Alex Balashov writes: > I don't know about that. Granted, I work largely within the > intra-carrier/intra-industrial space, not so much with end-user > endpoints, but to me it seems UDP is still the overwhelming norm. In that space I would assume that SIP over TLS is mandatory. Anything else is a big security risk to users. If carriers exchange SIP requests over the Internet over UDP, they should be sued for not protecting their customers privacy. -- Juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs
I don't know about that. Granted, I work largely within the intra-carrier/intra-industrial space, not so much with end-user endpoints, but to me it seems UDP is still the overwhelming norm. TCP has made some inroads as a solution to certain categories of problems, and has become rather less "exotic" in this sense. But it's still not anything like a default. -- Alex Balashov | Principal | Evariste Systems LLC 1447 Peachtree Street NE, Suite 700 Atlanta, GA 30309 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ Sent from my BlackBerry. Original Message From: Juha Heinanen Sent: Tuesday, March 15, 2016 04:21 To: Kamailio (SER) - Users Mailing List Reply To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs Alex Balashov writes: > I definitely had in mind a minimalistic solution which has few > dependencies on other elements of state -- and certainly, in my mind, it > was implicitly UDP-only. I thought that SIP over UDP had already disappeared from the planet. -- Juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs
Alex Balashov writes: > I definitely had in mind a minimalistic solution which has few > dependencies on other elements of state -- and certainly, in my mind, it > was implicitly UDP-only. I thought that SIP over UDP had already disappeared from the planet. -- Juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs
Hi Daniel, On 03/15/2016 04:04 AM, Daniel-Constantin Mierla wrote: This was discussed a lot during early days of SER and even many times along the 15 years so far. I see! Sorry, perhaps I should have dug deeper into list archives and folklore before suggesting it. The persistence of transaction is not something easy, because of its complex relations with timers for retransmissions over udp, but also with connections for tcp/tls. Each transaction has a lot of states, particularly bound to each outgoing branches that can be at different phases. I definitely had in mind a minimalistic solution which has few dependencies on other elements of state -- and certainly, in my mind, it was implicitly UDP-only. I was thinking to just dump the current timer values and restore them on the assumption that the passage of time was "stopped" while the server was down, or, if these timers are done with reference to gettimeofday/wall clock time, then, on the contrary, allow it to elapse and dig into the timer allowance. In other words, keep it simple, lazy. However, I don't know what other dependencies it would have; are branches not a part of TM state as well? Or is it just a question of far too many data structures to dump/restore? This is a thing of investing a lot of resources to get a solution for 0.01% or less, which in most of the cases sort out themselves fairly nice. Fair enough. I think you're probably right on that, I just wondered if maybe there was a lower-hanging fruit option. I do think you're right that the best mitigation for this problem is probably to have two Kamailio servers and an externally settable (i.e. via MI/RPC) $shv that allows one to take it "out of service", i.e. reject all new requests. Let the calls bleed off, then restart it. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 1447 Peachtree Street NE, Suite 700 Atlanta, GA 30309 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs
This was discussed a lot during early days of SER and even many times
along the 15 years so far.
The persistence of transaction is not something easy, because of its
complex relations with timers for retransmissions over udp, but also
with connections for tcp/tls. Each transaction has a lot of states,
particularly bound to each outgoing branches that can be at different
phases.
So after a restart, any connection with a device behind nat cannot be
established, so all those transactions are dead anyhow. For UDP, each
branch can be in different state, with provisional replies received or
not, with some of the branches at different retransmission intervals
(now even more complex given that with tsilo one can add a branch at any
time).
This is a thing of investing a lot of resources to get a solution for
0.01% or less, which in most of the cases sort out themselves fairly
nice. If someone has those resources and considers these to be critical
for them, I won't have anything against provided that the start of the
server is not significantly delayed (or an option to turn this of exists).
You can do some more workarounds from the config to narrow down these cases:
- drop replies if associated transactions don't exist
- use htable to store where branches are going and then send cancel to
them (htable can save to db at shut down)
- instead of htable, external systems can be used for storage, like
redis or any sql via sqlops. Anyhow, you will hit them only when the
invite transaction doesn't exist. You can also enable storage in them
via some rpc command (e.g. turning a $shv() on), few minutes before you
expect a restart.
Also, with the new proposed embedded languages scripting routing in 5.0,
restarts should be needed less and less, as routing rules/blocks can be
reloaded. So it should help on this topic as well.
Cheers,
Daniel
On 14/03/16 22:00, Alex Balashov wrote:
> Currently (AFAIK), restarting Kamailio amidst production call
> processing is basically "safe"; except for no availability during the
> few seconds it takes to restart (which will just result in
> retransmissions until it is available), most things will happen
> "correctly" after restart even though TM state has been lost:
>
> (1) Initial requests will be routed as initial requests always were;
>
> (2) In-dialog requests will be loose-routed as sequential requests
> always were;
>
> (3) Replies to open transactions will fall back to stateless routing
> but will be delivered correctly to their destinations based on SIP
> fundamentals (i.e. Via).
>
> (4) rtpproxy & rtpengine control messages are grouped by Call-ID, so
> also stateless. If the proper destroy/remove functions are not called
> from failure_route[] due to lack of TM state, it's not so bad;
> rtpproxy & rtpengine will see an RTP timeout after a while and expire
> the bindings on their own.
>
> If dialog state is used, it will be lost, but assuming one is willing
> to live with that, it's okay. I don't know if there has been any work
> done to create a persistence layer for dialog that can be re-read
> completely on startup, and if it actually works - does it? - but it's
> a relatively small price to pay if it's important to integrate a
> change into production in the middle of the day.
>
> The one exception is CANCEL handling. CANCEL is a special animal,
> since it's a hop-by-hop (branch-level) request, so CANCELs sent from a
> caller apply to the 'caller -> Kamailio' branch. Kamailio generates
> separate CANCELs endogenously for one or more 'Kamailio -> gateway'
> branches.
>
> Stateful CANCEL handling with TM is implemented using t_check_trans()
> or t_relay_cancel(). For example, in the stock config[1]
>
># CANCEL processing
>if (is_method("CANCEL")) {
> if (t_check_trans()) {
> route(RELAY);
>}
>
>exit;
>}
>
> Or, as in our case, more folklorically:
>
>if(is_method("CANCEL")) {
> if(!t_relay_cancel()) {
> # Corresponding INVITE transaction found, but error
> # occurred.
>
> sl_send_reply("500", "Internal Server Error");
> exit;
> }
>
> # Corresponding INVITE transaction for CANCEL was not
> # found.
>
> exit;
>}
>
> In both cases, the corresponding INVITE transaction must exist.
>
> Unfortunately, there's no good alternative. According to RFC 3261
> Section 16.11 ("Stateless Proxy"):
>
>Stateless proxies MUST NOT perform special processing for
>CANCEL requests. They are processed by the above rules
>as any other requests.
>
> So, in other words, route_logic(CANCEL) == route_logic(initial INVITE).
>
> Sometimes, this is possible - with considerable config logic labour -
> but other times the path taken by the CANCEL is not so deterministic,
> as for example with round-robin load balancing, random distribution,
> complex LCR, etc. One is basically left in these situations with the
> choice of implementing one's own Call-ID/branch => destination
>
