| 00:18.30 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 00:45.17 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 00:45.17 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 01:25.57 | *** join/#asterisk-dev moy (n=moy@mail.e-contact.cl) |
| 01:54.22 | ricko73 | how long does it take for my License to get reviewed? |
| 01:54.55 | snuff-work | maybe 1-2 days tops |
| 01:55.09 | ricko73 | I submitted a patch to fix the music on hold selection in 'menuselect' for 1.4.26 to use the new opsound files |
| 01:57.30 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 01:57.30 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 02:01.55 | seanbright | if i see "Sending Set Asynchronous Balanced Mode Extended" |
| 02:02.00 | seanbright | constantly (like every second) |
| 02:02.04 | seanbright | what does that mean, exactly? |
| 02:02.41 | snuff-work | i'm going to assume your talking about a zap device |
| 02:02.53 | snuff-work | and i have no idea ;) |
| 02:03.14 | seanbright | yes indeed. |
| 02:04.20 | snuff-work | sangoma card? |
| 02:05.57 | seanbright | digium |
| 02:06.29 | snuff-work | mm.. not in wrong mode or anything.. like t1 vs e1? |
| 02:07.21 | snuff-work | also do you have the right data channel set? |
| 02:07.46 | seanbright | yeah |
| 02:09.34 | seanbright | correct mode and right data channel |
| 02:11.55 | snuff-work | mmm |
| 02:11.56 | seanbright | (i think i had my cables backwards... teehee) |
| 02:12.07 | snuff-work | that might not help :) |
| 02:32.18 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 02:32.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:24.30 | *** join/#asterisk-dev obnauticus (n=l@about/windows/regular/obnauticus) |
| 03:33.23 | *** join/#asterisk-dev infobot (i=ibot@rikers.org) |
| 03:33.23 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk |
| 05:20.49 | *** join/#asterisk-dev fiddur (n=fiddur@dhcp08.textalk.com) |
| 05:56.16 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 06:00.37 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 06:00.37 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:08.52 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 06:08.52 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 06:09.22 | tzafrir_laptop | seanbright, Set "Asynchronous Balanced Mode Extended" aka SABME |
| 06:09.44 | tzafrir_laptop | An ISDN layer 2 message. Basically asking: anybody on the other side? |
| 06:10.10 | tzafrir_laptop | If you get that, it is likely that layer 1 is down. e.g. the cable is disconnected |
| 06:57.43 | snuff-work | tzafrir_laptop: he said he might have had the cable the wrong way :) |
| 06:58.05 | snuff-work | and i'm assuming after he fixed that his issue disappeared |
| 07:16.57 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 08:37.19 | *** join/#asterisk-dev _ys (n=ys@xgw.infor.net.ru) |
| 10:52.23 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 10:52.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:56.19 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 10:56.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:14.22 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:14.22 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:20.53 | snuff-home | mornin kp |
| 11:22.38 | kpfleming | hello |
| 11:32.39 | *** join/#asterisk-dev _ys (n=ys@xgw.infor.net.ru) |
| 11:39.43 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 11:39.43 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:50.13 | oej | Afternoon folks |
| 11:51.32 | mvanbaak | mornin |
| 11:51.53 | kpfleming | evening |
| 11:53.21 | *** join/#asterisk-dev miguel3239 (n=elguero@ns1.nashuacs.com) |
| 11:56.20 | snuff-home | ello oej n mvanbaak |
| 12:07.57 | oej | ello |
| 12:09.22 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:09.22 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:09.34 | snuff-home | ello eliel |
| 12:09.51 | eliel | hello snuff-home |
| 12:12.11 | mvanbaak | so how are we doing today ? |
| 12:13.29 | snuff-home | wants netbackup to go in a corner n die |
| 12:15.11 | mvanbaak | real men dont make backups |
| 12:16.31 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:16.31 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:16.38 | snuff-home | heh big corps like their backups |
| 12:40.52 | leifmadsen | russellb: any ideas what is currently blocking for a 1.6.0.x and 1.6.1.x RC release? |
| 13:00.06 | *** join/#asterisk-dev oej (n=olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 13:00.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:01.44 | russellb | leifmadsen: I haven't been in the office in what feels like forever (last Friday), so I need to follow up on a number of things with people |
| 13:02.01 | leifmadsen | russellb: makes sense -- just thought I'd poke you about it :) |
| 13:02.18 | leifmadsen | we missed you (I think), if that makes you feel better :) |
| 13:02.19 | russellb | leifmadsen: specifically, though, we need to verify that dvossel's peer matching patches are done and merged. We also need to talk to Tilghman about something he was working on with IAX2 security. |
| 13:02.23 | russellb | those are my only two items. |
| 13:02.41 | leifmadsen | ok cool -- I think dvossel also has another issue to resolve in regards to IAX2 stuff |
| 13:03.02 | leifmadsen | M15834 |
| 13:03.03 | MuffinMan | [assigned] [Asterisk] Channels/chan_iax2 0015834: iax2 encryption failed on asterisk 1.4.26.2 reported by karesmakro (Karma: neutral) https://issues.asterisk.org/view.php?id=15834 |
| 13:03.08 | leifmadsen | regression |
| 13:03.14 | russellb | ah, interesting |
| 13:03.25 | leifmadsen | yes, and dvossel reproduced easily he said |
| 13:03.37 | russellb | okay, I'll follow up with him |
| 13:04.03 | snuff-home | russellb: bring back our pastrychef :) |
| 13:04.18 | russellb | M15869 |
| 13:04.19 | MuffinMan | [assigned] [Asterisk] Sounds 0015869: [patch] 1.4.26.2 still builds with freeplay MOH sounds reported by dhartman (Karma: neutral) https://issues.asterisk.org/view.php?id=15869 |
| 13:04.35 | *** join/#asterisk-dev mnt_real (n=sinan@bas12-montrealak-1167975649.dsl.bell.ca) |
| 13:08.47 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 13:10.07 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 13:10.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 13:12.01 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 13:50.29 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 13:50.30 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:04.15 | seanbright | so has anyone else noticed that PRI cables are touchy? |
| 14:04.32 | seanbright | we can't get home made ones to work reliably, but the flat ones (silky?) seem to work all the time |
| 14:04.40 | seanbright | maybe we just suck at making cables |
| 14:05.05 | Marquis42 | lol... Let's go with that. :P |
| 14:06.07 | Marquis42 | Are you using the exact same kind of ends for the silver satin and the twisted-pair cables? They are sometimes a bit different depending on the manufacturer and can cause issues. |
| 14:09.04 | russellb | what exactly is a PRI cable? *imagines Q.931 in cable form* |
| 14:09.29 | mvanbaak | ;) |
| 14:09.58 | russellb | is that similar to a SIP cable? |
| 14:10.06 | file | russellb: dang nabbit! I was going to say that |
| 14:10.06 | russellb | seanbright: <3 |
| 14:12.53 | Marquis42 | Heh... I was cutting him some slack, but I see everyone else picked it up! |
| 14:13.10 | file | Marquis42: you never cut seanbright any slack |
| 14:13.28 | Marquis42 | Give him and inch and he'll take a mile? ;) |
| 14:13.38 | file | no, 800km |
| 14:13.43 | Marquis42 | :D |
| 14:14.05 | tzafrir_laptop | A [EJT]1 cable |
| 14:14.10 | seanbright | yes |
| 14:14.10 | seanbright | that |
| 14:14.14 | seanbright | thanks for being pals |
| 14:14.19 | seanbright | i was here for 18 hours yesterday |
| 14:14.28 | seanbright | and still didn't get the connection working |
| 14:14.32 | seanbright | ... jerks |
| 14:14.38 | Marquis42 | You left 6 perfectly good hours on the table then! |
| 14:15.05 | seanbright | Marquis42: as for the cable ends, i'm not sure. will check them. |
| 14:15.32 | *** join/#asterisk-dev moy (n=moy@74.12.131.104) |
| 14:16.00 | Marquis42 | seanbright: Just a (potentially) helpful suggestion. I know at one time I had some ends of unknown origin and was having a hard time getting some ethernet cables to work well. Turned out they were, in fact, ends specific for making silver satin cables. |
| 14:16.22 | seanbright | they appears to work, but the primary d channel kept bouncing |
| 14:16.26 | seanbright | appeared* |
| 14:16.41 | seanbright | when we plugged back into the old machine with the satin cables, the pri came up |
| 14:17.17 | Marquis42 | Yeah, the issue I had (again, ethernet) was losing link every so often. So it sounds a bit similar. |
| 14:17.22 | mvanbaak | I'm so glad we ditched PRI and moved to IP |
| 14:21.09 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 14:24.07 | *** join/#asterisk-dev moy (n=moy@74.12.131.104) |
| 14:24.27 | leifmadsen | Marquis42: yo! |
| 14:25.09 | Marquis42 | leifmadsen: yo right back at you! |
| 14:25.21 | leifmadsen | Marquis42: wanna talk about that idea of yours? :) |
| 14:25.29 | Marquis42 | Oh, sure, why not? |
| 14:26.21 | Marquis42 | I'll tell you what this crazy brain is thinking, and you tell me why it makes no sense and will never work. :) |
| 14:26.34 | leifmadsen | I'll do my best :) |
| 14:28.26 | russellb | and then I'll tell you what critical thing you forgot 3 months after you write the code |
| 14:28.49 | russellb | jk, jk! |
| 14:28.50 | Marquis42 | OK, so the way I break it down is that you've got the agents and their availability and callers and their associated metadata (priority, etc.). Then you have the need of connecting them to one another in a sane way, using various queueing strategies. Right? |
| 14:29.01 | Marquis42 | russellb: LOL! |
| 14:30.52 | Marquis42 | If we go with that (intentionally simplified) high level conceptual model, we can say that the first (agent availability) is essentially a solved problem (res_ais already, with my additions to res_jabber in the future). The second, caller metadata, is easily synchronized through the same mechanism (with code magically appearing from wherever codes waits for us to request it). |
| 14:31.05 | leifmadsen | Marquis42: essentially yes, that sounds right. Need the ability for multiple boxes to be able to share metadata and sanely order the delivery of callers that do not reside on the same physical box (or same process, since you can run multiple asterisk processes on a single system...) |
| 14:31.42 | leifmadsen | Marquis42: yes, it sounds like the agent part is solved (already with res_ais, perhaps better with your new method) |
| 14:32.26 | Marquis42 | Perhaps not "better", but using a mechanism that makes it easier to integrate with other systems and so forth. |
| 14:33.02 | leifmadsen | well, better in the context that it is possible to use across WAN links :) |
| 14:33.16 | Marquis42 | Yes, true. |
| 14:34.18 | leifmadsen | so ya, are you saying you might just need to add some hooks in the appropriate places to utilize your XMPP scheme to share that metadata? |
| 14:36.07 | jsmith | leifmadsen, Marquis42: This sounds a lot like what Mark Michelson is working on with his CCSS branch, doesn't it? |
| 14:36.11 | Marquis42 | The last part, actually connecting callers to agents, is the where we have to get creative. My initial line of thinking, here, is that all you *really* need here is a way to enter the dialplan with enough information ( as part of the aforementioned metadata) to connect back to the caller from the box that reaches an agent in service of the caller. |
| 14:36.26 | jsmith | (the agent availability and call priorities pieces) |
| 14:36.28 | leifmadsen | jsmith: maybe? I don't know what CCSS does or how it's used |
| 14:36.38 | Marquis42 | jsmith: It certainly seems like there are some parallelisms, yes. |
| 14:36.40 | leifmadsen | jsmith: I'm talking the other side -- sharing the position of callers in the queue |
| 14:36.44 | jsmith | leifmadsen: Check out the branch, and go read the PDF in the doc/ subdirectory |
| 14:37.03 | leifmadsen | not the agents availabliity |
| 14:38.25 | Marquis42 | Certainly the aims of the CCSS work aren't the same, but the mechanisms being built (inasmuch as I've had the time to track the commits) seem like they may potentially prove useful. |
| 14:38.57 | Marquis42 | ...although that's even a step further probably from what I was originally envisioning. |
| 14:42.48 | Marquis42 | To finalize what I was thinking, once you're there in the dialplan you have a few options. You could have some static stuff designed to just connect back to the Asterisk instance servicing the caller's channel and bridge. You could throw in DUNDi for more dynamism (perhaps with a regcontext/regexten-style mechanism for adding extensions used for the lookup). And for larger scale systems, where the call may have *originally* |
| 14:42.49 | Marquis42 | come from a box used purely as a PSTN gateway, you could use Transfer (now that it seems to work for SIP, thanks again to file and oej!) to pull it away from the system holding it. |
| 14:44.01 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:44.01 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:44.36 | tzafrir_laptop | moy, a dahdi/R2 question |
| 14:44.38 | Marquis42 | I'm sure there are some "devil in the details" things I'm eliding, but have I gone off my rocker with this or does it seem plausible? |
| 14:45.41 | tzafrir_laptop | If I disconnect and reconnet the E1 cable in a port, it seems that it takes quite a while for chan_dahdi/openr2 to recover |
| 14:45.48 | tzafrir_laptop | Channels remain blocked |
| 14:47.08 | jsmith | Marquis42: Definitely sounds plausible... |
| 14:47.30 | Marquis42 | Cool, I need not check into an asylum just yet. :) |
| 14:47.44 | jsmith | Marquis42: Keep the straightjacket handy though, just in case :-p |
| 14:48.12 | Marquis42 | Oh, absolutely. There is always the possibility it'll be needed. |
| 14:52.20 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:52.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:53.21 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:53.21 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:55.59 | leifmadsen | Marquis42: I don't see anything you're saying that requires a 6th dimension |
| 14:59.52 | Marquis42 | Well, that's a good start I suppose. |
| 15:04.37 | tzafrir_laptop | hmmm.... the memset of size 0 has been in chan_phone since about 0.1.2 |
| 15:04.52 | tzafrir_laptop | Anybody actually uses chan_phone? |
| 15:05.40 | russellb | nice ... probably not |
| 15:08.50 | mvanbaak | sweet |
| 15:10.35 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:10.35 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:17.35 | Corydon76-dig | Do they even sell the Phonejack/Linejack anymore? |
| 15:18.07 | russellb | shrugs |
| 15:18.12 | russellb | doesn't cost us much to keep it in the tree, though |
| 15:18.29 | russellb | it's not like we get many (or any) bug reports on it :-) |
| 15:20.13 | tzanger | haha I had a pair of those |
| 15:20.18 | tzanger | before I knew asterisk |
| 15:20.59 | Corydon76-dig | http://gigaom.com/2009/02/02/quicknet-what-might-have-been/ |
| 15:21.27 | tzanger | so how are my asterisk homies |
| 15:21.32 | tzanger | god it's been forever since I"ve hung out in here |
| 15:22.03 | seanbright | we just ordered 6 satin cables overnight. i'm keeping my fingers crossed. |
| 15:22.04 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 15:22.09 | seanbright | i may be unemployed in the near future. |
| 15:23.44 | tzanger | interesting story there Corydon76-dig |
| 15:23.50 | tzanger | ... satin cables? |
| 15:23.57 | seanbright | silver satin, sorry. |
| 15:23.58 | tzanger | seanbright: unemployed by choice? |
| 15:24.01 | kpfleming | for what purpose? |
| 15:24.03 | seanbright | tzanger: heh, no. |
| 15:24.07 | file | sweet zombie tacos tzanger is in here |
| 15:24.09 | tzanger | what's a silver satin cable? |
| 15:24.13 | tzanger | zombie tacos? |
| 15:24.25 | seanbright | tzanger: http://www.computercablestore.com/1000FT_Silver_Satin_Modul_PID3.aspx |
| 15:24.35 | tzanger | ahhhhhhh okay |
| 15:24.36 | kpfleming | tzanger: you've seen them... most cheap analog phone cables are silver satin |
| 15:24.38 | tzanger | flat cable |
| 15:24.43 | kpfleming | super cheap, super crappy |
| 15:24.46 | seanbright | eh? |
| 15:24.47 | kpfleming | no, not just flat |
| 15:24.48 | seanbright | great. |
| 15:24.55 | seanbright | because our PRIs don't work on home made cables |
| 15:25.00 | tzanger | are those the cables that are made of chinese copper? |
| 15:25.02 | kpfleming | PRI won't work on silver satin |
| 15:25.03 | seanbright | only the silver satin ones. |
| 15:25.08 | tzanger | it's not quite metal, but it conducts and is impossible to solder? |
| 15:25.10 | kpfleming | T1 requires twisted pair cable |
| 15:25.10 | Corydon76-dig | kpfleming: not necessarily crappy, they work fine on short distances |
| 15:25.10 | seanbright | then we are talking about different things |
| 15:25.32 | seanbright | sangoma (at least) ships there t1/e1 cards with silver satin |
| 15:25.37 | tzanger | yep |
| 15:25.50 | Corydon76-dig | seanbright: then there's something wrong with your equipment |
| 15:25.57 | kpfleming | wow... that's a terrible idea |
| 15:26.01 | Corydon76-dig | seanbright: probably not getting a good crimp |
| 15:26.16 | seanbright | thanks for your support |
| 15:26.17 | kpfleming | i'm glad we don't do that |
| 15:26.31 | kpfleming | in fact, we ship shielded cables, since some places require them |
| 15:26.32 | seanbright | maybe it's just the clip |
| 15:26.40 | seanbright | the connector, rather. |
| 15:26.48 | Corydon76-dig | seanbright: might want to spend the $45 to get a better crimping tool |
| 15:27.00 | seanbright | alrighty |
| 15:27.13 | Corydon76-dig | because they DO wear out |
| 15:28.00 | seanbright | ok, well here is a question |
| 15:28.07 | seanbright | are all rj45 connectors created equal? |
| 15:28.11 | Corydon76-dig | Once bought a $10 crimping tool... it lasted about as long as the sample plugs that came with it |
| 15:28.20 | tzanger | haha |
| 15:28.52 | seanbright | the ones on the cables that sangoma ships (the ones that actually work, mind you) seem to have a flatter, deeper connector |
| 15:28.59 | Corydon76-dig | seanbright: dunno, I get mine usually at Graybar |
| 15:29.41 | Corydon76-dig | Or the premium ones at Home Depot also work fine |
| 15:30.21 | Corydon76-dig | One interesting thing: in the datacenter, you need to make sure that the cable run is not too SHORT |
| 15:30.46 | tzanger | Corydon76-dig: yes, there are min. cable lengths |
| 15:31.17 | Corydon76-dig | Short cables will kill the signal just as ably as crappy cable |
| 15:31.18 | tzanger | I also find it interesting that if the cable run is > approximately 20 wavelengths of the desired frequency, you should ground the shield at both ends |
| 15:31.32 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:31.32 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:33.47 | seanbright | the other thing i don't "get" is that the cables are straight through |
| 15:34.00 | jsmith | seanbright: re: your earlier comment regarding silver satin cable... often times silver satin cables will do a roll-over (1 to 8, 2 to 7, etc.) |
| 15:34.24 | Corydon76-dig | Yeah, might want to check the ends |
| 15:34.31 | seanbright | the working cables are straight through |
| 15:53.45 | moy | tzafrir_laptop: that is you cannot make or receive calls? or you mean blocked like in CAS bits rx is in BLOCKED? |
| 15:54.01 | tzafrir_laptop | yes, the rx bits |
| 15:54.05 | *** join/#asterisk-dev errotan (n=errotan@62.201.122.54) |
| 15:54.30 | moy | which ast version and openr2 version? |
| 15:55.16 | *** join/#asterisk-dev itamarjp (n=itamar@189-015-163-111.xd-dynamic.ctbcnetsuper.com.br) |
| 15:56.12 | tzafrir_laptop | asterisk 1.6.2.0-rc2 . openr2-1.2.0 |
| 15:56.30 | tzafrir_laptop | s/rc2/rc1/ |
| 15:56.59 | tzafrir_laptop | infobot knows there wasn't any rc2 |
| 15:58.44 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 15:58.54 | moy | have you used dahdi_tool to see if the bits get back to 1001? here I jus tested and takes about 5 seconds, but that's what it takes for the driver to let me know the line is up again |
| 16:07.32 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 16:07.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:52.33 | oej | Anyone knows if audiohooks is having problems in 1.4.26? |
| 16:52.49 | oej | My muteaudio works in 1.4.23 and 1.4 svn, but not in the current release. |
| 16:53.00 | oej | SO I guess that I know :-) |
| 16:55.01 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 17:05.57 | *** join/#asterisk-dev manxpower (n=EWieling@138.sub-70-214-106.myvzw.com) |
| 17:06.18 | manxpower | Does anyone know how to figure out the Kernel HZ of the currently running kernel? |
| 17:06.41 | russellb | ask it nicely? |
| 17:07.11 | manxpower | It's the QUESTION that drives us, Neo |
| 17:07.18 | manxpower | What should I ask it? |
| 17:07.33 | russellb | I dunno :-( |
| 17:12.36 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 17:12.36 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 17:13.08 | *** part/#asterisk-dev manxpower (n=EWieling@138.sub-70-214-106.myvzw.com) |
| 17:16.26 | seanbright | there are functions on linux to do it |
| 17:16.44 | seanbright | clock_getres()? |
| 17:16.46 | Marquis42 | grep CONFIG_HZ= /boot/config-$(uname -r) |
| 17:16.57 | seanbright | i guess there is that, too. |
| 17:16.58 | Marquis42 | That'll do it on a Fedora/RH box, dunno if it works on others. |
| 17:17.30 | seanbright | nifty |
| 17:17.33 | seanbright | works on ubuntu |
| 17:18.00 | Marquis42 | Excellent |
| 17:18.06 | seanbright | you're a smart dude Marquis42, i don't care what russellb, Corydon76-dig, kpfleming, putnopvut, and file say |
| 17:18.16 | Marquis42 | :D |
| 17:18.30 | russellb | seanbright: did you find a better PRI cable? |
| 17:18.36 | seanbright | eff you |
| 17:18.39 | russellb | lol |
| 17:19.05 | seanbright | i bought 2 from the store. going to test them in the morning. |
| 17:19.29 | Corydon76-dig | smacks seanbright with a sticky Elmo |
| 17:20.04 | seanbright | i know that real men make their own cables |
| 17:20.13 | seanbright | but that's just another variable i don't want to have to deal with |
| 17:21.07 | Corydon76-dig | seanbright: you do realize that terminated cables are made by men who are paid by how many they can crank out in an hour, with no regard for quality, right? |
| 17:21.25 | seanbright | yes |
| 17:21.28 | russellb | I don't blame you, sometimes the cost savings of your own cable aren't worth the potential cost caused by problems due to a flaky cable |
| 17:21.32 | seanbright | thanks again |
| 17:21.38 | russellb | and by sometimes, I mean almost always, heh |
| 17:22.53 | Corydon76-dig | russellb: I've had more flaky preterminated cables than I have had cables that went bad that I terminated myself |
| 17:23.48 | Corydon76-dig | Customer-terminated is a different story. Some people apparently haven't gotten a clue |
| 17:23.58 | seanbright | i've made *1* cable in my entire life |
| 17:24.05 | seanbright | and it worked just peachy |
| 17:24.07 | russellb | I guess you're a pretty big deal, then Corydon76-dig :-p |
| 17:24.12 | seanbright | totally |
| 17:24.14 | seanbright | heh |
| 17:24.24 | seanbright | Corydon76-dig: make me 2 cables and mail them to me |
| 17:24.28 | seanbright | i'll even pay |
| 17:24.36 | Corydon76-dig | seanbright: terminated how? |
| 17:25.08 | seanbright | cat5? |
| 17:25.11 | seanbright | is that the wrong answer? |
| 17:25.26 | Corydon76-dig | cat5 refers to the type of cabling, not the termination |
| 17:25.29 | russellb | terminated with a PRI connector |
| 17:25.30 | seanbright | ahh |
| 17:25.31 | russellb | runs |
| 17:25.34 | seanbright | heh |
| 17:25.41 | seanbright | i never claimed to be smart |
| 17:25.52 | jsmith | seanbright: I'm closer... give me a good excuse, and I'll drive up and terminate some cables for you |
| 17:25.55 | seanbright | and i still got commit access somehow |
| 17:26.16 | Corydon76-dig | seanbright: we can fix that in two shakes |
| 17:26.43 | seanbright | but then you wouldn't have a new menuselect front end every 6 months |
| 17:26.48 | Corydon76-dig | seanbright: what's your mailing address? |
| 17:27.03 | seanbright | russellb has it |
| 17:27.08 | seanbright | in an email somewhere |
| 17:27.24 | seanbright | or if you are serious i can pm |
| 17:28.06 | Corydon76-dig | Just post it on stalkersrus.com... I'll find it... |
| 17:28.12 | seanbright | and what is the correct response to the termination question? rj45? |
| 17:28.49 | Corydon76-dig | No, something along the lines of "straight through", "T1 crossover", "Ethernet crossover" |
| 17:28.56 | seanbright | straight through |
| 17:29.25 | jsmith | www.jaredsmith.net/misc/cables/ help? |
| 17:29.33 | Corydon76-dig | Basically, termination refers to how the pins at opposite ends connect |
| 17:29.44 | seanbright | jsmith: if it wasn't a 404, it might |
| 17:29.53 | jsmith | Doh! |
| 17:29.56 | jsmith | Try http://www.asteriskdocs.org/cables/ instead |
| 17:30.05 | seanbright | same |
| 17:30.08 | seanbright | err |
| 17:30.16 | seanbright | there we go. |
| 17:31.02 | Corydon76-dig | btw, you really should stop using the term "rj45". That refers to a specific cable part made by AT&T back in the Ma Bell days |
| 17:31.18 | seanbright | ok |
| 17:31.21 | seanbright | i'll be sure to do that |
| 17:34.55 | Corydon76-dig | "Mod8 plug" is more correct |
| 17:35.21 | russellb | is it more correct or less incorrect? |
| 17:35.56 | Corydon76-dig | Yes |
| 17:37.43 | Corydon76-dig | and also, the receptacle isn't a "jack" |
| 17:38.49 | Corydon76-dig | A jack is the male side of the connector... Call a receptacle a "Jill", if you don't want to call it a receptacle |
| 17:39.00 | russellb | Corydon76-dig: you are +47 pedantic today |
| 17:39.25 | Corydon76-dig | AND ANOTHER THING... |
| 17:39.39 | putnopvut | russellb: he's making up for being out sick yesterday |
| 17:40.01 | Corydon76-dig | Being sick sucks |
| 17:40.22 | russellb | actually, Corydon76-dig, it doesn't suck. That's what a vaccum does. |
| 17:40.26 | putnopvut | Corydon76-dig: amen to that |
| 17:40.28 | russellb | Depending on the sickness, it might blow. |
| 17:40.54 | Corydon76-dig | Actually, I was pretty much sleeping the entire day |
| 17:44.23 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 18:06.41 | *** join/#asterisk-dev abalashov (n=sasha@216.126.43.100) |
| 18:06.48 | abalashov | Howdy |
| 18:07.32 | abalashov | Is there a fairly easy way to get a reference to the other RTP stream (struct ast_rtp) associated with a call in chan_sip if the streams are natively, not Packet2Packet bridged? |
| 18:07.52 | abalashov | I'm looking to do so in handle_request_invite(). |
| 18:08.16 | abalashov | If they are Packet2Packet bridged, it's easy - ast_rtp_get_bridged(p->rtp) does the trick. |
| 18:08.22 | abalashov | But if they're natively bridged, that returns NULL, obviously. |
| 18:08.43 | russellb | It's possible, but not pretty. |
| 18:08.49 | abalashov | Yeah, I know it won't be pretty :( |
| 18:08.50 | abalashov | But I need to do it. |
| 18:08.54 | russellb | You'd have to start by getting the bridged channel (ast_bridged_channel()) |
| 18:09.07 | abalashov | (Need to call ast_new_rtp_source() on the other leg of the media, not the current one) |
| 18:09.10 | russellb | and then make sure it's a SIP channel ... IS_SIP_TECH() or some such macro in chan_sip can check for you |
| 18:09.49 | abalashov | This is all to cause a Mark bit to be set on the next outgoing RTP frame after a re-INVITE |
| 18:09.51 | russellb | oh, well see, this is a case where you should have started out by talking about what the problem was :-) |
| 18:09.55 | abalashov | Yeah :/ |
| 18:09.56 | abalashov | I know. |
| 18:10.01 | russellb | there is a much easier way to do that |
| 18:10.12 | russellb | you need to queue a control frame on the current channel AST_CONTROL_SRCUPDATE |
| 18:10.13 | abalashov | The need is to set the mark bit on an outgoing stream when a reinvite is received, but it has to be on the other stream, not the current one. |
| 18:10.18 | russellb | which will get read, and then written to the other side |
| 18:10.30 | abalashov | Will it set the mark bit? |
| 18:10.56 | russellb | that's the idea yes |
| 18:11.00 | abalashov | My impression is that this can only be accomplished by setting rtp->set_marked_bit |
| 18:11.06 | abalashov | which requires accessing that rtp structure directly |
| 18:11.12 | abalashov | (or via the ast_rtp_new_source() wrapper) |
| 18:12.16 | abalashov | It didn't seem to me that any of the code that acts on the SRCUPDATE control frame in main/rtp.c also sets the mark bit. |
| 18:12.21 | abalashov | But I could be wrong. |
| 18:12.48 | russellb | sounds like you're 3 steps ahead of me |
| 18:13.05 | abalashov | maybe, but I'm not familiar with the RTP implementation nearly enough to be able to say for sure where I am :) |
| 18:13.28 | russellb | this is weird, I think something like this was _just_ reported internally ... |
| 18:13.40 | abalashov | It's a very ubiquitous problem, wouldn't surprise me |
| 18:13.49 | abalashov | (mostly with Level3's TNT origination stuff) |
| 18:14.04 | abalashov | it's like this: Carrier ---> Asterisk leg [A] <- native bridge -> Asterisk leg [B] --> internal peer |
| 18:14.12 | russellb | yep, that is the exact situation |
| 18:14.16 | abalashov | internal peer sends re-INVITE, carrier timing needs to be resynchronised |
| 18:14.24 | abalashov | so as to avoid a 3-5 sec audio gap |
| 18:14.37 | russellb | exactly .. |
| 18:14.39 | russellb | well then! |
| 18:14.42 | abalashov | yep, it's a widespread issue... it wouldn't be a problem if OOB DTMF were used |
| 18:14.49 | abalashov | but, that doesn't work in this case for various reasons |
| 18:14.55 | abalashov | so there's two approaches |
| 18:15.07 | abalashov | the "internal peer" *does* send a mark bit when the reinvite happens |
| 18:15.15 | abalashov | so, either 1) pass the mark bit through in native bridge - if that's easier |
| 18:15.17 | *** join/#asterisk-dev puzzled (n=foobar@puzzled.xs4all.nl) |
| 18:15.19 | abalashov | or 2) just set the mark bit on a reinvite |
| 18:15.23 | abalashov | I was going for option #2. Maybe #1 is easier. |
| 18:15.42 | russellb | well, #1 should be easier, as we have mechanisms like that in place |
| 18:15.49 | russellb | having to grab data from the other side of the bridge is nassssssssty |
| 18:15.59 | abalashov | That's what I figured, but didn't see a straightforward way to do that. |
| 18:16.02 | russellb | mostly due to the amount of locking involved and potential for deadlocks which are nearly impossible to avoid |
| 18:16.18 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:16.18 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:16.18 | abalashov | Any guidance would be appreciated - my familiarity with main/rtp.c is pretty low :( |
| 18:16.42 | russellb | so, first, I'm curious if we are properly sending a SRCUPDATE CONTROL frame across the bridge when the internal stream changes |
| 18:16.43 | abalashov | if OOB DTMF were used this wouldn't be an issue, the channels would just be P2P bridged and the Mark bit would automatically get passed |
| 18:17.06 | abalashov | but since it's regenerated out of native bridge (which is mandatory with inband DTMF)... |
| 18:17.23 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:17.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:17.33 | russellb | do you have this labbed up? |
| 18:17.39 | abalashov | yeah, fairly |
| 18:18.24 | abalashov | I see nothing in the reinvite handler (in the bits where SDP changes are processed) that enqueues an SRCUPDATE CONTROL frame. |
| 18:18.45 | russellb | but when that happens, in the RTP itself, the SSRC changes, though, right? |
| 18:18.51 | russellb | we should generate it based on that |
| 18:19.00 | abalashov | I believe so, yes. |
| 18:19.16 | abalashov | I'm just looking for a quick solution - I'm quite sure you guys will have a better internal one when this issue is officially addressed |
| 18:19.27 | abalashov | and so my solution was to just force the mark bit to be set when any reinvite+SDP is received |
| 18:19.29 | russellb | I'm trying to officially address it right now :-) |
| 18:20.06 | abalashov | Well, fair enough :) |
| 18:20.31 | russellb | If you queue a SRCUPDATE frame, it should get passed across, and will result in a call to sip_indicate() on the other channel |
| 18:20.39 | abalashov | It's regrettable that this is even an issue - it's because so many folks are forced to use inband DTMF due to Sonus sucking at OOB, and thus not being able to take advantage of P2P bridging |
| 18:20.42 | russellb | handling of that will result on a ast_rtp_new_source() call |
| 18:20.49 | abalashov | Ah. |
| 18:21.00 | russellb | and all that does is set set_marker_bit to 1 |
| 18:21.05 | abalashov | Understood. |
| 18:21.36 | abalashov | ast_queue_control(p->owner, AST_CONTROL_SRCUPDATE); ? |
| 18:21.49 | russellb | exactly |
| 18:21.55 | abalashov | let's have a look-see! |
| 18:21.56 | russellb | So let's see what happens there ... |
| 18:22.04 | abalashov | *compiles* |
| 18:22.50 | russellb | I'd like to 1) see if that fixes it, and if so, 2) why wasn't that already happening automatically based on the RTP stream changes |
| 18:22.58 | abalashov | That does not fix it. |
| 18:23.18 | abalashov | but, hang on, I didn't get a console message indicating that a reinvite was received either |
| 18:23.19 | abalashov | one sec |
| 18:23.40 | abalashov | oh, haha ... yeah, um, 'make install' might help |
| 18:23.42 | abalashov | *facepalm* |
| 18:23.48 | russellb | hehe |
| 18:24.19 | abalashov | No, doesn't fix it :( |
| 18:24.33 | russellb | hrm. |
| 18:24.36 | abalashov | now, let's examine where I put that control frame enqueue directive a sec |
| 18:24.50 | abalashov | <PROTECTED> |
| 18:24.50 | abalashov | <PROTECTED> |
| 18:24.50 | abalashov | <PROTECTED> |
| 18:24.50 | abalashov | <PROTECTED> |
| 18:24.50 | abalashov | <PROTECTED> |
| 18:24.51 | abalashov | <PROTECTED> |
| 18:24.52 | abalashov | <PROTECTED> |
| 18:24.54 | abalashov | <PROTECTED> |
| 18:24.57 | abalashov | <PROTECTED> |
| 18:25.00 | abalashov | That's on line 14748 in chan_sip.c |
| 18:25.22 | russellb | did you see your message? |
| 18:25.23 | abalashov | yep |
| 18:26.02 | oej | what is the task at hand, folks? |
| 18:26.18 | abalashov | I also tried ast_new_rtp_source() before when I was just messing around, in that exact spot, and it did work... unfortunately, it had the problem of setting the marker bit on the same stream, which isn't what I was looking to do. :/ |
| 18:26.30 | abalashov | And then I realised I need to acquire the other leg, and went down this rabbit hole |
| 18:26.32 | russellb | right, wrong channel. |
| 18:26.49 | russellb | so I'm reading some of rtp.c, and it doesn't appear to be doing what I thought it did. |
| 18:27.05 | abalashov | Yeah, so, I guess I either need to look up the bridged channel and call ast_new_rtp_source() on it, but as you mentioned that is both cumbersome and dead-lock prone. |
| 18:27.06 | russellb | I thought we would queue up a SRCUPDATE based on a SSRC change on the incoming stream, but it does not appear that we actually do that |
| 18:27.21 | file | no, we only queue up a srcupdate if we internally know the media stream is changing |
| 18:27.24 | russellb | well, what you did should result in exactly that if the channels are bridged |
| 18:27.25 | abalashov | Well, the point is I just queued it up manually and it still did not result in sorting out the audio gap. |
| 18:27.29 | russellb | file: yeah |
| 18:27.41 | russellb | abalashov: are you sure the channels were bridged at that point? |
| 18:27.41 | abalashov | Well, they're not "bridged" in the rtp->bridged sense |
| 18:27.48 | abalashov | native bridging, not P2P |
| 18:27.52 | russellb | they may not have been bridged, yet. |
| 18:28.02 | abalashov | they were, this was like 15s into the call when the second reinvite shows up |
| 18:28.04 | abalashov | to a different media server |
| 18:28.07 | russellb | oic. |
| 18:28.17 | file | native bridged would mean the audio stream is direct... |
| 18:28.45 | russellb | i presume you meant generic bridge, abalashov ? |
| 18:28.54 | abalashov | yep |
| 18:29.06 | abalashov | Sorry, I get these confused. "Native bridge" to me means non-P2P. |
| 18:29.22 | abalashov | Meaning it actually runs through the RTP core event bus etc. |
| 18:29.24 | russellb | P2P is a native bridge, actually :-) |
| 18:29.26 | abalashov | oh |
| 18:29.31 | abalashov | Well, that would explain the confusion |
| 18:29.33 | russellb | and so is direct media |
| 18:29.34 | file | that should still work, unless the marker bit won't actually cause the sonus to behave |
| 18:29.37 | russellb | generic is ... different |
| 18:29.39 | abalashov | okay, it shall henceforth be referred to as a Generic Bridge(TM) |
| 18:29.42 | abalashov | :) |
| 18:30.03 | abalashov | I suppose I better do a packet capture and verify that the marker bit actually didn't go out |
| 18:30.04 | abalashov | one moment |
| 18:30.07 | russellb | abalashov: can you add a log message to ast_rtp_new_source() to see if it gets called? |
| 18:30.14 | russellb | that works too |
| 18:30.15 | abalashov | file: Yes, it is known that it will cause the TNT to behave |
| 18:30.24 | abalashov | file: But empirical testing is better, I agree |
| 18:30.46 | abalashov | Sonus doesn't have a problem with this because it basically ignores the timestamps, or seems to |
| 18:30.58 | abalashov | what happens is Asterisk passes through the timestamps but keeps the SSRC and Seq steady |
| 18:31.07 | abalashov | whereas the TNTs are strict and decide that means loads of jitter |
| 18:32.52 | oej | Quick questions - russellb: Anything against integrating that INTMAX stuff into 1.6.2? |
| 18:33.15 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 18:33.26 | russellb | not from me, no |
| 18:33.30 | russellb | also, did you see my comment about that? |
| 18:33.46 | russellb | ah, you did, cool |
| 18:33.48 | oej | I just fixed it. Thanks. |
| 18:33.53 | russellb | no problem |
| 18:33.58 | abalashov | russellb: Well, now this is interesting. It appears that the frame with the Mark bit does go out. Doesn't fix the issue, sadly. |
| 18:34.11 | russellb | I wonder if it really wants the ssrc changed, too. |
| 18:34.20 | abalashov | It almost certainly does |
| 18:34.32 | abalashov | the frame that goes out with the mark bit set has timestamp=0 |
| 18:34.32 | russellb | ast_rtp_new_source() currently _only_ sets the marker bit |
| 18:34.37 | abalashov | Yeah, I know. |
| 18:34.39 | russellb | it does not change the SSRC. |
| 18:34.41 | abalashov | everything else is held constant |
| 18:34.46 | russellb | but it should I think. |
| 18:35.03 | russellb | so, try one more thing. |
| 18:35.06 | file | ugh |
| 18:35.08 | file | I've been down this road |
| 18:35.18 | file | changing the ssrc caused another implementation to freak out |
| 18:35.26 | russellb | in ast_rtp_new_source(), instead of just rtp->set_marker_bit = 1;, also add rtp->ssrc = ast_random(); |
| 18:35.27 | abalashov | Well, the hypothesis was that if you set the mark bit it'll cause the TNT to resync on the new timestamps, and that's what I was looking to confirm. |
| 18:35.31 | russellb | file: ugh, seriously? |
| 18:35.34 | file | russellb: yes |
| 18:35.39 | abalashov | russellb: Oh, it's that easy? Well, let's try it then! |
| 18:35.39 | file | long ago I had it change the ssrc |
| 18:35.56 | abalashov | file: I'm in a pretty controlled environment here. As long as the implementations _I'm_ dealing with don't freak out, hey... :) |
| 18:35.58 | russellb | well it's the right thing to do, so I guess yet another configurable behavior thing? |
| 18:36.27 | oej | Yes, RTP is black magic and all vendors seems to handle marker/ssrc differently |
| 18:36.33 | abalashov | SSRC is just a completely arbitrary GUID, no special characteristics? |
| 18:36.37 | russellb | how exciting! :-) |
| 18:36.40 | oej | It will be very interesting with SRTP |
| 18:36.47 | russellb | abalashov: yep, supposed to be random |
| 18:36.52 | russellb | the important thing is that it changes value |
| 18:37.04 | abalashov | testing now |
| 18:37.20 | russellb | This is Asterisk development, live folks! Get your tickets here! Popcorn $5! |
| 18:37.22 | oej | Hmm. Changing ssrc without reinvites... |
| 18:37.24 | abalashov | well, that did it ;-) |
| 18:37.34 | abalashov | oej: There are reinvites in this scenario. You weren't around for my description of it. :) |
| 18:37.54 | abalashov | That works.. my concern is that there are a few carriers being used for origination. The Level3 TNTs will munch on this, but I wonder how the Sonuses & co. will feel |
| 18:38.10 | abalashov | so we'll need to test to see if it breaks *any* of the vendors' edge equipment |
| 18:38.11 | russellb | Yeah, I'm not sure what the final proper change will be here ... |
| 18:38.30 | abalashov | well, it sounds like I need to keep my SRCUPDATE control frame in there |
| 18:38.35 | abalashov | because otherwise it doesn't get updated at all |
| 18:38.43 | russellb | right, as expected now that I read the code more |
| 18:39.12 | abalashov | (Is there any harm in queuing an SRCUPDATE control frame on all reinvites with an SDP body generically?) |
| 18:39.21 | abalashov | (From a incorporate-this-into-release perspective?) |
| 18:39.33 | russellb | looks around at the SIP experts in the room |
| 18:39.50 | russellb | it seems like it shouldn't hurt ... |
| 18:39.54 | file | hrm hrm hrm |
| 18:39.56 | oej | Depends if the SDP is the same or a new version |
| 18:39.56 | file | it *should* be okay |
| 18:40.14 | oej | You need to update the SDP if there's any change |
| 18:40.39 | russellb | so, let's say, a reinvite with an updated SDP version |
| 18:40.43 | abalashov | but if nothing's changed on the incoming SDP, including version, what's the harm in regenerating the same info? |
| 18:40.52 | abalashov | just to keep logic simple? |
| 18:41.03 | russellb | abalashov: well, it's just not "the right thing to do" |
| 18:41.15 | russellb | you know, standards and all of that ;-) |
| 18:41.19 | abalashov | Understood. |
| 18:41.39 | russellb | I do a pretty good job of breaking standards compliance, so I'm trying to improve on that, heh. |
| 18:42.12 | abalashov | Well, let me ask you and oej this... |
| 18:42.23 | abalashov | In principle, when there is a reinvite received with, let's say, a new SDP version |
| 18:42.35 | abalashov | are implementations expected to break if they get a marker *and* a new SSRC? |
| 18:42.42 | abalashov | It seems almost logical to generate a new SSRC at that point. |
| 18:42.59 | abalashov | certainly works with the TNTs in question here |
| 18:43.47 | oej | I can't say I'm an expert at that layer, to me it's just a matter of adapting to all the SBCs out there and how they do that. File has been digging more in all of this. |
| 18:44.01 | oej | But my feeling is that in order to change SSRC, we need a new offer/answer. |
| 18:44.09 | oej | This will be even more important in SRTP |
| 18:44.36 | abalashov | Well, in this case there is a new offer, and certainly, a new answer |
| 18:44.42 | abalashov | but it just happens to be that the scenario aligns this way |
| 18:44.43 | file | but not on the other leg |
| 18:44.52 | abalashov | oh, I see |
| 18:44.54 | abalashov | yeah, correct |
| 18:44.56 | oej | Ahh. I can't block a commit to 1.6.2 in 1.6.1... Of course. Stupid me. |
| 18:45.11 | file | to the other leg you are just changing the ssrc in the middle of things |
| 18:45.15 | abalashov | of course |
| 18:45.30 | abalashov | seems to work for the TNT splendidly, but I haven't tried with Sonus or the various other origination gear potentially in use here |
| 18:46.39 | russellb | file: but that's ... okay, right? Don't we do that with things like file playback? |
| 18:46.41 | russellb | or did I make that up ... |
| 18:46.47 | file | we don't |
| 18:46.51 | russellb | ah, just on bridges and such |
| 18:46.59 | file | we never change the ssrc |
| 18:47.01 | file | we only set the marker bit |
| 18:47.02 | russellb | oh, right |
| 18:47.21 | abalashov | I like the marker-only idea better, too, but in this case that did not fix the problem because the timestamps still change midstream |
| 18:47.30 | abalashov | and I guess if the timestamps change but SSRC does not, the TNT finds that to be hosiery |
| 18:47.38 | leifmadsen | grabs the popcorn |
| 18:47.54 | abalashov | (but the Sonus, for example, does not - we know that for a fact) |
| 18:48.16 | file | the Sonus has its own set of problems, albeit related |
| 18:48.20 | abalashov | for sure |
| 18:49.35 | abalashov | the curious thing for me is that the marker-only approach did not fix the problem |
| 18:49.50 | abalashov | because, if you have a look at https://issues.asterisk.org/view.php?id=11491 |
| 18:49.59 | abalashov | this leads to the impression that for one user, this was the solution relative to Level3's TNT origination platform |
| 18:50.04 | abalashov | well, I'm using it too, and no go |
| 18:50.24 | abalashov | in fact, there's a suggestion there from file in the bottom |
| 18:50.25 | abalashov | r105676 | file | 2008-03-04 14:10:34 -0400 (Tue, 04 Mar 2008) | 2 lines |
| 18:50.25 | abalashov | In addition to setting the marker bit let's change our ssrc so they know for sure it is a different source. |
| 18:50.26 | abalashov | :) |
| 18:51.01 | file | right, but I reverted that part |
| 18:51.04 | abalashov | :) |
| 18:51.14 | file | screwed either way ^_^ |
| 18:51.24 | russellb | yay! |
| 18:51.44 | file | we can certainly change that API call... and make an option in sip.conf, blargh |
| 18:52.00 | leifmadsen | sounds like you have no choice in the matter really |
| 18:52.12 | leifmadsen | one method breaks one set of end points, and the other option breaks the other set |
| 18:52.25 | russellb | file: yeah, that's what I was thinking ... |
| 18:53.39 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 18:57.18 | abalashov | Well, I'm going to test it with Sonus here in a little bit |
| 18:57.33 | abalashov | but unfortunately Sonus and Level3/TNT is all I have access to immediately right at this moment |
| 18:57.44 | abalashov | who knows how other vendors will react to it, I can't answer that easily |
| 18:57.55 | abalashov | hey, thanks a lot for your help guys, appreciate it very much.... |
| 18:58.14 | abalashov | If you want I can stick around and let you know how this fares with Sonus |
| 18:58.43 | abalashov | heck, I think I can probably fenagle a test with Acme Packet as well |
| 18:58.50 | abalashov | but definitely not a full gamut |
| 18:59.17 | russellb | sure, would be nice to know |
| 18:59.24 | russellb | and you're welcome :-) |
| 18:59.39 | russellb | that will cost you one basket of muffins |
| 19:00.00 | abalashov | I'm in Atlanta, I'm sure I'll make the trip down to HSV sometime |
| 19:00.12 | russellb | I was just kidding, though :-) |
| 19:00.15 | abalashov | sorry I missed you at the SE LinuxFest, a lot of folks from Athens, GA/UGA (where I was for about 8 years) went |
| 19:00.18 | russellb | but yeah, it would be great to have you here for a visit. |
| 19:00.36 | russellb | That conf was a lot bigger and more fun than I expected |
| 19:00.50 | abalashov | I still spend like half my time in Athens |
| 19:00.54 | abalashov | though I nominally live in ATL |
| 19:01.15 | abalashov | so if you met any CHUGALUG folks I probably know 'em |
| 19:01.41 | abalashov | (not to be confused with the Chattanooga CHUGALUG) |
| 19:03.57 | abalashov | Good news, Sonus works |
| 19:04.49 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 19:08.23 | Corydon76-dig | abalashov: but do you know 404 2600 folks? |
| 19:08.31 | abalashov | That I do not |
| 19:09.04 | Corydon76-dig | I think there's far more Digium folk who belong to 2600 groups than belong to LUGs |
| 19:10.34 | *** join/#asterisk-dev xpot-mobile (n=james@173.8.94.1) |
| 19:15.31 | *** part/#asterisk-dev abalashov (n=sasha@216.126.43.100) |
| 19:33.28 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 19:41.40 | seanbright | mnick? |
| 19:44.20 | putnopvut | seanbright: he's an intern at Digium. |
| 19:44.34 | seanbright | ahh |
| 19:53.33 | oej | Who's "mnick" that's committing? Presentation? |
| 19:54.21 | russellb | He just started and just got his cert. |
| 19:54.31 | russellb | I will send something out today. |
| 19:55.03 | oej | thanks! |
| 19:56.01 | *** join/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 19:56.33 | *** part/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 19:56.57 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 19:56.57 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 20:09.41 | *** join/#asterisk-dev moy (n=moy@74.12.131.104) |
| 20:38.54 | *** join/#asterisk-dev elguero (n=elguero@ns1.nashuacs.com) |
| 20:40.43 | *** join/#asterisk-dev tamiel (n=tamiel@ip-7.net-81-220-254.rev.numericable.fr) |
| 22:24.00 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 23:10.38 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 23:20.52 | *** join/#asterisk-dev itamarjp (n=itamar@189-015-163-111.xd-dynamic.ctbcnetsuper.com.br) |
| 23:40.16 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@212.179.75.202) |
| 23:40.16 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |