| 02:58.41 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 03:45.39 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 04:50.31 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 04:51.41 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 06:02.08 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:51.16 | *** join/#asterisk-dev goddva (~goddva@77.40.154.242) |
| 07:04.03 | *** join/#asterisk-dev Gugge (gugge@92.246.2.105) |
| 07:04.04 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 07:04.13 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 07:04.34 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 07:05.19 | *** join/#asterisk-dev Qwell (~north@asterisk/developer/Qwell) |
| 07:05.19 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 07:06.02 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 07:10.16 | *** join/#asterisk-dev doome_ (~doome@94-21-148-51.pool.digikabel.hu) |
| 07:33.10 | *** join/#asterisk-dev lumasepa (~gestoip@193.145.124.30.local.ull.es) |
| 07:37.09 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:06.02 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 09:00.43 | *** join/#asterisk-dev doome_ (~doome@82.150.48.146) |
| 09:03.20 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:03.20 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:26.47 | *** join/#asterisk-dev bof23 (~Thunderbi@185.13.183.107) |
| 11:21.51 | *** join/#asterisk-dev doome_ (~doome@82.150.48.146) |
| 11:30.24 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 12:04.52 | *** join/#asterisk-dev stefan27 (~stefan27@212.247.4.149) |
| 12:44.48 | stefan27 | Unwanted sip INVITES to my asterisk 13 go to [default] where I do Hangup. Asterisk then sends Trying and Decline, but asterisk also temporarily opens rtp ports which is seen by 'netstat -tupan | grep asterisk'. I don't want unwanted invites to open rtp ports, because all ports quickly get depleted if invites are spammed, and I first asked in #asterisk but even after discussion there |
| 12:44.48 | stefan27 | couldn't find any sip.conf setting which disabled this behavior |
| 12:45.20 | stefan27 | is chan_sip hardwired to always allocate rtp ports when receving an invite? |
| 12:46.20 | file | probably |
| 12:48.41 | stefan27 | If I want to dig into source out of curiousity, do you know which function is a good starting point for tracing this flow? |
| 12:49.45 | stefan27 | hmm, I think I'll make a JIRA out of this for a longer discussion |
| 12:50.20 | file | uhhhh I don't remember chan_sip that much |
| 13:07.59 | *** join/#asterisk-dev doome_ (~doome@82.150.48.146) |
| 13:09.15 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 13:33.01 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:56.33 | file | achoo |
| 13:59.49 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 14:02.52 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 14:43.12 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 14:57.32 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-xlklufsmwvzcamaj) |
| 15:26.45 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-gsgkgehcgwbizzws) |
| 15:55.25 | *** join/#asterisk-dev acidfoo_ (~acidfoo@69-165-149-25.dsl.teksavvy.com) |
| 16:14.52 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 16:14.52 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:22.47 | file | gtjoseph, I assume you want the security level adjusted? |
| 16:22.59 | gtjoseph | please |
| 16:23.04 | putnopvut | The PJSIP_CONTACT() dialplan function test fails sometimes due to a race condition. When retrieving a contact_status object, the function to do so is a "find_or_create" function. Thread A tries to retrieve a contact_status for Alice, finds that one does not exist, and creates Alice contact_status object 1. Thread B attempts the same thing at nearly the same time. Thread B does not find a contact_status object for Alice, so |
| 16:23.04 | putnopvut | it creates contact_status object 2. |
| 16:23.08 | gtjoseph | was just writing the email |
| 16:23.11 | file | helps if I log in |
| 16:23.34 | file | gtjoseph, done |
| 16:23.39 | gtjoseph | thanks |
| 16:24.05 | putnopvut | Later, when the contact_status is updated, object 1 gets updated so that the contact status is "unknown", and the RTT is "n/a". But when the PJSIP_CONTACT() dialplan function is called, it's retrieving contact_status object 2 instead, which still has the values that were set on initialization. |
| 16:24.15 | putnopvut | Therefore, PJSIP_CONTACT() gets unexpected values and the test fails. |
| 16:24.32 | putnopvut | So the problem is clearly that two separate contact_status objects are being created for the same contact. |
| 16:24.44 | putnopvut | There are two ways I've considered approaching fixing this problem. |
| 16:25.17 | putnopvut | 1) The "find_or_create" contact_status function can have a lock around the entire operation. This way, finding and creating is atomic. You can't have two threads attempt to create a contact_status for the same contact. |
| 16:25.58 | putnopvut | 2) Change sorcery so that it does not permit objects with duplicate IDs to be created. This way, if one thread attempts to create a second contact_status with the same ID, it will see that one already exists. |
| 16:26.55 | gtjoseph | i'd go with 1. seels like 2 would require an extra lookup every time |
| 16:26.56 | putnopvut | Solution 1 would fix the problem at hand, but I don't know if there are other sorcery object types that might fall into this same trap. Solution 2 seems like it should be fine, but I don't know if there's a legitimate reason to ever allow for sorcery objects with duplicate IDs to exist. |
| 16:27.28 | putnopvut | gtjoseph: it would only require an extra lookup if the creation ended up failing due to the existence of a duplicate object. |
| 16:27.46 | file | yeah, 2 already happens (or should) when you persist |
| 16:27.47 | gtjoseph | what would make the create fail though? |
| 16:28.06 | file | it's up to the backend to fail, though |
| 16:28.14 | gtjoseph | yes, which it might not |
| 16:28.26 | putnopvut | 2 doesn't happen for res_sorcery_memory(), which is the default storage for contact_status |
| 16:29.16 | file | I'd do both then |
| 16:29.20 | file | fix res_sorcery_memory |
| 16:29.26 | file | and fix find_or_create |
| 16:30.02 | putnopvut | All right, I'll do that. |
| 17:10.40 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 17:10.48 | *** join/#asterisk-dev DivideBy0 (~DivideBy0@unaffiliated/divideby0x0) |
| 18:50.45 | *** join/#asterisk-dev leedm777 (~leedm777@50-81-28-152.client.mchsi.com) |
| 19:21.23 | gtjoseph | putnopvut: changing the container to AO2_CONTAINER_ALLOC_OPT_DUPS_REJECT might be faster |
| 19:21.45 | putnopvut | The problem with that is that it requires a sorted container (or at least a sort function) |
| 19:21.57 | gtjoseph | yeah, true |
| 19:23.03 | gtjoseph | although, given that it's infrequently written the sort option might still be faster |
| 19:24.57 | gtjoseph | and the sort function only needs to return 1. |
| 19:49.44 | gtjoseph | putnopvut: topic mismatch. :) |
| 19:50.13 | putnopvut | looks |
| 19:50.39 | putnopvut | Ah, if you don't specify -t in 'git review' it apparently will wipe the previous topic from your review... |
| 19:50.48 | putnopvut | My branch is just called "creation_race" |
| 19:51.02 | putnopvut | Thanks! |
| 20:09.14 | *** join/#asterisk-dev acidfoo_ (~acidfoo@69-165-149-25.dsl.teksavvy.com) |
| 20:17.24 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 20:31.12 | *** join/#asterisk-dev w9sh (~sph@c-73-54-187-250.hsd1.ga.comcast.net) |
| 20:37.04 | *** join/#asterisk-dev pchero (~pchero@109.70.54.56) |
| 21:52.58 | gtjoseph | need some opinions about the PJSIP_HEADER dialplan function and header replacement... |
| 21:53.29 | file | 9. |
| 21:53.33 | gtjoseph | if the res_pjsip_header_functions module loads early (which it does), |
| 21:53.35 | gtjoseph | :) |
| 21:54.11 | gtjoseph | then it's supplements are going to be called first and any headers it adds can be overwritten by the "real" module. |
| 21:54.36 | gtjoseph | res_pjsip_caller_id for instance, overwrrites ir |
| 21:54.37 | gtjoseph | it |
| 21:55.02 | gtjoseph | but if res_pjsip_header_functions loads later, then it's going to add duplicate headers |
| 21:55.09 | gtjoseph | because it doesn't check |
| 21:55.29 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 21:55.29 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:55.51 | gtjoseph | so should it... allow the dups, overwrite, or refuse to add? |
| 21:56.25 | file | in this specific context, or just in general? |
| 21:56.50 | gtjoseph | well, the header module has no idea what type of header it's adding, so in general. |
| 21:57.27 | file | whether multiple headers or not can exist for a header is header specific |
| 21:57.42 | gtjoseph | yeah |
| 21:58.00 | gtjoseph | which makes it even worse |
| 21:58.04 | file | yup |
| 21:58.26 | file | I'm a bit meh that we allow non X- headers to be added in the first place... wonder how much you could break things |
| 21:58.34 | file | a fun experiment for the weekend |
| 21:58.57 | file | or for my train travel Thursday... now that I think of it |
| 21:58.58 | file | ANYWAY |
| 21:59.11 | gtjoseph | it all depends on the load order and what the "real" modules do |
| 21:59.25 | gtjoseph | i'm thinking that we leave it as is for now |
| 21:59.38 | file | aye |
| 21:59.40 | file | putnopvut, thoughts? |
| 22:00.23 | putnopvut | reads |
| 22:00.43 | gtjoseph | the alternative is that we add a parameter to PJSIP_HEADER with ran action like eplace, add, etc. |
| 22:02.42 | putnopvut | Yeah, unfortunately the answer of whether to allow duplicates, block duplicates, or replace is going to be header-dependent. I'm also in agreement with Josh that if you're trying to add headers that would potentially be overwritten by Asterisk (i.e. non X-<blah> headers) then it's probably not a good idea, and that sort of thing is best left undefined. |
| 22:03.32 | putnopvut | The thing is, because load-order factors into things, and sometimes header order is important, allowing duplicates can lead to "fun" scenarios where system A has one behavior and system B has a different one because of their different load orders. |
| 22:03.45 | gtjoseph | yeah. exactly |
| 22:04.02 | gtjoseph | ok, i'm not touching PJSIP_HEADER. |
| 22:04.40 | gtjoseph | if you really need more fine grained control, register a supplement and deal with it yourself. |
| 22:06.26 | gtjoseph | hmmm. i wonder if I should change PJSIP_HEADER's registration order so always registers before the others? |
| 22:08.24 | gtjoseph | but that would probably piss people off if I did it in 13. :) |
| 22:10.46 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 22:24.56 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 22:24.56 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |