| 01:00.21 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 01:40.00 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 03:40.36 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 05:35.35 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 05:54.48 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:14.33 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 06:22.30 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 06:22.31 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:31.57 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:39.20 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 07:46.54 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.121) |
| 08:16.48 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 08:18.03 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:23.20 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 08:27.15 | *** join/#asterisk-dev stevedav_ (~stevedavi@197.155.252.3) |
| 08:28.29 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 09:54.58 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 10:04.15 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 12:18.29 | *** join/#asterisk-dev Corydon76 (~quassel@zett.abyt.es) |
| 12:18.29 | *** mode/#asterisk-dev [+o Corydon76] by ChanServ |
| 12:44.39 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 12:55.01 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 12:56.51 | *** join/#asterisk-dev stevedav_ (~stevedavi@197.155.252.3) |
| 13:06.03 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 13:12.07 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 13:17.33 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.37.241) |
| 13:42.34 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:42.34 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:51.10 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@185.122.102.105) |
| 13:57.08 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.121) |
| 14:12.59 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dintkcxseeiaxvwh) |
| 14:12.59 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:20.43 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.39.211) |
| 14:31.40 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-uymykkugedqvojtz) |
| 14:31.40 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:49.23 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 15:10.03 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 15:12.09 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 15:15.45 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 15:21.04 | *** join/#asterisk-dev matjethetree (4e033f76@gateway/web/freenode/ip.78.3.63.118) |
| 15:41.38 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 15:41.38 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 15:59.53 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 15:59.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 16:03.46 | coreyfarrell | bford: I'm a bit confused by the commit message in https://gerrit.asterisk.org/10941 |
| 16:04.47 | bford | coreyfarrell: what's the cause of confusion? i can try to help clear it up! |
| 16:04.57 | coreyfarrell | are you suggesting that you want to support two sets of changes in one file? IE "Subject: res_pjsip\n\nmessage\nSubject: core\nanother message" |
| 16:05.33 | coreyfarrell | I had assume that multiple subject headers would be "Subject: res_pjsip\nSubject: core\n\nmessage for both sections". |
| 16:06.03 | coreyfarrell | so if you needed one message under res_pjsip and a different message under core you would just create two changes files in the same commit |
| 16:07.27 | bford | yeah, it probably would not be a common scenario, but if you were to make a change that impacted 2 separate modules, you have that freedom to incorporate it for both |
| 16:07.27 | bford | right now it breaks it down every time it sees a "Subject:" header, but it could be changed to allow multiple subjects in one section |
| 16:07.27 | bford | the only concern i would have for that is if you wanted to have a different message for each module |
| 16:07.27 | bford | but im flexible on this, still hashing it out |
| 16:08.07 | bford | but yeah, you can do it all in one file rather than needing another, to keep the change in the same relative spot |
| 16:09.49 | bford | then again, it could have the ability to have 2 subjects and you could still break it out into multiple sections if you wanted |
| 16:09.58 | bford | *for the same message |
| 16:10.02 | coreyfarrell | I haven't looked at the code but my concern with more headers after contents is that might create ambiguity in the parser. the intent of my idea about with multiple Subject headers was something like `Subject: res_pjsip\nSubject: chan_sip\n\nChange default RTCP timeout to X` |
| 16:11.57 | bford | it would definitely make it easier on the parser, because right now it goes through and sees "Subject:", looks for headers immediately following it, waits for a line with only a new line, then adds the contents unless it sees another "Subject:" - then it will add everything it read to the current subject and start again with the new "Subject:" header |
| 16:13.53 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:28.38 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 16:39.21 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 16:45.34 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:54.21 | *** join/#asterisk-dev sahmed (~sahmed@12.235.204.202) |
| 16:57.46 | sahmed | One thing to know, If endpoint's dtmf_mode=auto_info and caller's sdp has no 101, then if called party send dtmf as rtp event. Is it the expected way to transmit dtmf to caller in both INBAND and INFO mode? |
| 17:01.12 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-1-5196-243.w90-105.abo.wanadoo.fr) |
| 17:49.19 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-1-5196-243.w90-105.abo.wanadoo.fr) |
| 17:55.05 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 18:26.59 | coreyfarrell | kharwell: looks like something weird is happening with the release scripts re-tagging old fixes to 16.3.0. |
| 18:27.10 | gtjoseph | he's on it |
| 18:29.42 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 18:31.27 | *** join/#asterisk-dev stevedav_ (~stevedavi@197.155.252.3) |
| 18:59.20 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-1-5196-243.w90-105.abo.wanadoo.fr) |
| 19:03.12 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 19:15.26 | kharwell | coreyfarrell: unfortunately I made a typo in one of the update scripts and it updated too many issues |
| 20:13.15 | sahmed | Hello, Anybody experience this? If endpoint's dtmf_mode=auto_info and caller's sdp has no 101, then if called party send dtmf as rtp event. Asterisk transmit this dtmf to caller in both INBAND and INFO mode. |
| 20:13.48 | sahmed | Anybody have any idea on this? |
| 20:41.17 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 20:50.30 | cresl1n | wibbles |
| 21:39.29 | *** join/#asterisk-dev libardi (~libardi@201.53.215.24) |
| 23:21.45 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 23:22.07 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-dintkcxseeiaxvwh) |