| 02:26.05 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip184-182-52-160.ph.ph.cox.net) |
| 02:57.07 | *** join/#asterisk-dev leifmadsen (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 02:57.07 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 02:58.59 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 02:58.59 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 03:00.37 | *** join/#asterisk-dev opticron (~opticron@75.76.59.35) |
| 03:00.37 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 03:05.00 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:828e:5c97:d1a3:efac:e76a) |
| 03:05.00 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 03:56.53 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 04:01.40 | coreyfarrell | gtjoseph: you still awake? |
| 04:02.10 | cresl1n | don't bug him, it's too late :-P |
| 04:02.21 | coreyfarrell | ah hey cresl1n |
| 04:02.45 | cresl1n | hey! |
| 04:02.47 | cresl1n | j/k btw |
| 04:02.53 | cresl1n | not sure if he's up or not |
| 04:02.55 | coreyfarrell | it's cool :) |
| 04:03.04 | gtjoseph | I am. what's up? |
| 04:03.23 | coreyfarrell | I just reverted https://gerrit.asterisk.org/7124 on my own machine and tests/channels/pjsip/resolver/srv/failover/in_dialog/transport_tcp passed. |
| 04:04.21 | gtjoseph | eh? not sure what would have affected that |
| 04:04.44 | gtjoseph | the pjsip tests all passed earlier today |
| 04:05.20 | coreyfarrell | do you have unbound-devel on all the test machines? |
| 04:05.31 | gtjoseph | yep |
| 04:05.57 | gtjoseph | when did it start failing? |
| 04:06.28 | coreyfarrell | odd. that tests and the transport_unspecified have been failing every time on 15 and master since the security release. |
| 04:07.28 | gtjoseph | hmmm did you try reverting the res_pjsip_session patch as well? |
| 04:07.55 | coreyfarrell | yeah that didn't fix it, so I reset to master and reverted the pjproject patch. rebuilt and the tests worked. |
| 04:08.45 | coreyfarrell | on 15 https://jenkins2.asterisk.org/job/gate-ast-15-pjsip/39/ appears to be the last success, run #40 failed. |
| 04:09.13 | gtjoseph | ok. I can take a look in the morning. unless there are invalid values in the sipp XML that patch should do nothing |
| 04:09.58 | coreyfarrell | it's weird we're getting a 481 leg not found when sipp tries to BYE the call. |
| 04:10.00 | gtjoseph | and if there are,. there should be errors in the log |
| 04:10.38 | coreyfarrell | before you go, what's the easiest way to force bundled pjproject to rebuild? |
| 04:10.39 | gtjoseph | which means it went away before it should have |
| 04:11.17 | gtjoseph | touch one of the makeopts files |
| 04:11.25 | gtjoseph | I forget wjich |
| 04:11.35 | coreyfarrell | probably menuselect.makeopts |
| 04:12.48 | gtjoseph | you'd have to look in third-party\pjproject\makefile |
| 04:17.09 | coreyfarrell | oh well I just went into third-party/pjproject and ran make clean :) |
| 06:15.20 | *** join/#asterisk-dev tm1000_ (sid6728@gateway/web/irccloud.com/x-iktmcfhiejixnkfk) |
| 06:18.35 | *** join/#asterisk-dev Gugge_ (gugge@92.246.2.105) |
| 07:42.16 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:42.16 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:51.26 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:51.26 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:56.40 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:1dd7:b42:3b85:c2f5) |
| 07:57.55 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:27.43 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:44.29 | *** join/#asterisk-dev startups (~startups@cpe-76-175-177-156.socal.res.rr.com) |
| 12:52.37 | *** join/#asterisk-dev joshelson (~joshelson@206.81.147.110) |
| 13:28.35 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 13:36.22 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 13:55.26 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-sccnszjdkbzhrksi) |
| 13:55.26 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:59.28 | *** join/#asterisk-dev gedia (~gd@185.73.41.1) |
| 14:00.45 | gedia | hello all! I've been looking at https://github.com/asterisk/asterisk/commit/673fa4431e2c5d056ba0d76d05748af10fdbd5f9, but even with this patch applied, "To" Header body is truncated at 256 characters with asterisk 11.25.3 after "to" tag is appended by UAS (exceeding initial 256 length). is this intended? |
| 15:00.32 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:00.32 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:01.13 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:01.13 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:14.39 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-rpxyublryegcidce) |
| 15:14.39 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 15:19.03 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-iursycjgxjkrbkjt) |
| 15:19.03 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:35.02 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 15:48.26 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 16:00.34 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-eoeldnidxgwyollp) |
| 16:00.34 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:26.56 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 16:44.51 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 17:04.24 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 17:15.02 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 17:20.17 | coreyfarrell | gedia: that commit fixed a specific instance of header values being truncated, other similar issues probably exist. Asterisk 11 is unsupported, if you are able to reproduce the issue in Asterisk 13 please file a bug with JIRA with the info needed to triage. |
| 17:20.29 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-nfoumaljmcxheklo) |
| 17:20.30 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:23.10 | coreyfarrell | gedia: chan_sip is community support and even those of us who still use it often prefer to just leave it alone.. but header truncation is a simple enough issue with a low risk fix so I'd be willing to make a fix for it. |
| 17:25.00 | coreyfarrell | gedia: if you haven't tried chan_pjsip it's worth trying. at minimum you want to identify and report any issues that prevent you from using chan_pjsip in production. |
| 17:25.38 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 17:28.13 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip184-182-52-160.ph.ph.cox.net) |
| 17:29.23 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-odjyjywjtnmctvba) |
| 17:29.23 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:30.33 | gtjoseph | coreyfarrell: was it more than just tests/channels/pjsip/resolver/srv/failover/in_dialog/transport_tcp that was failing? |
| 17:30.53 | coreyfarrell | gtjoseph: yes also transport_unspecified in the same folder. |
| 17:31.16 | gtjoseph | the entire team has been scratching its collective heads for the past hour and a half trying to understand why |
| 17:31.19 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 17:31.21 | coreyfarrell | those are the two that are (were?) failing every time. |
| 17:31.25 | gtjoseph | rmudgett: ^^ |
| 17:32.28 | coreyfarrell | have you been able to reproduce my finding that the test fails with the latest pjproject patch but passes without it? |
| 17:32.55 | gtjoseph | oh yes |
| 17:32.59 | gtjoseph | we can reproduce it |
| 17:33.29 | gtjoseph | we've been on a conf call trying various things to figure out why |
| 17:33.37 | gtjoseph | but have come up empty |
| 17:33.53 | coreyfarrell | gtjoseph: in the asterisk logs I looked at one interesting thing is that the asterisk logs show the 503 response with the patch, but did not show it without the patch. |
| 17:34.04 | gtjoseph | yes |
| 17:34.28 | gtjoseph | and if the 503 part of the test is commented out, it passes |
| 17:36.00 | gedia | âcoreyfarrellâ: thanks for the reply. unfortunately migrating to pjsip is a huge undertaking for the time being, we need to migrate and validate our entire application written in PGPAGI on this stack. Anyway, I tried changing #define SIPHEADER 256 to #define SIPHEADER 512 but "To" is still truncated, maybe because the length is only exceeded after the UAS appends its tag (original to without tag is less than 255) |
| 17:36.45 | coreyfarrell | gtjoseph: one thought I had was that maybe your parsing error checks changed some header from optional to required.. one of the sipp scenarios sent requests without 'content-length: 0', but adding it had no effect. |
| 17:37.05 | gtjoseph | nope, there are no more or less parser issues |
| 17:37.15 | gtjoseph | everything's still valid |
| 17:37.31 | gtjoseph | AND... the udp version of the test passes :) |
| 17:37.46 | gtjoseph | we're thinking it may be timing and tcp connection related |
| 17:38.38 | gtjoseph | when it passes, sipp sends the 503 and just ends without waiting for an ACK to come back and in fact, asterisk never sends the ACK. |
| 17:39.03 | gtjoseph | when it fails, sipp sends the 503 and asterisk DOES send an ACK (like it should) |
| 17:39.40 | gtjoseph | BUT asterisk is still processing that failure on 1 thread while it's processing the new INVITEW on another thread |
| 17:39.45 | coreyfarrell | gedia: that's chan_sip. likely lots of places where it uses definitions like 'char from[256];' instead of using define's. I can't help you troubleshoot this here. the only way to make progress would be to open a ticket on JIRA and attach logs/configs. if you want write the ticket number to me here so I notice it. |
| 17:41.14 | coreyfarrell | gtjoseph: can your pjproject patch be broken into chunks? maybe that would help focus what needs to be looked at? |
| 17:41.26 | gtjoseph | nope, not possible |
| 17:41.49 | gtjoseph | well, i should say... not and continue to work |
| 17:46.46 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 17:48.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d009dd1294ab7e1b7e1.ipv6.abo.wanadoo.fr) |
| 17:57.29 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 18:01.08 | coreyfarrell | gtjoseph: the problem is in pjsip/src/pjsip/sip_parser.c (in case you haven't realized this already). I just reverted all changes to only that file except the added inlucde pj/limits.h - test worked. |
| 18:01.35 | gtjoseph | yeah but that's THE change :) |
| 18:04.49 | gtjoseph | coreyfarrell: https://issues.asterisk.org/jira/browse/ASTERISK-27408 |
| 18:04.54 | gtjoseph | i made you the reporter |
| 18:05.53 | gtjoseph | i also have a review up to disable those 2 tests until we figure out what's going on. |
| 18:10.49 | coreyfarrell | gtjoseph: can you remove the changes to pjsip_find_msg and verify that the tests work again? |
| 18:10.51 | rmudgett | I should probably just shove that patch in to make other patches go in |
| 18:11.33 | coreyfarrell | rmudgett: if you're talking about disabling the 2 tests I agree. |
| 18:12.40 | gtjoseph | @coreyfarrell: what changes exactly? |
| 18:12.44 | file | falls over |
| 18:13.02 | coreyfarrell | all changes to pjsip_find_msg in pjsip/src/pjsip/sip_parser.c |
| 18:17.59 | coreyfarrell | gtjoseph: I've attached the patch with my change to JIRA. |
| 18:18.09 | gtjoseph | i'm looking |
| 18:18.29 | coreyfarrell | I just deleted the chunks from that one function. |
| 18:29.10 | gtjoseph | ok i tpasses |
| 18:32.34 | coreyfarrell | gtjoseph: great. this stuff is way beyond my knowledge of pjproject but hopefully I've narrowed it down enough for you to add extra debugging or whatever needed to determine why the pjsip_find_msg change caused the failures. |
| 18:32.47 | gtjoseph | gee thanks |
| 18:32.56 | gtjoseph | that's coded that was added by Teluu :) |
| 18:43.30 | rmudgett | gtjoseph: The 503 response doesn't have a content-length header. |
| 18:43.41 | gtjoseph | i know but it doesn't help putting it in |
| 18:43.45 | gtjoseph | just tried it |
| 18:47.36 | coreyfarrell | I tried that last night as well because I saw something in one of the functions processing content-length with one of the new functions. |
| 18:48.02 | rmudgett | It is a required header for TCP though. |
| 18:51.53 | coreyfarrell | :( seems like an unnecessary deviation between TCP and UDP specs |
| 18:53.44 | rmudgett | It's optional for UDP because the datagram can define the content lenght |
| 18:55.49 | coreyfarrell | rmudgett: ah, I had misunderstood / assumed that content-length was always required if non-zero, but 'Content-Length: 0\n' would be implied. |
| 18:59.58 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-pmdsqrqdfbvviwfm) |
| 18:59.58 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:00.18 | rmudgett | It is best if it is there for UDP in case there is any trailing padding in the datagram |
| 19:09.22 | rmudgett | I do see a difference in behavior of the function with and without the patch. If we didn't find the content-length header we used to return PJSIP_EMISSINGHDR. Now we return PJ_SUCCESS |
| 19:11.58 | rmudgett | gtjoseph: ^^ |
| 19:12.14 | gtjoseph | yeah just saw that |
| 19:15.01 | rmudgett | Can easily be fixed by initializing status with PJSIP_EMISSINGHDR |
| 19:22.15 | rmudgett | The hdr_end, body_start, and line local variables should have volatile added to them. |
| 19:38.58 | rmudgett | gtjoseph: The difference in return value with/without the patch makes some sense when the invalid packet is received and the sipp scenario waits for the ACK. Looking at the sip_transport.c call to pjsip_find_msg(), when we get the error code back we will wait for more TCP data to arrive to complete processing the 503. |
| 19:39.10 | gtjoseph | is busy |
| 19:39.40 | seanbright | rmudgett: why whould those variables be volatile? |
| 19:40.39 | rmudgett | Because they could get put into registers. Register variables don't survive a longjmp back to the context. |
| 19:41.13 | seanbright | is that hidden in the PJ_TRY/PJ_CATCH_ANY stuff? |
| 19:41.43 | rmudgett | setjmp/longjmp is how pjproject implements TRY/CATCH |
| 19:41.50 | seanbright | gotcha |
| 20:03.38 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-170.barak.net.il) |
| 20:03.38 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:12.14 | gtjoseph | so the big question is why after putting in the Content-Length header does it still fail |
| 20:12.22 | gtjoseph | but i need lunch first |
| 20:30.12 | rmudgett | I think it passed before because pjsip_find_msg returned an error from the 503 msg because the content-length header wasn't there. I bet if you add the content-length header and didn't have the security patch installed it would fail. |
| 20:47.05 | *** join/#asterisk-dev joshelson (~joshelson@64.55.128.243) |
| 21:09.48 | rmudgett | coreyfarrell: You forgot to remove the duplicates in your commit message. :) https://gerrit.asterisk.org/#/c/7166/ |
| 21:13.57 | coreyfarrell | rmudgett: not sure what you mean? |
| 21:14.15 | rmudgett | s/will will/will |
| 21:15.23 | coreyfarrell | ah thanks.. I hate when I'm looking for something wrong and my brain auto-corrects it. |
| 21:19.54 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-apzijbbcotnilivg) |
| 21:19.54 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 21:50.40 | *** join/#asterisk-dev bford_ (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 21:50.40 | *** mode/#asterisk-dev [+o bford_] by ChanServ |
| 22:19.48 | seanbright | coreyfarrell: will your CLI improvements be backported to 13 & 15? |
| 22:21.36 | coreyfarrell | seanbright: my hope is that the current series can be cherry-picked. |
| 22:22.24 | seanbright | good deal |
| 22:24.15 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-fbnggdnciyiwjmdg) |
| 22:24.15 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:25.34 | coreyfarrell | seanbright: I split the original patch into stages and it now does the absolute minimum for this feature to work. I have more changes to submit in follow-up (stuff cut from my original single large patch). |
| 22:36.48 | kharwell | file: why did you -1 yourself on https://gerrit.asterisk.org/#/c/7012/ |
| 22:37.04 | file | broke tests |
| 22:37.08 | file | later fixed tests |
| 22:37.32 | kharwell | meaning the tests are now fixed or still need to be fixed? |
| 22:37.41 | file | there is a review up to fix them |
| 22:37.56 | file | once that test is merged then they can be regated |
| 22:38.13 | kharwell | alrighty |
| 22:41.08 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |
| 22:45.49 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 22:45.49 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:47.23 | coreyfarrell | seanbright: just curious when you tested that pjsip CLI completion and it took 10 minutes was that with asterisk -c or asterisk -r? |
| 23:05.45 | *** join/#asterisk-dev zopsi (~zopsi@dir.ac) |