| 00:30.48 | Juggie | on another interesting note, i heard a few days ago about multiple registrations per the same sip username |
| 00:31.02 | Juggie | this just seems like nonsense to me. |
| 00:32.39 | snuff-work | tis true.. which reminds me.. need to put out 1st draft of basic xml doc for res_sip |
| 01:19.20 | *** join/#asterisk-dev serafie (~erin@24.214.158.242) |
| 02:52.08 | *** join/#asterisk-dev serafie1 (~erin@24.214.158.242) |
| 04:00.50 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 04:19.31 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 04:40.48 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 05:55.44 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 05:55.44 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 06:32.28 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 06:40.23 | *** join/#asterisk-dev bulkorok (~chatzilla@85.183.36.36) |
| 06:45.59 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 08:21.24 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 08:36.45 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:7cb8:2a90:152b:bef3) |
| 10:14.31 | *** join/#asterisk-dev Greenlight (~email@cpc1-dund9-0-0-cust142.16-4.cable.virginmedia.com) |
| 11:35.14 | *** join/#asterisk-dev italorossi (~italoross@187.60.66.11) |
| 12:55.28 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-kdjofygdsngklnhg) |
| 12:58.28 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 12:58.28 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:08.07 | *** join/#asterisk-dev w9sh (~sph@50-79-224-193-static.hfc.comcastbusiness.net) |
| 13:16.07 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 13:16.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:17.09 | oej | Afternoon sirs. |
| 13:17.28 | file | moo |
| 13:18.10 | oej | Do we have a unique ID for an Asterisk instance somewhere? I remember something in dundi. |
| 13:18.30 | oej | And where is the work with the UUID? |
| 13:19.13 | file | you can configure Asterisk instances with a system name, I don't think there's anything auto generated persistently, and it's in trunk - include/asterisk/uuid.h |
| 13:20.32 | oej | ok, will need to backport taht (ugh) and use as sip.instance. Create something in astdb and use that. |
| 13:20.51 | opticron | there's an EID based on the MAC |
| 13:21.10 | opticron | primarily used in the event system |
| 13:21.32 | opticron | used to identify servers communicating distributed device state |
| 13:21.45 | opticron | oej, utils.h |
| 13:25.14 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-bqppefxqlyuzaxhi) |
| 13:25.14 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:25.49 | oej | opticron: Is it saved anywhere, like in astdb? |
| 13:28.13 | file | no, it's derived at startup time but can also be optionally explicitly set |
| 13:28.16 | oej | I need to implement something like SIP outbound fo rUDP |
| 13:28.40 | oej | The instance ID needs to be persistent across space and time. So ASTdb |
| 13:31.39 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:31.39 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:25.51 | mjordan | leedm777: I'm glad to see the test suite properly freaked out on the DTMF changes :-) |
| 14:27.12 | leedm777 | mjordan: I guess those tests will need to be updated. |
| 14:27.32 | mjordan | yup, I'm on it. Always nice to see that tests actually catch things when they change :-) |
| 14:38.23 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:38.23 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:41.11 | mjordan | drat. We're going to need to add the ability for a pluggable module to only be added if an Asterisk Version is of a particular value. |
| 14:42.46 | Qwell | que? |
| 14:44.51 | oej | mjordan: Don't forget my code with DTMF continue :-) |
| 14:45.40 | oej | Just to make life a bit more complex. |
| 14:49.34 | oej | DTMF is far too complex for it's own good. |
| 14:49.46 | mjordan | oej: yup, just responded to the e-mail. Luckily, this is all just feeding off of whatever Stasis-Core gives it, so if Stasis-Core gave it DTMF continue, it'd b |
| 14:49.53 | mjordan | be good with that too :-) |
| 14:50.02 | mjordan | and yes, DTMF is too complex for its own good |
| 14:51.10 | mjordan | Qwell: there are some pluggable modules in the Asterisk TestSuite that check for certain things, like if an AMI event fired. When that AMI event no longer applies in later versions, we want to only check for it if the version of Asterisk is 11 or less. Correspondingly, there will be events we want to check for in 12+ |
| 14:51.13 | oej | So I will need help with the trunk version and stasis stuff later |
| 14:51.17 | Qwell | oh, testsuite |
| 14:51.25 | oej | Don't remember if I ported that patch to trunk yet. |
| 14:51.26 | mjordan | oej: sure! We're writing documentation on it right now |
| 14:51.33 | Qwell | mjordan: I was thinking you meant Asterisk modules. I was confused. |
| 14:51.46 | mjordan | I wasn't specific :-) |
| 15:01.26 | oej | Matt. Please be nicer to qwell. Forcing him to do DTMF over SIP Info is not a nice thing to do. |
| 15:02.51 | oej | Not for any one... |
| 15:18.34 | Qwell | oej: it has to be there, for WebRTC. :( |
| 15:19.04 | oej | Oh no, no no no no no no no no no no no |
| 15:19.14 | oej | Then we need telex over SIP info too. |
| 15:19.15 | Qwell | snickers |
| 15:19.22 | Qwell | don't forget FAX |
| 15:19.49 | oej | Maybe Matt made the right decision to punish you with SIP Info. I should not have doubted his decision again. My apologies mjordan |
| 15:19.57 | Qwell | :D |
| 15:22.17 | mjordan | at least I didn't give Qwell fax support for chan_gulp |
| 15:22.39 | oej | Not yet... |
| 15:22.51 | oej | he he |
| 15:26.29 | leifmadsen | MOAR FAXEN! |
| 15:44.57 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:56.04 | oej | compiling asterisk for a very small cpu. |
| 15:56.45 | oej | Always interesting |
| 16:07.38 | mjordan | eek |
| 16:07.41 | mjordan | LOW_MEMORY? |
| 16:10.25 | oej | yep, you bet. |
| 16:10.46 | oej | OpenWRT for MIPS |
| 16:10.58 | oej | Asterisk channel made for broadcom chipsets |
| 16:13.03 | mjordan | what version of Asterisk? |
| 16:15.11 | oej | 1.8 something |
| 16:15.30 | oej | Will implement the plc and that code on this little box |
| 16:15.59 | mjordan | as a head's up, you may run into ASTERISK-19612 |
| 16:15.59 | LieutPants | [ASTERISK-19612] [Status: Open] Asterisk crash with compiler flag LOW_MEMORY - https://issues.asterisk.org/jira/browse/ASTERISK-19612 |
| 16:16.46 | oej | Btw, matt. Can you please mail me the issues related to Mysql. I found a mysql dev that wants to look into it. Thanks. |
| 16:18.07 | mjordan | oej: sure thing. And that'd be great :-) |
| 16:18.38 | oej | Thanks for the heads up. |
| 16:18.50 | oej | But that's ASterisk 10 |
| 16:19.16 | *** join/#asterisk-dev ZX81 (~ZX81@184.90.88.69) |
| 16:19.45 | oej | I guess the difference between 8 and 10 is small here. |
| 16:20.11 | mjordan | yeah |
| 16:20.28 | ZX81 | hiya, I've noticed something strange with channel redirect - if I do a channel redirect from the dial plan it doesn't break the bridge - even though it gets a SUCCESS nothing happens till the a party hangs up. If I do it from the CLI it works as expected - anyone seen this? |
| 16:20.29 | mjordan | it was re-done to be more LOW_MEMORY friendly in 11, but it was kind of invasive |
| 16:20.32 | oej | Hmm. And I do have some insights into the RTP channel. |
| 16:20.35 | oej | Arrgggh. |
| 16:20.38 | ZX81 | 1.8 |
| 16:22.49 | ZX81 | http://pastebin.com/cTVTuMST |
| 16:56.48 | ZX81 | I want to compare the CLI version of channel redirect with app_channelredirect |
| 16:56.54 | ZX81 | where is the CLI version defined? |
| 16:58.40 | file | res/res_clioriginate.c |
| 17:04.45 | ZX81 | or ratherthanks |
| 17:04.48 | ZX81 | tanks |
| 17:04.50 | ZX81 | hmmm |
| 17:04.53 | ZX81 | keyboard hates me |
| 18:11.42 | *** join/#asterisk-dev ZX81 (~ZX81@184.90.88.69) |
| 18:27.10 | ZX81 | it's doing exactly the same thing... |
| 18:27.24 | ZX81 | I thought that maybe the problem was that status was set to success regardless (which it is) |
| 18:27.31 | ZX81 | but it is actually successful to |
| 18:27.39 | ZX81 | both do res = ast_async_parseable_goto(chan, dest); |
| 18:27.47 | ZX81 | when it happens from cli it works |
| 18:27.52 | ZX81 | when it happens from app it doesn't |
| 18:28.10 | ZX81 | I did a printout just in case |
| 18:28.10 | ZX81 | ast_log(LOG_WARNING, "Channel '%s' successfully redirected to %s\n", args.channel, args.label); |
| 18:28.14 | ZX81 | inside a !res |
| 18:28.27 | ZX81 | and it's identical from both calls |
| 18:28.42 | ZX81 | I thought it might have something to do with: |
| 18:28.47 | ZX81 | <PROTECTED> |
| 18:28.55 | ZX81 | but even removing that doesn't seem to help |
| 18:29.16 | ZX81 | both do: |
| 18:29.17 | ZX81 | <PROTECTED> |
| 18:29.18 | ZX81 | <PROTECTED> |
| 18:29.29 | ZX81 | I mean in the app it's |
| 18:29.30 | ZX81 | res = ast_async_parseable_goto(chan2, args.label); |
| 18:29.32 | ZX81 | <PROTECTED> |
| 18:29.34 | ZX81 | but it's the same thing |
| 18:31.21 | putnopvut | pulls out the code |
| 18:31.39 | mjordan | it is the same (although there's a good chance the CLI version should also be setting the HANGUP_DONT flag) |
| 18:32.01 | mjordan | most likely the channel isn't in the same state when it gets hit in the dialplan and when you issue the command from the CLI. What version of 1.8 are you running? |
| 18:32.27 | ZX81 | latest (svn as of today) |
| 18:32.35 | ZX81 | I'm running the same dial plan code |
| 18:32.50 | ZX81 | so instead of doing a feature code to trigger it |
| 18:32.54 | ZX81 | I'm doing CLI |
| 18:32.57 | ZX81 | and then it works |
| 18:33.15 | ZX81 | I mean it runs the dial plan code from the feature etc and returns success |
| 18:33.19 | ZX81 | just doesn't happen |
| 18:33.29 | putnopvut | Feature code...interesting. The bridge is actually already broken when feature codes are processed. |
| 18:33.39 | Qwell | feature code + goto == bad |
| 18:33.52 | Qwell | didn't read everything fully |
| 18:33.58 | ZX81 | ok |
| 18:34.15 | ZX81 | so I guess this no longer works: |
| 18:34.15 | putnopvut | What dialplan app are you using to do the redirect? |
| 18:34.16 | ZX81 | http://www.voip-info.org/wiki/view/Asterisk+n-way+call+HOWTO |
| 18:34.20 | ZX81 | channelredirect |
| 18:34.46 | ZX81 | is there a better way? |
| 18:35.10 | ZX81 | trying to redirect one channel of a bridge to a conf call for a sec while I get someone else on the line |
| 18:35.33 | mjordan | well, regardless of how insane that is, ChannelRedirect should still redirect the channel. |
| 18:35.35 | ZX81 | then adding myself and/or third party to it too |
| 18:38.59 | ZX81 | any other way to do it? |
| 18:39.38 | ZX81 | can I schedule ast_channel_unref(chan2); |
| 18:39.44 | ZX81 | to run later or something? |
| 18:39.57 | ZX81 | because when I end the chan it does happen |
| 18:40.03 | ZX81 | but just not till then |
| 18:40.17 | ZX81 | hmmm |
| 18:40.35 | ZX81 | maybe I could run an ago that connects via the cli and does a redirect lol |
| 18:40.38 | ZX81 | *agi |
| 18:43.16 | mjordan | so, no, you shouldn't be scheduling a channel unref. Without seeing a DEBUG log, it's pretty impossible to know for sure why the channel isn't be pulled out of its bridge. |
| 18:43.30 | ZX81 | ok |
| 18:43.59 | ZX81 | I'll need to rerun it after hours when the system is quieter for a full debug log |
| 18:44.09 | ZX81 | I'll add something to issues tonight |
| 18:44.26 | ZX81 | in the meantime I'll try doing something with AGI/manager |
| 18:44.32 | mjordan | although |
| 18:44.45 | mjordan | you'd have better chances with that. |
| 18:44.45 | ZX81 | yeah |
| 18:44.53 | mjordan | features.conf specifically says that dyanmic features are not supposed to perform dialplan manipulation |
| 18:45.23 | mjordan | including macro execution |
| 18:45.35 | mjordan | so very likely what this is attempting to do only worked in the past due to a fluke |
| 18:46.35 | mjordan | in fact, that was pointed out in the discussion on that voip-info page |
| 18:48.30 | ZX81 | by dial plan manipulation you mean dial plan usage? |
| 18:48.41 | ZX81 | I mean that code has no need to be a macro |
| 18:51.04 | ZX81 | ah |
| 18:51.05 | ZX81 | <PROTECTED> |
| 18:51.05 | ZX81 | ; concept of dialplan flow |
| 18:54.17 | mjordan | correct. Using GoSub, GoTo, Macro, etc. will have undefined behavior. |
| 18:54.49 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 18:54.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:54.59 | ZX81 | ok cool |
| 18:55.08 | ZX81 | will figure out another way to do it |
| 18:55.31 | ZX81 | What about local originates that do stuff like that |
| 18:55.33 | ZX81 | same thing? |
| 18:55.40 | ZX81 | hmmm |
| 18:55.41 | ZX81 | nah |
| 18:55.43 | ZX81 | never mind :-) |
| 19:52.30 | Qwell | putnopvut: Do you know how often the "short" version is used? I've literally never had to tell somebody to set dtmfmode=shortinfo |
| 19:54.22 | putnopvut | Qwell: nope, I have no idea on it. |
| 19:54.47 | putnopvut | According to the original issue that added it, the description said "some devices" without specifying which. |
| 19:55.00 | putnopvut | https://issues.asterisk.org/jira/browse/ASTERISK-10588 |
| 19:55.01 | LieutPants | [ASTERISK-10588] [Status: Closed] implementation of application/dtmf for SIP INFO - https://issues.asterisk.org/jira/browse/ASTERISK-10588 |
| 19:55.06 | Qwell | yeah, looking at that now |
| 20:01.50 | *** join/#asterisk-dev spditner (~simon@206-248-134-18.dsl.teksavvy.com) |
| 20:01.53 | spditner | Is there some issue with comedia / RFC 4145 in 11.3.0? I'm seeing all my calls running RTP in non-comedia mode, and I don't think it was behaving that way in 11.0... |
| 20:03.00 | Qwell | putnopvut: as for the nortel one, chan_sip would have never worked for that, since it doesn't follow the same format. |
| 20:03.08 | Qwell | http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/sip_tn/8_5_1/10-sip_transparency.html |
| 20:03.20 | Qwell | last section there shows an example packet |
| 20:03.45 | Qwell | I lied. |
| 20:03.50 | Qwell | It would totally work. |
| 20:21.55 | *** join/#asterisk-dev alecdavis (~alec@210.48.127.227) |
| 20:26.35 | spditner | Hmm, maybe I misunderstand what comedia means? I thought it meant that audio for both directions travel over the same RTP ip/port connection. Is that true? |
| 20:27.05 | alecdavis | @mjordan: re review 2452, regarding the question 'A comment with your rationale would be appropriate', did that mean in the code for furture readers, or for yourself as your not sure either? |
| 20:29.04 | putnopvut | spditner: well there aren't really "connections" with UDP. Comedia just means that the media should be going to the same port that Asterisk received media from. |
| 20:29.38 | putnopvut | So if Asterisk received audio from port 1234, but the SDP that set up SDP said to send audio to port 5678, Asterisk would send the audio to 1234. |
| 20:29.52 | putnopvut | s/SDP/INVITE/ |
| 20:30.49 | putnopvut | So if you have comedia enabled, and Asterisk is not sending media to the same port that it received it from, then it sounds like there could be an issue. |
| 21:48.55 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-bqppefxqlyuzaxhi) |
| 22:10.11 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 22:10.16 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 22:56.32 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 22:56.32 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 23:19.25 | spditner | I found that the NAT that this asterisk system is behind is shifting the rtp port numbers (non-randomly), would asterisk's STUN support pick up on something like that, and be able to traverse port restricted cone nat? |
| 23:21.34 | spditner | Oh ipv6 adoption, wherefore art thou? |
| 23:22.08 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:22.09 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 23:59.01 | *** join/#asterisk-dev ZX81 (~ZX81@172.220.217.215) |