| 00:30.45 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-86-98.dhcp.nwtn.ct.charter.com) |
| 00:30.45 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 00:36.28 | coreyfarrell | kharwell: thanks for dealing with the CHANGES! just didn't make the cut for me today. |
| 00:38.07 | kharwell | np I was looking for some low hanging review fruit to keep me busy here for a few minutes before heading out |
| 00:49.04 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-247.barak.net.il) |
| 00:49.04 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 00:50.00 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-kgitlalgvzdihuzl) |
| 01:20.14 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:20.14 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 03:30.22 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:50d5:1c20:aadf:ff72) |
| 03:30.22 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 04:50.45 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:d20:6cd5:39bd:da14) |
| 04:50.45 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 05:49.34 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.170) |
| 07:09.23 | *** join/#asterisk-dev elcontrastador (~textual@206.78.110.4) |
| 07:17.24 | elcontrastador | I looked at the res_rtp_multicast.c module code for Asterisk 15.1.5 to find and potentially increase the multicast TTL. I've done extensive network troubleshooting and have proven that mcast IS working from source to endpoints. I believe that RTPmulticast TTL is set too low... Can anyone help me check where to check and change the TTL in this file? I think I found it at line 107. Is this where I modify this, from the current value of 4 |
| 07:17.25 | elcontrastador | <PROTECTED> |
| 07:49.33 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:49.33 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 08:15.56 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 09:49.30 | elcontrastador | Greetings. Anyone have any suggestions on my post regarding checking/changing the multicast TTL on res_rtp_multicast? |
| 09:49.42 | elcontrastador | I'm actually in a bit of an emergency |
| 11:13.27 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:15.28 | elcontrastador | If anyone can point me the PROPER way to change the multicast timeout on the res_rtp_multicast module it'd be much appreciate. I have schools starting in a few hours and have been up thru the night. It's apparently set at a TTL of ZERO. Madness if not configurable! |
| 12:27.14 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 12:27.14 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:29.13 | *** join/#asterisk-dev opticron (~opticron@75.76.59.35) |
| 12:29.13 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 12:32.34 | *** join/#asterisk-dev Tim_Toady (~fuzzy@snf-33276.vm.okeanos.grnet.gr) |
| 12:38.52 | *** join/#asterisk-dev skrusty (~skrusty@88.150.145.104) |
| 12:38.52 | *** mode/#asterisk-dev [+o skrusty] by ChanServ |
| 13:07.50 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.173) |
| 13:35.42 | *** join/#asterisk-dev elcontrastador (~textual@206.78.110.4) |
| 13:59.45 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-ccakuzcjkutsvrdy) |
| 13:59.45 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:08.16 | *** join/#asterisk-dev skirmisha (~skirmisha@213.16.62.70) |
| 14:08.20 | skirmisha | hi guys |
| 14:08.35 | skirmisha | can you help me with your comments on the following scenario |
| 14:09.04 | skirmisha | already asked in the other channel, but just in case |
| 14:09.06 | skirmisha | i have strange issue, not sure where the issue is...i have normal call coming to ast server...it is routed to fax machine |
| 14:09.14 | skirmisha | fax machine answers with t38 back on the invite |
| 14:09.23 | skirmisha | the origination party reject the t38 with 488 not acceptable and send g711 re-invite offer...second offer is accepted by the fax machine...however there is no fax tone heard |
| 14:10.41 | skirmisha | if fax machine answer with g711 i hear a fax tone |
| 14:10.54 | skirmisha | what could be the reason channel to not pass fax tone |
| 14:18.06 | skirmisha | any comments |
| 14:35.20 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 14:40.41 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 15:10.21 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 15:15.22 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-uwllfrakefifsixy) |
| 15:15.22 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:22.46 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-pakekmbtvjkxrrvk) |
| 15:22.46 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 15:28.17 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:28.17 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:41.55 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-fbsfaawnlwnvikwd) |
| 15:41.55 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 16:09.10 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 17:28.17 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-gugoouaedzzexdaa) |
| 17:28.17 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 19:02.54 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 19:02.54 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:25.10 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-nphihcrzfrkrdwky) |
| 19:25.10 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 20:48.28 | seanbright | so it is very possible that i don't understand something, but i am looking at res_rtp_asterisk.c in 15 |
| 20:48.56 | seanbright | there is a call to SSL_do_handshake(dtls->ssl) in dtls_perform_handshake() |
| 20:49.28 | seanbright | there is a call to SSL_do_handshake(dtls->ssl) and SSL_do_handshake(rtp->rtcp->dtls.ssl) in dtls_srtp_renegotiate() |
| 20:50.03 | seanbright | nevermind, i see it now |
| 20:50.05 | seanbright | kthx |
| 21:26.38 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 21:26.38 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 21:50.31 | *** join/#asterisk-dev leedm777 (~textual@2607:fb90:982:7698:f9d8:d8be:9aa8:cdea) |
| 21:50.31 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 22:08.46 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 22:08.46 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:34.32 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 22:34.32 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 22:49.32 | kharwell | so I guess chan_sip has never cleaned itself up on shutdown with regards to outbound registrations or did something break? |
| 22:49.49 | file | it never has |
| 22:50.32 | kharwell | heh so then is this issue really a "new feature" :-D https://issues.asterisk.org/jira/browse/ASTERISK-27601 |
| 23:15.29 | coreyfarrell | kharwell: I agree it would be a new feature.. also if you do 'core stop now' or `killall asterisk` as most init scripts would then chan_sip unload never happens. |
| 23:16.45 | coreyfarrell | chan_pjsip would be the same way unless the outbound registration module uses ast_register_atexit to deal with non-graceful shutdown. |
| 23:19.12 | kharwell | I do not see an "atexit" in res_pjsip_outbound_registrations so doesn't look like it would handle that case either. I'd expect though if you shut your system down that way then a lot of things won't get "cleaned up" or even should |
| 23:20.56 | coreyfarrell | kharwell: two sides to cleaning up an outbound registration. releasing memory, and sending a SIP packet to the remote system so it immediately expires the registration. |
| 23:21.52 | coreyfarrell | but not telling the remote side to expire the registration can be a feaature too. if the remote system gets a call for you while you are restarting asterisk they will still try sending an INVITE. |
| 23:23.09 | coreyfarrell | the INVITE would timeout but they'd send it again (once the service restart completes) and at most the caller would experience a small delay. if the remote registration expires they would reject the inbound call immediately so the caller would probably get congestion. |
| 23:25.36 | kharwell | that makes sense. Guess there is no way to tell in asterisk is someone is doing a "core restart" vs manually shutting down and then maybe eventually restarting asterisk |
| 23:28.42 | coreyfarrell | we could make it possible to know which CLI command is run, but that wouldn't help when init scripts / systemd uses a KILL signal for service stop and restart |
| 23:30.20 | kharwell | ya prob one's best bet if the functionality (send unregisters on restart/shutdown vs not) was so desired is to create yet another option :-) |
| 23:31.50 | coreyfarrell | agreed |
| 23:32.16 | kharwell | I had opened this issue as a bug, but if you or someone else feels strongly that it's a feature I'd be fine if you want to comment as such and close it out unless they supply a patch. |
| 23:32.36 | coreyfarrell | that said 1&1 should be realizing "our outbound INVITE timed out so we need to try the next server". |
| 23:33.27 | kharwell | yup and I also thought that that's what qualifies were good for |
| 23:35.11 | coreyfarrell | absolutely nothing we can do to deal with situations where the server or network connectivity just fails unexpectedly.. I suspect that 1&1 is deflecting blame. even without qualifies they should detect the system as unavailable when they get no response to the INVITE. |
| 23:36.53 | kharwell | agreed |