| 00:46.26 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-64-110.dialup.adsl.anteldata.net.uy) |
| 03:43.09 | *** join/#asterisk-dev sh_smith (foobar@cpe-76-174-26-91.socal.res.rr.com) |
| 04:51.50 | *** join/#asterisk-dev tzafrir (~tzafrir@206.167.44.205) |
| 04:51.50 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:06.35 | *** join/#asterisk-dev tzafrir (~tzafrir@206.167.44.205) |
| 06:06.35 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 06:24.57 | *** join/#asterisk-dev jkroon (~jkroon@uls-154-73-35-201.wall.uls.co.za) |
| 06:42.46 | *** join/#asterisk-dev oej (~oej@h-205-12.A165.corp.bahnhof.se) |
| 06:42.46 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:49.04 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:49.04 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:57.48 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:57.48 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:04.33 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:04.39 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:20.21 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:20.21 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:59.24 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:03.05 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 08:04.56 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 08:26.22 | *** join/#asterisk-dev dustinm (~dustinm@68.ip-149-56-14.net) |
| 08:54.32 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 09:26.40 | *** join/#asterisk-dev leedm777 (~textual@173-16-52-28.client.mchsi.com) |
| 09:26.40 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 10:04.08 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 10:20.02 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.135.186) |
| 11:10.04 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 12:11.40 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 12:11.40 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 12:15.02 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 12:18.54 | tsearle | waves |
| 12:24.57 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-65-214.dialup.adsl.anteldata.net.uy) |
| 12:48.03 | gtjoseph | offers a late wave to tsearle |
| 12:48.25 | tsearle | :) |
| 12:50.24 | tsearle | I don't know if it's taboo to ask, but will any of you guys will be in Chicago next week? |
| 12:51.00 | gtjoseph | Not I. |
| 12:52.49 | file | Nope. |
| 12:53.29 | tsearle | and I know cresl1n won't be either |
| 12:54.08 | tsearle | I guess I might be alone in enemy territory :-P |
| 12:55.04 | gtjoseph | :) |
| 13:12.47 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-wdbrxdyzbbahpnkk) |
| 13:12.47 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:27.32 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-qpkndibstbwmubpm) |
| 13:27.32 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 13:34.13 | jameswf | Who's coming to Orlando with the cool kids :) |
| 13:39.51 | file | People. |
| 13:50.37 | jameswf | Robots? That shoot fire? That would be cool |
| 13:51.04 | cresl1n | It sounds like that there's a good chance that this Astricon is going to be pretty large |
| 13:51.32 | cresl1n | If the number of talk submissions are any indicator |
| 14:04.29 | stefan27 | Orlando? Aren't there angry people with guns there, and alligators? |
| 14:04.39 | cresl1n | That's what they say |
| 14:04.49 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 14:04.49 | *** mode/#asterisk-dev [+o DivideBy0] by ChanServ |
| 14:04.49 | cresl1n | Beware of alligators and guns |
| 14:08.12 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 14:08.12 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:12.02 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ipsqhfytzluulype) |
| 14:12.02 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:16.41 | jameswf | Alligators with guns |
| 15:16.52 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-52-140-83.dialup.adsl.anteldata.net.uy) |
| 16:12.47 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.162) |
| 16:41.45 | rmudgett | file: gtjoseph So... What is the benefit to having a set number of max_contacts to pjsip AORs? In light of rewrite_contact this can get in the way if you re-register after a restart. |
| 16:42.55 | gtjoseph | not sure actually other than limit 1 |
| 16:43.39 | rmudgett | Setting to one actually makes the issue with rewrite_contact more likely. |
| 16:43.43 | gtjoseph | is the issue having a limit of having more than 1? |
| 16:44.05 | file | the issue is that if it's not a refresh then the REGISTER would be rejected |
| 16:44.14 | file | until a contact expires |
| 16:44.38 | rmudgett | Yes. And if the register is rejected, the endpoint may give up trying to register. |
| 16:45.51 | gtjoseph | well, we also have "remove_existing" |
| 16:45.53 | file | I think having remove_existing work in that case smarter would be the option, it would still limit to a max but allow registrations |
| 16:46.07 | rmudgett | There is also the chan_sip compatibility option of remove_existing in the mix. |
| 16:46.56 | rmudgett | file: How could remove_existing work smarter? |
| 16:47.06 | file | what does it do right now in that scenario? |
| 16:49.46 | gtjoseph | are we thinking that multiple contacts will be an issue or that having the set limit will be? |
| 16:50.06 | file | the set limit is the problem |
| 16:50.08 | rmudgett | The set limit is the problem. |
| 16:50.55 | file | I think remove_existing should remove the number of contacts required to allow the new REGISTER to succeed |
| 16:51.31 | gtjoseph | but which ones? Oldest? |
| 16:51.43 | file | the ones that will expire naturally soonest |
| 16:51.50 | gtjoseph | yeah makes sense |
| 16:52.30 | rmudgett | Remove existing removes all contacts that were not just registered. After it ignores any currently in the contacts container |
| 16:52.53 | rmudgett | remove_existing won't let you add more than max_contacts |
| 16:53.13 | file | I know, I'm saying I think it is reasonable for the behavior to change to the above |
| 16:53.21 | file | which solves the problem |
| 16:54.35 | rmudgett | I'm just wondering why have a set limit. Either max_contacts=0 to disable registrations or max_contacts=infinity. |
| 16:55.42 | gtjoseph | not sure i can think of an exact use case immediately but we really can't change it now |
| 16:55.45 | rmudgett | Is there some benefit to setting max_contacts=3 for instance? |
| 16:56.31 | file | outright benefit? no - but it can limit exposure |
| 16:56.31 | rmudgett | It could be documented that max_contacts is not a security feature and is not recommended to set it to a low value. |
| 16:56.49 | file | specifying a recommendation is fine |
| 16:56.56 | file | but as gtjoseph said - it's not getting removed |
| 16:57.35 | gtjoseph | it can also be used by a service provider to only allow a certain number of servers to register to an endpoint. |
| 16:58.57 | rmudgett | Which said service provider is likely to need rewrite_contact enabled and cause the problem of hitting the limit because of the random remote port number being registered. |
| 16:59.18 | file | which is why I said I think it's reasonable for remove_existing to behave as I stated, which solves the problem |
| 16:59.31 | gtjoseph | exactly |
| 17:01.50 | rmudgett | That changes remove_existing behavior from chan_sip behavior as it is documented to enable. |
| 17:02.40 | file | in a configuration that mirrors chan_sip it would function the same |
| 17:02.55 | file | the only scenario where it functions differently is if multiple contacts are enabled, which is a chan_pjsip feature |
| 17:03.09 | file | and it would function in a way which is better for the user |
| 17:03.46 | file | and if you are enabling multiple contacts then the existing behavior is against that from the first place - as others would be removed defeating it in the first place |
| 17:06.58 | rmudgett | So. The behavior is: |
| 17:06.58 | rmudgett | 1) Don't check max_contacts if remove_existing is enabled |
| 17:06.58 | rmudgett | 2) Process the register contacts. |
| 17:06.58 | rmudgett | 3) Remove the soonest to expire contacts until there are at most max_contacts. |
| 17:06.58 | rmudgett | 4) send register response |
| 17:07.35 | file | if you are referring to new logic, yes, that sounds about right |
| 17:12.45 | rmudgett | With the new behavior, remove_existing could use a better name. |
| 17:16.45 | *** join/#asterisk-dev newtonr (newtonr@nat/digium/x-zomjiwqycnoluwkd) |
| 17:16.45 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 17:42.23 | gtjoseph | rmudgett: careful with that logic... depending on Expires, times the pass that removes the soonest to expire might remove the one just registered. |
| 17:42.40 | gtjoseph | s/times// |
| 17:43.21 | gtjoseph | i think you have to remove until there's an open spot, then register. |
| 17:50.43 | rmudgett | We certainly cannot add more than the max. We already keep track of the unmodified contacts so we can remove the soonest to expire unmodified contacts. |
| 17:52.43 | gtjoseph | ok, so long as it's "unmodified contacts" |
| 18:06.39 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 18:06.39 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 18:39.32 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 18:39.32 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:12.52 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:12.52 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:28.35 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 19:28.35 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 19:30.11 | *** join/#asterisk-dev joshelson (~joshelson@12.226.100.2) |
| 19:41.58 | *** join/#asterisk-dev joshelson (~joshelson@12.226.100.2) |
| 19:51.19 | *** join/#asterisk-dev joshelson (~joshelson@12.226.100.2) |
| 20:25.41 | *** join/#asterisk-dev joshelson (~joshelson@12.226.100.2) |
| 20:56.04 | *** join/#asterisk-dev joshelson (~joshelson@12.226.100.2) |
| 20:59.30 | *** join/#asterisk-dev scgm11_ (~scgm11@r186-49-63-63.dialup.adsl.anteldata.net.uy) |
| 21:04.00 | *** join/#asterisk-dev joshelson (~joshelson@12.226.100.2) |
| 21:59.07 | *** join/#asterisk-dev joshelson (~joshelson@12.226.100.2) |
| 22:17.34 | *** join/#asterisk-dev joshelson (~joshelson@12.226.100.2) |
| 22:25.51 | *** join/#asterisk-dev tzafrir (~tzafrir@206.167.44.205) |
| 22:25.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:34.22 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-qpkndibstbwmubpm) |