| 00:00.07 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-xthztustpzyjgoje) |
| 00:31.36 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 00:36.42 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 01:08.45 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 01:13.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 02:55.06 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.92) |
| 06:05.57 | *** join/#asterisk-dev stevePearPear (~stevePear@202.166.82.92) |
| 06:31.52 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:31.53 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:42.13 | *** join/#asterisk-dev stevePearPear_ (~stevePear@202.166.82.164) |
| 06:43.28 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:11b3:646a:e7fc:964c) |
| 08:33.33 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:1413:8588:26a7:605a) |
| 08:53.35 | vassilux | hi is there a possibility to install hangup callback for a channel ? |
| 09:00.07 | wdoekes | hangup handlers, since asterisk 11, vassilux |
| 09:08.11 | *** join/#asterisk-dev paolo_ (~smuxi@ip-62-143-36-139.hsi01.unitymediagroup.de) |
| 09:11.35 | vassilux | cool, Is it in channel.h ? I can not find sorry. It's morning for me |
| 09:20.19 | wdoekes | https://www.google.nl/search?q=hangup+handlers+asterisk |
| 09:20.42 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 09:20.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:21.36 | wdoekes | note that it's a dialplan feature, you'll have to check how it's done internally if you want a handler in C |
| 09:23.12 | vassilux | wdoekes , I want to use internally , I saw something like this but don't remember where ... |
| 09:26.01 | wdoekes | if there is a generic way, you would hope that the hangup handlers take advantage of that |
| 09:26.11 | wdoekes | I suggest you start looking there |
| 09:26.11 | vassilux | <PROTECTED> |
| 10:07.44 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 10:30.41 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 11:02.01 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 11:02.01 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:09.20 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 11:09.22 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:16.19 | *** join/#asterisk-dev dms1 (~dms1@c-50-168-154-89.hsd1.sc.comcast.net) |
| 12:09.33 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:14.00 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 12:24.02 | *** join/#asterisk-dev leifmadsen (~free-mads@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:24.02 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:26.29 | hexanol | I have a trace on an asterisk 11.9.0 where a SIP phone (A) calls another SIP phone (B), and when B answers, asterisk start sending the RTP packets to A before sending a 200 OK (or a 183 Progress), i.e. it never sends an SDP to A |
| 12:26.41 | hexanol | (directmedia is not enabled) |
| 12:27.13 | hexanol | and then, the RTP is only forward partially (i.e. the media from B is sent to A but the media from A is not sent to B) |
| 12:28.43 | hexanol | and there's only one line "Probation passed - setting RTP source address to XXX" line for the call |
| 12:30.32 | hexanol | so, my question, does that ring a bell to someone ? |
| 12:52.38 | *** join/#asterisk-dev Dovid (~Dovid@static-173-63-105-210.nwrknj.fios.verizon.net) |
| 13:15.48 | file | hexanol, so it never sends an answer to the other side at all? |
| 13:17.42 | hexanol | file: right |
| 13:17.52 | hexanol | it only sends a 100 Trying, then a 180 Ringing |
| 13:18.02 | file | can't say I've heard of that happening |
| 13:18.10 | hexanol | and after that, he receives an ACK from the phone |
| 13:18.18 | hexanol | because asterisk did sent |
| 13:18.22 | hexanol | an RTP packet |
| 13:18.46 | hexanol | and I guess the phone (might be buggy), when he receives the first RTP packet, just respond with an ACK |
| 13:21.12 | hexanol | to me, it looks like A's channel was already in the AST_STATE_UP when the sip_answer function is called |
| 13:21.27 | hexanol | but then, I couldn't explain why the chan would be in this state |
| 13:21.31 | hexanol | and it might not even make any sense |
| 13:21.48 | file | it doesn't - you'll need to provide a complete console output with sip debug as well |
| 13:24.25 | hexanol | yeah unfortunately I don't have those yet |
| 13:27.26 | hexanol | i.e. I only have a network trace and the asterisk log, without sip debug activated |
| 13:50.46 | hexanol | hum, I just did an experiment, where I added a small CLI command to be able to set the state of any channel to AST_STATE_UP (http://pastebin.com/raw.php?i=hyLbFssK) |
| 13:51.08 | hexanol | and done a similar call scenario on my machine (on asterisk 11.11.0) |
| 13:51.27 | hexanol | and if I set the state of the caller channel to AST_STATE_UP |
| 13:51.38 | hexanol | just before the callee answer |
| 13:52.08 | hexanol | than I'm getting the same behaviour as what was observed in production |
| 13:52.20 | hexanol | i.e. no 200 OK sent to A |
| 13:52.25 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xinnyiyphwnenjxo) |
| 13:52.25 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:52.31 | file | yes, if you do that... that is exactly what will happen |
| 13:52.43 | file | chan_sip can't answer a call twice and it uses the channel state to determine it |
| 13:53.01 | hexanol | I guess then I should try to find out what is changing the channel state |
| 13:53.08 | hexanol | on the production machine |
| 13:53.27 | hexanol | any idea on what could set the state of a channel to up ? |
| 13:54.29 | hexanol | I think there's fax detection enabled on the call... could it be possible that... |
| 13:54.56 | hexanol | hum.. guess I don't know |
| 13:55.34 | file | until there's complete logs that we can see it's all just guessing |
| 13:56.23 | file | I'd also suggest once you do have it to ask in #asterisk instead - if it's actually a code problem then come here |
| 13:57.04 | hexanol | file: understood |
| 13:58.32 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-tcpasgiocranmfua) |
| 14:01.26 | file | I am unsurprised |
| 14:02.23 | file | giggles at self |
| 14:15.45 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 14:32.56 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-zgafrjpifkycraeu) |
| 14:43.30 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-dewwtkyfnnmsgblz) |
| 14:53.47 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-tcrfxjnosigrdfre) |
| 14:56.05 | mjordan | file: putnopvut: should we be putting in a UUID into a Contact header? e.g.: <sip:e42c37f8-78f4-4726-813d-906a3aba79f3@193.84.95.110:5060>? |
| 14:56.40 | mjordan | Looking at ASTERISK-24149, and right now, that's the only thing I can see that is substantially different between chan_sip/chan_pjsip |
| 14:58.26 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:03.48 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:03.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:14.35 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 15:27.06 | file | mjordan, that's pretty much a default user value - normally it will get overwritten, but we could change it something else |
| 15:27.13 | file | er to something else |
| 15:30.04 | mjordan | hm. |
| 15:30.11 | mjordan | I'm not sure it's actually the problem anyway |
| 15:30.42 | mjordan | It's about the only thing that's different between what chan_sip sends and what chan_pjsip sends. The fact that this only fails on port 5060 screams ALG, and I can see an ALG barfing on that |
| 15:32.19 | Marquis42 | leifmadsen: plz2b providing mjordan with our handy SIP troubleshooting flowchart. ;) |
| 15:33.24 | leifmadsen | mjordan: http://imgur.com/0CwIvYt |
| 15:34.11 | file | truth |
| 15:34.24 | file | some residential equipment you can't turn off the ALG |
| 15:34.25 | skrusty | lol :) |
| 15:34.45 | leifmadsen | the worst part, is I've provided that to our internal support/provisioning team, and it's worked |
| 15:35.52 | skrusty | there was a time that whenever you upgraded zyxel hardware, it turned alg back on |
| 15:35.58 | mjordan | no shit :-( |
| 15:36.00 | Marquis42 | ugh |
| 15:36.09 | mjordan | alas, I don't think this person realizes there's an ALG. |
| 15:36.16 | mjordan | So, we shall see what they come back with. |
| 15:36.26 | mjordan | I've never had a situation where an ALG made life better. |
| 15:36.43 | mjordan | It's impressive that there's an industry of churning out this god awful crap |
| 15:36.47 | skrusty | :D |
| 16:25.44 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-neauoxzwsltokdmw) |
| 16:49.41 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 17:45.44 | seanbright | it doesn't make sense |
| 17:46.06 | seanbright | i'm having a sip networking issue -> is alg on? -> no -> it works! |
| 17:46.22 | seanbright | that leaves me with an unresolved sip networking issue |
| 17:46.28 | seanbright | this flowchart is bogus |
| 17:52.21 | Marquis42 | lol |
| 17:52.27 | Marquis42 | It's perfect, you shut your mouth! |
| 18:18.09 | leifmadsen | seanbright: nope, you must have ALG on "somewhere" |
| 18:18.16 | leifmadsen | if it is off, everything works |
| 18:18.21 | leifmadsen | SIP is perfect, so shut your mouth |
| 18:28.44 | seanbright | leifmadsen: lol |
| 18:28.55 | seanbright | don't sass me |
| 18:31.34 | leifmadsen | oh I'll sass you |
| 18:32.14 | seanbright | touche |
| 18:32.38 | seanbright | é rather |
| 18:35.35 | leifmadsen | you fancy huh? |
| 18:48.10 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113961.dyn.optonline.net) |
| 19:24.50 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:24.51 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:54.05 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-255-171-52.mci.googlefiber.net) |
| 20:57.36 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:07.51 | skrusty | is it possible to dial a sip Uri using ARI? (like Dial with tr option) |
| 21:14.53 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 21:14.53 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 21:15.54 | file | hrmph |
| 21:19.41 | skrusty | evening |
| 21:21.59 | *** join/#asterisk-dev philipp64 (~chatzilla@66-232-81-197.ctcweb.net) |
| 21:27.17 | mjordan | skrusty: chan_sip or chan_pjsip? |
| 21:30.55 | skrusty | chan_sip |
| 21:33.08 | mjordan | skrusty: should. You have to specify which endpoint you want, but after that it's pretty much just a dial string that gets interpreted by the channel driver |
| 21:33.34 | file | chan_sip doesn't believe in URIs so you have to work within what it provides |
| 21:34.14 | mjordan | right, but specifying endpoint:SIP/(YOUR CHAN SIP DIAL STRING) *should* work |
| 21:34.22 | skrusty | and pjsip? |
| 21:34.37 | mjordan | it will definitely work, because it is not weird and strange. |
| 21:34.48 | skrusty | haha |
| 21:34.57 | mjordan | although dialing an arbitrary URI requires specifying which endpoint you want to dial it through |
| 21:35.07 | mjordan | (IIRC) |
| 21:35.10 | file | correct |
| 21:46.24 | skrusty | thanks |
| 22:07.37 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 23:23.41 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 23:44.28 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-tcpasgiocranmfua) |