Dedicated to the strength of the nation. Yes, proudly we hail, starring Buck Cobb in Dottie's Dilemma, the United States Army and United States Air Force presentation. Now, here's our producer, the well-known Hollywood showman, C.P. McGregor. Thank you, thank you very much, and greetings from Hollywood, ladies and gentlemen. Welcome to your Theatre of Stars. For all your popular favorites of the motion picture world, join us in plays we know you'll enjoy. Our star is the vivacious young actress, Buff Cobb, in the title of our story, Dottie's Dilemma. This is the story of a young woman cub reporter who sets out to scoop the veteran news hawks of the Fourth Estate to prove that she has brains to use along with their beauty. We'll have the curtain for Act One in just a moment, but first, here's your announcer with this message. Choose the career that offers all five. The U.S. Army offers you these five keys to a successful future. One, a career of service to country. Two, the right job for you. Three, continuous training for planned advancement. Four, lifetime security. Five, travel and recreation. Yes, men, choose the career that offers all five. Find out about the five keys to a successful future at your nearest U.S. Army and U.S. Air Force recruiting station. And all once again, our producer. Act One of Dottie's Dilemma starring Buff Cobb. Last week, love as it does to all men came to Ken Phillips, managing editor of the Evening Times.  Well, anyway, she's rushing. Come out of there, Ken. I see you hiding under that desk. No, Dorothy. Do you know how long I've worked and labored and struggled on this paper without being given a big assignment? Yes, dear. Three weeks. Well, I want action, not a pension. You solemnly promised to let me be a reporter and send me out on a big story. And so I will, dear. I've just been looking through some of your work. Your style of writing hasn't proved tremendously. Oh, Ken, do you really think so? Oh, I certainly do, darling. Now, take your Smith story, for example. Ah, yes, here it is. Died. Smith Chansey, 93. Services, 2 p.m. Forest Grove Cemetery. Oh, believe me, Dorothy, you have a natural flair for obituaries. Obituaries? I know what you're doing. You're trying to break my spirit. Honey, Superman couldn't even bend your spirit. I'll give you one last chance. You are going to assign me to something big, like well-liked liquidation incorporated. Oh, well, just like that. Yes, just like that. Well, that's fine. I like it. My staff spent six months trying to uncover a mysterious organism, the deals in wholesale murder, which for the time being, we call liquidation incorporated. And you think you can solve it. Just like that. Yes, just like that. We don't know whether we're coming or going. I've got it all figured out. We're completely in the dark. I've got it all figured out. I think we finally found a stool pigeon who will talk. I've got it all figured out. But right now all we know is that they're desperate killers. We've got Detective Murphy, my bodyguard. Oh, no, not Murphy. He was such a nice guy. Oh, can't I can't believe it. Ah, now do you want to go on the story? I'll get them for this if it's the last thing I do. Oh, sure. Sure, you'll catch them. Yeah. You could. Yeah. The police can. My best reporters can't. I can't. But you can't. I can't. Sure. Oh, you could handle a story like this with ease. Oh, Ken, thanks. I knew you'd see it my way. I'll get to work on the case immediately. Yes, but I was only kidding. So long, Ken. Dorothy, come back. Where shall I begin? Who did that? It's me. Well, don't do it again. So what's the matter? Is there something wrong with your valves? Hey, look, assistant. I'm a biggie. You certainly are. Go away. Hey, look, dial a big shot in there to let me in and stop giving me the brush off. I'm the guy that can give him a lowdown on the liquid desimine incorporated. Did you say? Liquid desimine. Hey, what's the idea?  Don't say a word. We're being watched. Come on down the hall. I want to see you alone. Hey, but why you do this? Quick. We can talk in this broom closet. I don't want to go under no broom closet with you. What's the matter? Are you bashful? Get in there before somebody sees you. Now, sit down on that bucket. I don't like this. It ain't respectable. Go ahead. Sit down. Well, okay, okay, but quit a potion. I'll turn on the light and I'll close the door. Now we can talk. Are you comfy? What do you mean, comfy?  Oh, well, that's fine. Now tell me everything you know about liquidation incorporated.  Well, you see, there's a hundred cups. Go ahead. Look under this wallet. Detective Sergeant Murphy. Yeah. That's the cop that was murdered last night. Why you? Hey, let it go. I didn't do it. But for 500 bucks, I can take you to the hideout of the gang that did. 500?  Wait and I'll see how much I have in my purse. 20, 30, 40. Ah, ah, ah. No peeking. 45. That's all you got? 45? No, no, wait. Here's another one. 46 cents. Cents? And some peanut brittle. How do you like the bigger business? But I could get $50 out of my Christmas club and pay you the rest after I get the story. How do I know I can trust you? Oh, that's silly. Just look at me. Yes, sir, I am. And that's what worries me. You sort of reminded me of a Sadie Smith. Who's Sadie? It's a friend of mine who wants to live in a bigger house.  Except the Sadie was a classy dresser. You mean if I wore a bright red dress and carried a violin case, I could pass for a lady gangster? Sadie was a no-go on a mild. She was a poison queen. Me and a Lucy Bodger. That's what she was to say. Me and a Lucy Bodger, we got a racket. Me and Lucy Bodger. Piggy, will you take me there for $50 cash and the rest when I get the story? Well, if you ain't got a rest, I guess I'll have to. Now, here's a set up. I'm a taker. You'll be killed as a hideout as soon as I get tickets. Good Lord, they don't sell tickets. No, training tickets. It's about a 50 miles out of town. I'll get a compartment so we want to be seen traveling together. I'll meet you at my place in about one hour. Where is your place? He's down the street a couple of blocks. Up the stairs from the fish market. Well, I'll see you later, Piggy. Don't you want the address? Oh, don't worry about me. I'll find it. Today's Friday. It's over a fish market. All right, boys, break it up, break it up. And keep the stairway clear. If I come down to hurry, I won't be yelling scat. I guess this is it. Piggy, are you busy? Would you rather I came back later? Unlocked all the time. Oh, hello, Piggy.  You can't do that. Wait here. I'll phone the police. No, there's no time. Find a man with a scar. You just leave everything to me and I'll... Who? The big fellow shot at me. Had to liquidate him in a cupboard. He's got a scar on his arm. A scar all the way from elbow to wrist. Is this his gun? That's his. Can't you think of anything else to identify him? Scar. No, but I can't very well go around town asking all the men to take their coats off.  Oh, he died. Oh, Joji, Ken, I've got to tell Ken. Ah! Oh, excuse me. Oh, you frightened me. I... I didn't know you were here. Yeah. You see, I've been watching this house for several days. Go on, get back in there.   Yeah. I heard some shots up here.  Something terrible has happened. A man's been... Well... Oh, dear, you don't think that... Don't I? I suppose it's only a coincidence that you're holding a gun and there's a body lying over there on the floor. Body? Yeah, body. Uh... Over there. Oh, that one! Yeah, that one. Embarrassing, isn't it? Come on. What is this murdered man doing here? I don't know. I guess it's just one of those things. Well, I'll have to be getting along, Mr.... I don't believe we've met. My name is Scott. Dorothy Scott. Oh, pleased to meet you. My name is Williams. Jerry Whitt... Hey, I don't care who you are. Why did you do it? But I tell you, I didn't do it. I was down here getting a story. I'm a reporter on The Evening Times. These clothes I'm wearing are just a disguise. You want to see my credentials? Uh, yeah. Oh, you do? Yeah. And, uh, stop pointing that gun at me. Oh, it's empty, see? Well, it's empty now. Hey, give me that thing. Now, what can you tell me about this man? He's dead. You don't say. Look, if I tell you everything I know about this case, will you let me have the story first when you make the arrest? Well, uh... It's all figured out. Everything boils down to one question. What? Who killed him? Now, we're getting somewhere. The first clue is these handcuffs on the table. They belong to Detective Murphy who was murdered last night. These were his bracelets? Ah, I'll take them for evidence. Okay. Now, Murphy was killed by liquidation incorporated, and piggy squeals so they slaughtered him. He was going to take me to their hideout. It was out of town, so he bought train tickets. Yeah? Well, here are some tickets in his pockets. Well, now all we have to do is follow up that clue and catch the gang. Let me see what station the tickets are for. Never mind, never mind. I'm following up this clue myself. Oh, but you've got to take me with you. Now look, I've got trouble enough on my hands. You stay here where it's safe until the coroner comes. But I... I'm going to follow up this ticket clue. Well, of all the nerves, you want to make the capture yourself. You want all the glory. Hey, wait a minute, wait for me. Quick, kitty, which way did he go? Oh, he won't talk, eh? Okay. Meow! Sorry, but I got to know. Nobody's going to muscle in on my murder. The curtain screeches down and act one of our play, Dottie's Dilemma, starring Buff Cobb. In just a moment, act two. First, a word from our government. High school graduates, there's an important place for you in the U.S. Air Force. You can continue your education, learn a trade, get ahead, and at the same time earn good pay. The United States Air Force has openings for specialists in air transport, aircraft maintenance, research, clerical administration, radio, and many other fields. The Air Force will train you for one of these responsible jobs. Two kinds of training are open to you. You can learn on the job under world's most skilled experts, or if you qualify, you can go to the finest Air Force in all schools as vacancies exist. You will find interesting work, job security, sound retirement benefits, and opportunity for travel. This is your big opportunity. Look into it today. Get full details at your nearest Air Force base, our United States Army, and United States Air Force Recruiting Station. Act two of Dottie's Dilemma, starring Buff Cobb. Dottie, out on the trail of a gang which deals in wholesale mayhem, won't be shaken off by anything from threats to bribes. Having made some important discoveries with Jerry, a man whom she believes to be a detective, she cannot accept his suggestions that she remains somewhere in safety while he goes on looking for the gang. She has chased after Jerry, followed him onto the train, and now stands at the door of his compartment. Holy smokes, how did you get on this train?  I have some new evidence. What evidence? Do you have Murphy's handcuffs? Yeah, here they are. Why? Well, I just remembered, there's something funny about them. Give them to me. Yeah. Look, when I snap one on your wrist, like this. And one on my wrist, like this. Well? And we can't get them off, can we? Hey, what are you driving at? This story is very important, and I'm going to see that I'm with you when you make the arrest.  Don't be mad, Jerry. I can help you. Really, I can. Because I'm the only one who can identify the murderer. Oh, you've seen him? No. But I know that he has a scar on his arm. Yeah? Yeah, a long scar that runs from his elbow to his wrist. I see. Yeah.  Yes, that's it. Exactly like the one you had there on your arm. See, but... Oh! It runs for the... It runs for the... Oh, you look... Ah! Ah, you would lose the key. Oh! Cold still, sister. You wouldn't appear. Okay. So now when I get these things off, you can make yourself comfortable here. It's hideout doesn't look very inviting. It was your idea, sister. Stop calling me sister, brother. Quiet. Ah. Now that those things are off, we can get down to business. Broderick! Ah, what's keeping a guy? Broderick! Yeah, yeah, here I am, Jerry. We have a friend here who's suffering from a painful curiosity. I think we ought to put her out of her misery. Do you think you can do a nice, clean job? Well, I ain't missed yet, have I? What do you mean? You've missed that newspaper guy, Phillips, four nights in a row. Ah, Jerry, that ain't my fault. No, he works late at night. I got to pass the time somehow, so as usual I have a few beers while I'm waiting. Then with him and his twin brother comes out. Him and his twin brother. Yeah, yeah. Now you get rid of this dame and then take care of Phillips, you understand? Okay, okay. Because if you don't take care of him tonight, I'm going to take care of you. Okay, okay. Come on, baby. Want to ride in the front seat with me? I'm not going to ride anywhere. Come on, babe, now come on. No, no, no, no, no, let me go. Ground all torn up. Ah, that's just a new grave. Cemetery is the safest place for this sort of thing. Now look, sweetheart, you just stand right over there. Oh, don't shoot me. Please, please don't. I'll do anything. I'll pay you. I can get money. No, no, I can't take no money. Well, I'll go away somewhere. Nobody will know the difference. You can tell them I'm dead. I'm sorry, sister. Come on, now. Be a good girl and get right over there. All right. That's it. Are you ready, there? That's good. Okay, now. One, two. Get over with me. I just can't hit nothing. All right, brother, dear, so you missed. Yeah. Let's call it off. After all, murder must be pretty monotonous for you. Why, when you've seen one, you've seen them all. Hey, peace boy, you can be side, you know. Jerry's the boss. Why? Huh? Why is he the boss? Why, anybody could see you're the brains of that outfit. Why, that guy's getting away with murder. Yeah. Yeah, he sure is. And after I kill you, I'm going to tell him a thing or two. Say, tell me, why does he want to kill you anyway? I know too much. I'm too smart for him. Yeah, you in the rackets, too? Ha! Am I in the rackets? Ever hear of Sadie Smith? You? You ain't Sadie, the Poison Queen. Hey, Dye. Hey, and Lucy Bogey, we got a racket. Broderick? Yeah? Together we could make such wonderful music. All we have to do is get Jerry out of the way and take over the mob. Hey, now, look, wouldn't that be something? You and me just take that easy and bossin' everybody around. Ha! Sadie, tell me something. Do you think you could ever learn to, you know, like a guy like me? Broderick, I've got great plans for you. That's so. Come on, let's go somewhere and celebrate. No, no, no, no, no. I gotta kill that Phillips guy somebody on my life won't be worth nickel. You mean to say you got a little thing like that spoiled our evening? Listen, I'll tell you what I'll do. I'll call Ken Phillips and have him meet us at the conga club. Oh, say, and then we'll do the job there, huh? Why not? Been thinkin' about murderin' him for a long time. Come on, let's find a telephone. Let me speak with Mr. Phillips. Ha! Oh, boy. Ain't this swell? A murderin' dancing all in the same night. Ken? What do you mean, yes, dear? I haven't told you who I am yet. Well, it's me. Now, don't ask any questions. Hurry right over to the conga club. There's somebody I want you to meet. Yes, a friend of mine. He's very clever.   Understand?  And when you come, bring along some C-O-P-S. Yes, C-O-P-S. Goodbye. What did you tell him? What's that stuff, that business, that C-O-P-S? Well, I just asked him to bring along some Jean-Dame. Oh, he don't have to bring nothin'. The drinks is on us. I've been here half an hour ago. I don't know what can be keeping him. You know, some people just got no consideration at all. Say, I still think you oughta let me. Oh, here he comes now. Dorothy, would you please explain the meaning of this? Why did you call me up and insist that I could? Ken, I want you to meet Broderick. He's the one I was telling you about. Yeah, sit down, buddy. Have a drink. Ah, give it to him, Sadie. Broderick has been waiting to get together with you for several days. But he's always missed you. He's missed you four times.  Huh? Yeah, have a drink, buddy. Have a drink. We got one all ready for you. All right, give it to him, Sadie. Sadie? Who's Sadie? What is this? Why did you say over the telephone?  Have a drink, buddy. Thank you, thank you. I need one. Ah, well, that's better. Now, Dorothy, for the last time, what is the... Ken, Ken, what's the matter, darling? Ken, dear, what happened? Tell me what happened. Well, that's over. Come on, let's dance. Well, I didn't put anything in his drink. I know, I know. She was taking so long, you see, I went ahead and poured some red poison in his glass. You what? And it's all my fault. I'll get you to a hospital. Now, what's the matter?  Help! Bunnyard, ma'am, what happened? You tell him, Broderick, hurry up, tell him. All right, all right, we poisoned the guy. We've been trying to shoot him all week, but... I gave him the red poison. We have to get him to a hospital and arrest that man. Arrest him. Quick, quick, you heard what she said. Arrest me, arrest me. No, Sadie, what are we doing?  He's a killer for liquidation incorporated. Okay, okay, lady, take him away, boys. Come on. No, wait a minute. Oh, Dorothy. Oh, Ken. A drink. Give me a drink. Of course, darling. Here you are. Drink it down. Yes, thank you. Ken, darling, you're going to be all right. The nurse said it was just like a bad stomach ache. To think I'd come to this drinking rat poison. Darling, it's no worse than a lot of the other stuff you drink. Ken, can you sit up? I want you to see the paper. Paper? We scooped the town. Broderick confessed last night and they've caught the whole gang. Look, here's a picture of them on the front page. With me pointing my finger at them. Oh, I love reporting crimes. From now on, I'm going to specialize in murder. Excuse me, ma'am, I'm from headquarters. Is this your picture here on the front page of the paper? Yes, that's me. I thought I recognized you. What is it, another murder? Yeah, a murder. I've been looking for you ever since you escaped last week. Escape? You mean you think I'm... You're under arrest. But I'm not, Sadie. Can't tell him who I am. You tell him. What's the matter with him? Oh, nothing. Nothing. I've just been poisoned. Poisoned? At it again, eh, Sadie? Now come along quietly. Can't do something. He thinks I'm Sadie. They'll put me in jail. They may even hang me. Well, don't just lie there grinning. Don't worry, darling. I'll drop by one of these days and get you out. Why, you... After I'm sure you're fed up with murder. Come on, Sadie, get going. I'll bring the minister when I come. Bye-bye, dear. All right. Oh, I don't tell him who I am. Let him think I'm Sadie. Let him think I'm the poison queen. But I'm warning you, Ken Phillips, when we get married, when we have our wedding supper, I wouldn't drink anything if I were you, brother. And there's our play, Dotty's Dilemma. In a moment, our star, Buff Cobb, will return for a curtain call. Now, here is Wendell Niles. Nurse Anesthetists. Did you know that you may be eligible for appointment in the Army Nurse Corps Reserve in the grade of captain? The requirements are seven years of professional nursing experience, one year practicing anesthesiology, and, of course, your certificate from the American Association of Nurse Anesthetists. A captain's base pay is $313.50 monthly plus subsistence allowance. Write for further details today to the Surgeon General, Department of the Army, Washington, 25 D.C. Now, once again, our star and our producer. Welcome back to the microphone, Buff Cobb. You made a very charming newspaper reporter. Thank you, C.P. I've enjoyed being here so much, and Granpappy always wanted me to be a reporter. I think this is as close as I'll get. Of course you mean Granpappy Cobb. Yes, Irvin Cobb was my grandfather, and as he started out to be a newspaper reporter, he always told me I should be one. Do you think you'll choose writing for a career? No, I think I'll stick to the movies in the stage. Oh. Well, I had written several articles for Vogue magazine, and I guess I'll continue to do so from time to time. There's one thing that you are gifted with, and that's the Irving S. Cobb's sense of humor. Everybody loved him, Buff. Oh, thank you, C.P. That's very sweet of you, and a great compliment to me. Now, Buff, suppose you tell us something about Paduca Kane-Tucky. Oh, no. My grandfather covered that little subject completely. I wouldn't attempt to talk about it. Won't you tell us just one little thing about Paduca? Yes, I love it. But I've got to be going. Goodbye, C.P. Goodbye, Buff. Hey, aren't you going to invite me back again? Why, of course, Buff. We'd love to have you any time. Well, thank you. But before I go, who is your star for next week? Next week, Buff, and ladies and gentlemen, the young and very popular Richard Long will join us as the star of an exciting story of a scientist, the magic darkness. This is the story of a man and woman, two scientists, who dedicate their lives to a single purpose and prove that when two elements have an affinity, they are difficult to separate. Be sure to join us. And now, until next week then, thanks for listening and cheeriole from Hollywood. Buff Cobb appeared through the courtesy of the Hollywood Coordinating Committee, which arranges for the appearance of all stars on this program. The script was by Robert Riley Crutcher in the music of Eddie Dunstead. This program is transcribed in Hollywood for release at this time. Wendell Niles speaking.


Alright, so I think since I'm being filmed, I'm going to kind of stay here completely. Which will be hard for me to do because I like to walk around and interact. I'll start, here's the plan today. I'm going to give a quick introduction of Adobe Systems. Most people are probably familiar with some Adobe products. But I'll give a little bit of background that's pertinent to how we develop software. I'll talk about the team that I worked on, the first strung team at Adobe, which is the audio team that's delivered the audio product of this channel. And then I'll talk about a little bit about how that story is starting to spread over the use of Adobe in my current role. So as far as Adobe, Adobe's product development lifecycle. So Adobe, as many of you might know, is a company that's really built on acquisitions. So we require many, many different companies to build the current company of Adobe. And because of that, they're very conscious of being respectful of the teams that they're acquiring of their own culture and their own development methodologies. And so Adobe has never, to this day, said, when you become part of Adobe, here's the lifecycle you need to follow. So what we have at Adobe is just the first set of groups all developing software and how they think it's best. And of course there is a little bit of cross-qualification that happens over time. But different groups can use different terminology and different life cycles. And it's an interesting problem. It has its benefits, of course, because then teams can come in and be immediately stuck with them and they don't feel like the big Adobe is trying to effectively do things. But Adobe's about 7,000 employees right now and making about $3 billion a year, doing primarily desktop software but also software services as well. Products like Photoshop, Acrobat, Flash, all pretty well-known products. Where I came into this was on the audio products, though. And my background was all in audio. So I'm going to talk a little bit about this team, which is the team that developed the first Scrum product. And so the history of that team goes all the way back to 1990 when we had one, the original, founder of Centrillion Software, who was at the time working for Microsoft doing C manufacturing, with me doing coding, but had a background in audio acoustics and wanted to write a PC audio editor. And so he wrote up this little shareware that he called CoolEdit and started asking for $5 donations. He was starting to get all these checks in, and he said it was annoying to take all those checks to bank. So he upped the price to $25 thinking the check flow would slow down, but the number of checks was about the same and they were just 45 times as much. So he decided he better incorporate and he formed this company called Centrillion. So, you know, throughout the years, various releases of CoolEdit and eventually Adobe, for their video business, was interested in acquiring an audio application to be a companion to their video editors. And I was working for Centrillion at the time that Adobe acquired Centrillion, so I was one of the acquisitions of Adobe. We had a couple releases of what became on Adobe Audition. It used to be called CoolEdit Pro and it became Adobe Audition as soon as Adobe bought it. And I worked on the product of the tester. Around the Audition 2.0 cycle, I became the program manager for Audition. And shortly after, I heard about Scrum. Since that time, Adobe, or that audio team has developed three major releases, all using Scrum as well as a few updates, and are still using Scrum on that. So let me talk a little bit about Audition 2.0. And this was the cycle that I became the program manager on. It's not in the middle of it. So there were a few issues that we were dealing with on this cycle. This was a major rewrite of both the back end, the facing engine to mix all the audio streams together and apply effects, all the fun stuff that you can do with an audio application, as well as we were reskinning the whole front end to make it look like we could do the application. Until then, we still had kind of the old user interface that we had developed as our little startup company. And we were making it look like the other applications in the video suites. And one of the issues that we had there is that the fundamental technology that we were relying on to make this new mix engine work really fast to where all of you who have turned a knob on a stereo, you expect that it's going to get louder immediately, not until you have to wait two seconds to hear it get louder, and we were experiencing problems like that. So we had to develop a new engine for that. The guy that was working on that had been with the company for a long time. Quite frankly, he was pretty burned out working on the product. All of our developers at that time were working from their homes, all of the testers were working in an office together. So it was an interesting environment we were working in at the time. But I'll call this developer, John, who was developing this really key feature, the underlying mix engine. John, this is the azio driver. The azio driver was the key thing that was going to allow us to do that real-time mixing. John had worked on all of our driver development up until that time. And the driver came in, gosh, I thought we had a milestone that we called Future Complete. It works like a beta milestone where we stopped working on new feature development. We just started fixing all the bugs that we built in the last, a very water-polished type of model at the time. John delivered that audio driver about two weeks before that Future Complete date. And he delivered pretty full of bugs at the time. And I remember as a tester, when this came in, I was pretty freaked out that we were going to have to try and get all these bugs fixed in the new engine. So we didn't have very much testing on prior to that Future Complete milestone. And we also had, you can see this is the actual bug curve of bugs that need to be fixed. This is open, two-fixed bugs, this is how we get the class button. This is the actual curve, shape of the curve. And you can see, you can guess where a feature complete happened, right? Right at the top of that mountain there. Because of that big mountain, it was a pretty rough end game. And we could barely meet our schedule as, you know, a newly acquired Adobe application. We had to ship at the same time as all the other products. So that was a new experience for us. So we barely made that. This bottom picture down here is, we found out, after the fact, you know, one of those times where somebody accidentally hit a fight of all, when they meant to play the fight of all firsts. We found out that John was spending quite a bit of time building this great new home theater. And he found out he was developing an active driver. So a few personality issues that we were dealing with as well. And of course, you know, John's manager was working with him to do a better job of those things. And I had a lot of success with that. So all these things were happening. And I was a new program manager at Adobe. And I remember going to, like, a brown bag lunchtime, hour-long presentation from Jeff, several hundred years. And Jeff was saying things like, you know, in Scrum, we develop things in priority order, feature priority order, or, you know, based on the customer or based on risk. And I remember thinking, oh, if we did that, an active driver would have been done in the first couple of months. That would have been great. And in Scrum, what we have is we have all the people on the team working together. And they meet once a day for a day in Scrum. And they answer questions like, what did you work on yesterday? And I'm like, wow. If John had answered what you were working on yesterday, what's he going to say? Well, I'm a new receiver, but that's true. And so I was pretty excited about hearing about Scrum. And it just seemed to really resonate with me as a better way to do things. So I read, you know, I read Cantalus and I got online and learned all I could about Scrum. And then I wrote up a little, you know, presentation to the other managers in my team saying, I think this is a good way to do things. And I think our next release, we should try this new development policy, this Scrum thing. They agreed, they, you know, with a few bumps along the way, but everybody finally agreed that, yeah, we're going to give this thing a shot. We got Bunyan from Art Direct executives directly over us to try this on the product. And so myself, the engineering manager, went to Kent's two-day Scrum training back in August of 2006. And then we brought in a local trainer, Alan Shalloway, who works at a company called NetObject, who used to train for the team with varying levels of success depending on who you talk to.  And I'm going to talk a little bit about some of the things that happened over the course of that cycle. I want to talk about a little bit the results that we had. There were four areas that really changed when we moved to Scrum. The first is in co-quality. The second one was in our ability to focus on what the customers really want. This, you know, kind of buzz-turned productivity, which I'll talk about, and then teamwork. So I'm going to talk about the results that we got over time. So the green line, you might remember that first curve, which is the Audition 2.0 cycle. The next curve is the cycle we used from. So you can see that we have about a third the number of bugs to fix over the cycle. Very similar release time. These are 18 months releases. So the Creator Suite all releases on these 18 months to two-year cycles. We were fitting into that time box. And you can see that, you know, we still had a little bit of a hill that we climbed. And it was a little bit of a self-consuming prophecy, because we said, well, we're trying this new thing, but we're not going to really modify these milestones like feature-complete. We're not going to, you know, what if this thing blows up? We don't want to have feature development up until the last month, and then it blows up and we don't have good quality. And so we built in this, what we call an end game. You know, we're the fixing bugs.  And we were saying we have these, you know, our bug counts, one third of what it's been in the same team size, but gosh, maybe we should, maybe we should let quality slip a little bit, get a few more features in this time, because what are we going to do in those five months? So it was a bit of a self-consuming prophecy that we had still a bit of a bug, but still, if you look at cycle-cycle improvement, way better. The customer focus area is, because we were at the anniversary sprint, we had complete features that we could show to customers. We were able to go out as opposed to private beta, you know, not the NEA signed beta testers that were able to use these features and give us feedback very early on on the direction of the product. But then we were also able to do a public beta. In fact, we had talked about doing a public beta release of this new software called SoundBlizz, which is another audio product targeted to producers. And originally in the planning phase of that project, we said, you know what, it's too risky. We don't know what the product's going to look like by that point. We don't know what the value is. So we had decided, both as a team and had executive buy-in, not to do it. Well, we got eight or nine months into it, and Adobe, for various reasons, which I go into if you want to ask later, but we're trying to impress us a little bit, Adobe said, you know what, we want you to do a public beta. In fact, we want you to have it ready for the Max conference, which is at three weeks. And I said, well, we had no plans on doing a public beta. And he said, yeah, I know, but we really need you to do one. And so, luckily, we were at the end of a sprint. And in fact, we were to go back to this bug curve. See that little peak right above 250 days? These are both back-day and commercial days. That little peak right there is where they asked us to do it. So we were at a very, very low bug count, and we had just finished the sprint. And so we said, well, gosh, should we do this? I think maybe we could. And this next sprint, we could say the goal for the sprint is to do a public beta, where they do all kinds of things like legal reviews and stuff like that. We're removing codecs where the empty free codec, Brown Hopper wants a lot of money anytime somebody downloads it. And for a free product, we said, well, that's probably another good idea, but we're getting Brown Hopper for a free product. So we removed the Brown Hopper codecs, things like that. But we were able to, within three weeks, turn that around and say, OK, here's your public beta build, and maybe get that up on left. If we were to look at the audition, same contract in an audition, if we had a request like that, no way could we have responded because of the bug count, number one. But number two, the features that we have were all these kind of half-developed things, right? It culminated in finding a feature plate where everything worked. No way would we have had something that was a cohesive set of features that we could have got feedback on. So we only go out and get that public feedback, which was extremely valuable to the team as well. I mentioned productivity. So this term end games, we'll call it during the war, we stop doing things like adding value, you know, new functionality, and start doing things like just fixing all the bugs we created. Over an 18-month cycle, the standard delta for us was five months of that. We've just been fixing bugs. And I mentioned that for the CS3 cycle, we said we're not going to alter that. We're going to say five months is what we're going to do, just in case this thing doesn't work. Well, we got to that feature plate data that you saw. We had one third bug count. And so as a management team, we were sitting at a table saying, what are we going to do? Should we just say, oh, well, we're going to fix bugs for five months, even though we don't have that many. We'll get it done earlier. We'll start working on the next release, which should be good. Most of us said, you know, we want to get more features into this product. Let's do that. But our very conservative QA manager on the team said, ah, I think that we've been doing these sprints where we're later focused on individual features. And we haven't really been focusing on the whole thing. He said, I think that when we get to feature complete, we're going to start these big workflow tests. And I thought we're going to turn up all kinds of bugs that we didn't see before. Now, most of the people on the team and the management have been playing with the application, and it felt pretty solid. And we were saying, really? I don't know if you agree, but we said, all right, here's our compromise. Let's do one sprint. And in that sprint, we'll all focus on regression testing, workflow testing, and let's see what happens. Maybe you're right. And the bug counts have been skyrocketed once we started doing lots of focus testing. And we were right. And this thing's really stable.  You can see that we did our feature fleet today. We did that first sprint of regression testing, and it actually started going down. It was, you know, as most of us expected. And so what we agreed to was let's add one more sprint then of feature development. So we rolled it to squeeze. We were doing four-week sprints. We were able to squeeze one more month of feature development out of that cycle above what we originally planned. For CS4, we were able to reduce that down to three months. And for the next version that we're currently working on, the plan is to do a two-month. So cycle over cycle, we're getting more and more time of actual feature development. So I mentioned that I wanted to tell a little bit of how the adoption went for us. And so I have three sprint burn down charts here to talk about. They tell a bit of a story, and then they talk about retrospectives a little bit, and how retrospectives were extremely powerful for our team in making this work for us. So this first sprint burn down, you can see some pretty tell-tale signs. First of all, the things flat-lining for the first two, three weeks of the sprint. And then at some point we say, gosh, I guess we're really not going to make it. You know, at this point, the team was still at the point where they're saying, I think we can do it. I think we can do it. You know, if we just really buckle down, we're going to get this stuff. We're going to get these tasks marked off, and we'll make it. And then finally, like a week before the review, you know, reality says, gosh, I guess we're not going to do it. And so, you know, we pulled a user story out of that sprint, put it back in the back, brought it to the area, brought it down. We're not going to get to that one this time. And try to get the rest of them done. And you can see that even doing that, deferring those things back into the product back, we still didn't quite make it. You can see there's still a little bit of work to do at the end of this. And almost certainly that little bit of work was test this, fix this bug, right?  So we had a retrospect at the end of this sprint. And what came out of that retrospect was this idea that, you know, if we're going to, if we're not, if we're overly committed for a sprint, number one, let's be more careful about what we commit to in the sprint. Let's maybe reduce our expectations a little bit. But number two, if we know three days into it, four days into a week into it, that we're not going to make it, let's put it back on the product, back on right then. Let's go to the product owner and say, this isn't going to make it. Put it back on the product, back on. And really focus on getting the rest of the stuff done so we can get down to zero in our sprint. So that was our plan for sprint number two. And you can see that there were a few points in there where the team said, well, we're committed to put that thing back on the product, back on. A couple of times they did that. And yet they still didn't quite make it down to zero at the end of the sprint. The team was pretty frustrated with this retrospective, this sprint date retrospective. They were saying, you know, we tried this thing. We thought it was going to work. It didn't work. You know, what do we do differently? And we started talking about how we do things on our team. A few issues came up. So sprint seven and eight are kind of represented by these little holes. Now, any set of feature development is going to go through a natural art. These are very, of course, abstract in person to this. But there's going to be some analysis, some coding, some testing. All these whatever the phases are, maybe some testing, some coding, depending on how it works. But on our team we were doing things like doing the design, then the coding, and then black box testing on the end of that. And there was this reluctance on the part of some of the developers to check things in until they were, you know, the whole thing was done, that whole feature for that sprint was done. Then I'll check it in because, and this was the reason I said, I don't want QA, writing bugs on stuff that's not done. So you can see right away there's a little bit of a trust issue already, communication issue. What we talked about was, hey, maybe what we should do is check in like every day, whatever progress you've made, check it in, and then talk to your tester or counterpart and say, hey, here's what I've done. Here's what's ready to be tested. You know, we're talking every day. Let's thank you for that meeting. And the testing guys are pretty, hey, we're not going to write bugs on stuff that you haven't done yet. Don't worry about that. That's in the past. We're working together here. And so instead of doing these big sets of features, we broke things down into very small pieces of functionality. From a UI standpoint, it might be something like, yeah, this little check box or from a back-up standpoint, it might be at the support for this sample rate for an audit process. Very small, little tiny increments of functionality. And those we get checked in and tested so that there were a much faster feedback loop. Also, you can see that as you do that, you have many more opportunities to say, this is the right amount of scope for this user story. Or is it this amount of scope? Which one actually solves the problem? As soon as we solve the problem, let's not do all those other details. I don't know if you've ever used Adobe products. You probably know they're way over-engineered. About Adobe guys standing there saying, yes, our products are way over-engineered. They do many more things than almost anybody needs. Not good at 80, 20 rule as Adobe. And so we said, let's just stop. Let's just stop doing those last two little bumps, maybe, if this thing is already solving the user story. And especially at the end of sprints, we could use that and say, you know what, we got three days left on the sprint. I could add support for this new thing, or I could stop, and we could actually get everything tested and all the bugs fixed for these last couple of days. And I'd see emails going out of this thing when you open it up. So this was our kind of discovery of the sprint red perspective. And so the mantra that came out of that was, as we're in the sprint planning meeting, for every little coding task, the question was going to be, and how are we going to test that? Because some of the things, we had one white box tester out of 10 testers and the rest were all black box. So they didn't have a lot of code expertise. These were people that had a lot of customer expertise. They knew what audience people wanted and they were verifying from that standpoint. And so we had to say, how am I going to test this? And our developers would have to say, oh, good question. I didn't talk about how you're going to test this in any subset of functionality. And so what really happened is the team kind of self-discovered test driven development. Because we had all those discussions in this sprint planning meeting and then throughout the sprint. Every time some new thing was going to come in, the thought popped up, okay, how are we going to test this? So we broke things down into much smaller increments and made them test driven. And you can see that the burn down for sprint nine was much better. You can see it's actually a much more natural curve and that it actually got down to zero. So this is just kind of a story of how our team retrospectives were really valuable to us. If we had hired somebody to come in and say, you know, I see that you're not getting done in sprints and I think test driven development is the solution to your problem, I'm going to train you. It's never going to happen, right? Everybody said, oh, yeah, sure. We're going to have a high pause while the team is down. The fact that the team self-discovered and came up on their own made it very powerful for the team. So that's kind of the story of SoundMove. That was the first release of SoundMove. Certainly didn't do everything right. The next burn down after sprint nine probably had more problems, you know, if I were to show all of them. But that was one small success on that team. At the end of that cycle, the kind of data that I was just showing you were reducing our regression testing time, were reducing our bug count significantly, were able to respond very quickly to what our executives want. Those stories started making around the company. There was a pretty grassroots kind of thing as far as development goes, as I mentioned before. There's nobody telling the teams how to do it. And so those stories started kind of getting around, you know, that, hey, here's a team that did it this way. In fact, I was studying a major review of the Creative Suite, because after I did SoundMove, I got a promotion to be the Group Program Manager for Creative Suite. So I went from this small agile team to the Creative Suite, which is 1,200 developers developing 14 major point products and trying to manage that process. It was like, you know, going from sprinting to running in molasses. It was an interesting experience personally. But right after that, these other teams, I was at this review, and the CEO was asking somebody, hey, can you go to Public Beta? Can you go to Public Beta and ask number of months? And the executive said, well, I don't think we can get there in time. I think it's going to take a system of months. And the CEO said, well, SoundMove did it. What were they using? And it kind of went down the chain. Yeah, Joe, what were they using? And it went down to the director. Yeah. What was it called, Peter? Scrump. Scrump, and it kind of went up back to the chain, and Bruce Jizz and the CEO kind of said, yeah, they're using Scrump. Why don't you look into that? So those stories started making their way around. And because I've been the Program Manager on that team, people started asking me, hey, can you tell us more about this scrump thing? And so I was getting a little presentation and power-winning slides and started talking about what we had done and what scrump is. And over time, in fact, over that CS4 release, I had more and more people asking about it. There was more interest in the company and what scrump could do for these teams. So we started bringing Ken Traver in to do two days, two days from master training. And he did five of those over the course of a year where it was really a whole situation where if I get enough people that were willing to pay Ken's fee, I'd organize it and we'd kick it off. And then I'd help Ken train because what we found was that Ken would come in and say, here's what my team calls the Dallas scrump. Here's the philosophy behind it. And teams would be very skeptical and say, I want to see how this could work at my company. And then if I stood up and said, and now here's how we did it at this company, then everybody would say, oh, I guess we could do it here. And then we'd kind of open the shackles a little bit and say, yeah, let's figure out how we could make this thing work for our team. So we brought Ken in and then at the end of the cycle, I moved into a full-time role of just training teams because there was so much demand. There was kind of this kind of demand. It's very expensive. I'm very cheap, relatively, for a W to hire. And so I moved into a full-time role of just coaching teams. And so I've been able to see kind of the roll-out of scrump at the company. And it's been completely appalled. There's been no push. And what we do, I work for a group called the Lobe Quality Initiative. And there's kind of different best practice people in that. There's somebody who's a big peer review advocate and can go on and talk about peer reviews of health teams. And that's all they do is they give examples of, you know, here's a team of these peer reviews and they were able to reduce their defects to 80 to 80 percent. And then people understood about it and they might bring them down and use some training. So things like peer reviews and there's a big TFB guy involved in that as well. And so it's really just a poll to say, are you interested in this stuff? Cool, we'll come and train on it. And over time our goal is to kind of just spread these best practices, things that work well with the company. So since that time I've trained a lot of teams in scrump, we're definitely following this standard tech adoption curve that Edward Rogers described, where today we're kind of in the early majority stages at Adobe where we have about 25 percent of the product development. And I think that number's probably bigger. If you've got a recorder, I sent out a big email last to say, hey, is your team using scrump?  I'm trying to gather some data. And I'm about to do that again. I'm pretty sure this number will go up. So some of the team sizes, the Lifecycle Team is one of the teams that uses the enterprise software to Lifecycle Team. It's probably the biggest scrump team in Adobe. They have about 300 developers across about 50 scrump teams. The audition team that I work on is about 20 developers. So you can see there's various team sizes, both dispersed, distributed. The example team was a distributed team, or we had a homeroom group of about 60 people and 14 in Seattle. We gave them their own chunk of stuff to work on. We're in the process of trying to tool up, you know, studying on different tools because I always get that question, oh, what tools do I use? So Adobe's actually worked on their own internal as well as lots of teams using, you know, the various tools that are out there. So I mentioned that earlier this year I sent out a scrump survey and I kind of had two goals of that survey. The first one is there's this big question being asked in the community, which is are you actually doing the agile? Are you actually doing scrump? And what does that mean? So I wanted to try and get a feel for, you know, when I hear, oh, such and such teams use scrump and Adobe, I kind of want to get a feel for what they actually need by that. I'll hear some teams doing that. It just means they're having stand-up very good and as far as they're concerned, that means they're doing scrump. And I hear some teams doing it and they're not doing anything like that and they have, you know, very many patrol structures in place.  And then number two, what effects that actually had on your team as far as bug counts, productivity, features that you're able to deliver to customers, how the team feels about it. You know, this is a good way to work. So there's kind of two parts to the survey that were going out. I send it out with no incentives.  We send out with no incentives. We base kind of the are you doing it on the no-kit test? Oh, this, I don't know. I have some of the questions on it. So we modified a little bit the no-kit test if you're familiar with that. And we have about 30 people respond and that's across 21 product teams. Almost all of them were in their first year scrum adoption. So it's a pretty skewed viewpoint of scrum. But here's some of the data that we found. These are the questions that, you know, how does this affect your team? So, you know, I would ask a question like, has the product quality improved since implementing Scrum on a scale of 1 to 10? Zero to 10? What do you think? That's the most, of course. And, you know, these are the initial results on the first pass of this. I'll be very curious if I can send this test out again. Later this month. I'll be very curious to see as these teams have now had another four months of development or sprint into the belts, whether the things are getting better on some teams or more on some teams, how things are going. The kind of no-kit test questions, which is, are you actually doing it? Some pretty poor numbers on here. A scale from zero to 10. So if you look on the no-kit test, you can figure out what these things actually mean.  And this, again, this seems in our first year. But out of 100, the average Adobe score, I thought, Aaron, you heard a lot of the average Adobe score, Adobe score is about 58.  So even though there are some issues with the implementation and with how things are going, the great majority of people still like the better way to work than what they were doing before. If I filter that set of results by teams who are just using it more than a year, it's a smaller sample size, so it's a great solving for that. But there's a much more positive, 100% of those people that responded said, yeah, keep doing the interestingly enough, the no-kit test scores are almost identical if you do the overall hold up. But the individual areas that they responded by were much different. So the teams that were doing it for the long run of the year had really high scores on things like self-management and product owner, those types of things. So if they had the vision, they were able to deliver on it. Maybe their sprint links were too long. Maybe other things were going wrong. Or wrong, I guess. Not following the by-the-look-scrum. But overall, those teams that have been doing it a long time were really positive. Of course, they're going to self-select out of that as well, because if they're having a really paid experience with it, they're going to stop doing Scrum and stop doing it on their surface. So they self-select out of that a little bit. But these are the results for how those teams felt Scrum had impacted these areas. So teams doing it long in the year felt the quality was much higher, that communication was better, that the overall product, the overall product is like, we deliver a better product for our customers. How does this affect our customers? Does my work life bounce better since you've done all those things pretty significantly higher? So we'll wrap up there. Any questions? In your stand-ups, do you have the development manager participate? If so, how do you get past the programmers feeling like they're being watched every day? I've seen both sides of that. So the question is, do we have managers participating in the daily Scrums in the stand-ups? And how do we get away from the command and control implications of that? So I've seen, since I worked on one team as a Scrum master for an eight-month cycle, and then I've coached many other teams, I've seen both. So on the audio team, we actually had our managers were just members of the Scrum team. They actually were, you know, delivering code, testing code, whatever their role was, admittedly had a much smaller contribution with the other one. And so they felt like they were vested. And those were also pretty good managers already as far as not being command and control people. So it's a personality thing that they were very successful doing that. Our engineering manager was very egalitarian, very open to ideas about how to do things, but also not afraid to say, hmm, what about this? You know, not afraid to give leadership where it was appropriate. So he was really good at balancing that. I have seen some teams that have gone to Scrum, their managers didn't want to be on the team like that, but they still wanted to be in the daily Scrum. And we had some issues on some teams where, you know, at the retrospectives, things like that would turn up, say, how come so-and-so QA manager is always telling me what to do at the end of the daily Scrum? And luckily those teams, or those managers, have been very open to that feedback in the retrospectives. I think it's helped to have me there as kind of an outsider that they can say, hey, is this the right way to do it? Or should we do it a different way? So having an outside perspective has been valuable, I think, there, so that people felt like they could go to somebody and say, why are they asking these questions? And I can say, hey, managers, remember when we said this is self-managing? You may be overstepping that a little bit. Yeah? You mentioned your team kind of discovered test-driven development along the process. Could you kind of explain what that was? Like was it Mormon acceptance testing, the unit testing, how many test-driven developments? How long this was accepted? Test-braining? And that's what actually dictated the development order of everything as opposed to the unit testing. We were developing unit tests at the same time, but that was not, that wasn't our goal as a community test-driven. Yeah, I have three roles of Scrum Master team and product owner. Which ones do you think were the most defined and were the most, and which ones do you think were the most problematic and didn't, in particular, interested in the product owner role, and maybe how that worked with Adobe? Okay, the question is the various Scrum roles, the three roles and how those were built with Adobe. The first two Scrum projects, my project and then another one that grew up out of a similar, in the same organization that they've heard about ours, both had just fabulous product owners. So we had a really good start. As it grew to many teams, what I saw was that not everybody had these great product managers that were really visionary and really good at communicating to the team what they wanted. And one of the things that's been mentioned in some of the other sessions is that the long-term vision can get view lost easily. And so I would see teams saying, well, we don't need to have user stories for the next sprint to find. That's all we need and we can start a new Scrum. And I would say, wait a minute, you don't know what your release is going to do and they would answer executive questions like, you know, when are you going to do that? When are you using Scrum?  And explain that, no, we actually do do product planning and, you know, portfolio planning in Scrum. And here's how it works, you know, down, you can use micro-homes planning on you, right, in the various levels of planning. So that was an area that there were some bumps along the road once we started to scale up to a broad set of product owners, instead of the lucky few that we started with where we got like, you know, had the right strategies on foot. Other questions? Great. Thank you very much.


And as my Dury and Christen faithful join their counterpart across the globe to still celebrate Christmas, which is the birth of the savior to the world, Christians have been admonished to emulate and reflect on the teachings of Jesus, which is the virtues of love, peace, and unity with one another in the country. The senior pastor of the church, Reverend James Moore, says, Christmas is for sober reflection for Christians to imbibe good leadership style of Jesus and reflect it on humanity, stressing the need to be ambassador of peace to all, irrespective of religion and ethnicity. He had government to put on people's cut-centered oriented programs to alleviate plight of the masses. The reason for the world is that we should serve as peace ambassadors because Jesus Christ came as the prince of peace, and therefore because he came and we are his own followers, we also need to imitate him by being peacekeepers. Let us reflect the grace of God upon our lives, and also let us reflect the peace that Jesus has brought unto us so that we live at peace with one another, that through us as Christians, the world would experience peace. The reason for the world is that God will help our leaders, that they would show human feelings upon the people. And in terms of formating their policies, they should be considerate. They should have the masses at the back of their minds, so that in form in making their own policies, their policies will go about helping the people to enjoy the dividend of the people. Some of the worshipers expressed their light for seeing great day like this, and adding that unity and peace is what Nigeria needs amidst difficult challenges. Jesus came to give us life and life in abundance. Today, Jesus, we are celebrating the peace that Jesus came and brought to the world. So my prayer for Nigeria is for the peace that Jesus brought to the world, to go all over the country. I pray for peace for the country and joy that Christ brought during his birth. Day of joy. So we have to celebrate it joyfully in Nigeria in order to live peacefully with one another. Peace to show love that you have shared with other people, that will bring people closer to God. And that will make people to know that yes, the real crisis is going to be. While others say Nigerians must show tribalism, ethnicity, difference by embracing love and peace as it is the only key to development. The expression of joy, affection coming from everyone who bring from the houses, in order to bring it to short and then share, that is the sign of love. But that is what I feel to that love and affection. See it in Nigeria is God. The issue of religious clashes, religious fanaticism and tribalism are all some kind of belief to be stopped and let's come together and join us as one and come together and then let's bring that love inside of us. So I believe that with us bringing that love inside of us will make us more stronger and the bond between us will be more stronger than any other thing.


yeah hello hello this is the one that we have for the umbrella chipset and can we look around with a touchscreen yeah that's okay so how much is a price on that one 86 yeah for moq big big right you don't have 4k 60 yet right not yet not yet all right cool thank you


Well, fellow RTC enthusiasts, we've got Oleg here who's going to tell us about SIP-3 which is not the new iteration of the SIP protocol. It is a VoIP travel shooting tool. Yep, take it away. Okay, hello everybody, my name is Oleg and I'm a CTO at SIP-3. As you know, it's a company doing VoIP travel shooting and monitoring. We don't have much time, that's why I decided to spend it answering the most frequently asked questions about the platform and give you a quick overview of all the new features we have in new release. And the very first question is like, what is SIP-3? So SIP-3 is a monitoring and travel shooting platform which works with different traffic coming from voice or IP network. It might be, in most of the cases, it's a copy of SIP and RTP traffic and also it might be different CDRs and other protocols coming to our platform. Who needs it? Every company which works with voice or IP can benefit using SIP-3. It might be either mobile operators with their IMS network or C-pass providers. So we have different cases with different companies starting from the companies using like a bar metal machine to companies deeply in clouds with infrastructure as a code project. But within the company SIP-3 might be useful for really all departments, I mean technical departments. It might be NOC, it might be support team, it might be R&D and also it might be businesses. And in most of the cases actually SIP-3 is like a breach. You can build all your processes within the company around SIP-3, just attaching links or pickup files or everything to the tickets in Giro or whatever system you use. Now let's talk about how it looks like and how it works. Unfortunately I can't show you demo in these 15 minutes, it's like not enough time. I will show you mostly screenshots. First thing we want to know, I mean why do we need voice or IP troubleshooting and monitoring? Just because we want to find any, literally any call in entire amount of data we have. And sometimes you have like a big amount of data and Fire Shark can't help us there. Even though engineers they like Fire Shark, that's why in SIP-3 we do troubleshooting and we have a search engine. Which actually looks like Fire Shark filter line. So you can see that you can specify the range of date and time. And you can say that I want to search this call by this for instance callee and IP address. So it's pretty simple and similar to what we have in Fire Shark. Now I briefly tell you about new features of new release. This is a simple JavaScript but very useful history of search. Now you can search in SIP-3 and get back two steps back and to keep digging into your problems. Also previously we had only equals as operator as a criteria of search. Now we have below, greater and not equal. And by introducing these operators we introduced new criterias like call duration or even more interesting and sensitive things like call setup time, call established time, call disconnect time. All these things now you can use as a criteria of search. So basically here is the list of for instance SIP criterias. By default you can search by state, call ID, caller, callee, all these times and some other criterias. But one of the most interesting features of new release is custom attributes. So basically you can assign your own attribute to your call based on different things. I will explain a bit later but you can search by custom attributes.  You can do SIP analysis and in terms of SIP analysis we have call flow where you can see correlated call legs and information about each of the messages of these call labs. And also we have a pretty nice new feature which is RTP analysis. This is a brand new feature of SIP3 where you can see quality of the call during the entire call. As you can see here we have a caller with perfect R-factor which is like 92.5 which is perfect for this codec. And we have caller who has some problems and we can see at what time of the call he had these problems, how many packets were lost during this period of time like call setup during the call ending and so on. Also you can switch between RTP switches and see the same data from RTP data. So also everything here can be represented by each of media legs. So basically you can see let's say how your call pass through all the nodes. The second part of SIP3 project is monitoring. When you are able to find whatever call you want to find you need to have some kind of an overall picture and to realize that okay I have a problem with call duration for instance or with ISR or with some other matrix. We don't have lots of cancelled calls or failed. So basically monitoring and SIP3 ships by default SIP3 ships the platform with embedded Grafana. So you can customize and build your own dashboards. This is an example of SIP dashboard. This is an example of RTP dashboard where you can see like expected lost packets and R-factor per codec or whatever you want. And R-factor as a heat map is a very useful thing. So I strongly recommend you to build some such type of charts if you want to monitor your RTP data. So just to give you a quick overview what do we have in terms of amount of matrix. For SIP for instance, for SIP calls even. You can have like generic matrix like messages, attempts, duration. You can have all the delays. You can have amount of sessions which are approaching at the moment and which are established like concurrent sessions. For RTP you can see all the required quality of service matrix as well. But that's not all. You can query each of these matrix using different dimensions. For instance if we take SIP call attempts you can query this matrix using source and destination hosts. You can query them using states, error codes, error types. You can query them using like call attempts related stuff like retransmits during the SIP transaction. Or you can find expired calls and you can query them using custom attributes. And by custom attributes we can... I mean it's whatever you can find in your SIP or RTP data. For instance in many platforms there are custom reason codes. There are custom reason codes which you can use and monitor. So basically you can define this reason code and query SIP call attempts by them. Or by operation system or application version if you are using mobile application. Now let's talk about what are the advantages of SIP3. The first one is performance because from the very beginning we worked on highly scalable system which capable to handle tons of traffic. And for instance our latest benchmarks shows that on one single server we can handle 50k SIP messages per second and more than 1 million RTP messages per second. And this is only one server and this is entirely scalable architecture but performance talk was the entire presentation. I can put it in 15 minutes. The second advantage is customizations. And I told you a couple of times already about user defined attributes. Now let me tell you what it is. As you know in Kamalio Open SIPs and other projects we have really flexible engines to customize your business logic. We have the same SIP protocol for instance but at the same time we can put some extra headers into SIP messages which actually in these headers they will be responsible for business logic. So in SIP3 we decided that if you want to give people the better experience working with all these systems with custom protocols and custom attributes and headers you need to introduce the same thing. So in SIP3 now starting new version you can write your own user defined functions in Groovy or JavaScript where you can just analyze SIP messages. For instance as an example here we all know that all the calls from number 100 is a robocalls or like internet test call and you can assign an attribute and say okay this is robocall and then you can get back to search and you can search by this attribute SIP.robocall true. You can see all your calls from robots. Or the same thing you can apply to monitoring and to monitoring Grafana. Another thing which might be useful in terms of user defined functions is the way to correlate call legs because SIP3 correlates call legs using caller and cally and very often we have situations for instance when there is a US number in international format and US number in national format after let's say PBX. So what we can do we can just match these numbers again analyze SIP message and we can reassign caller attribute which is service attribute and to make these numbers like in international or national format and now SIP3 can correlate all your calls and messages. Another very important thing and cool feature of user defined functions is integrations. Now we have an information about call. We can use this information to send it to third party systems for instance notifications to Slack or we can integrate it with your product console so when you can actually grab information from SIP3 in your product console all this can be easily done with this new user defined functions thing. Also in SIP3 we are very few people that's why it's absolutely not normal to develop everything from scratch and to try to reinvade bicycles that's why we like to delegate. So in terms of monitoring we delegate it to all the modern and cool systems like for instance by default we provide SIP3 with influx DB and Grafana but you can choose whatever you want. For instance if your company you already have Datadoc you can send data from SIP3 to Datadoc or you can send data from SIP3 to Prometheus or Elasticsearch everything is possible. So the next question, do we have a free version? A year ago when I presented at FOSDOM we actually didn't have code on GitHub and now I can tell you that we have almost all our models on GitHub two of them are 100% open sourced and two of them will be open sourced during this year so if you want just check it out if you want to be part of our community please join. So also we have not only free version we have an enterprise and the next question is what is the difference between community and enterprise? Okay, perfect. So what is the difference between community and enterprise and the first very main thing is that in community version we don't provide RTP analysis at the moment we provide only RTCP if we talk about media quality of service but also in enterprise version mostly we provide support because systems like SIP3 they are not that easy to set up and sometimes you just need some help which we always ready to give you in our community channels but at the same time we can provide support. How to try SIP3? On our GitHub we have SIP3 Ansible project which you can just pull and deploy a new version of SIP3 which I released yesterday. So also you can join our community since like in Telegram you can find the links on our GitHub as well you can follow me in Twitter and our accounts as well we will be always happy to help you. Thank you. Right on. We have time for a question. Would you like to ask anything? What's the instrumentation? How SIP3 gathers this data? Ingest SIP packets or whatever? Sorry again. Can you repeat it? How the data comes into SIP3? You have some agent or whatever? Yeah, we have a SIP3 container, it's an agent or also it can be used as a standalone server where you can just span traffic from your... like a copy of traffic from your network. So you just receive a real SIP packet? Yes. We support SIP3 so you can send it directly to our back end as well we support the moment only SIP I guess but we just... we develop features by demand and so far... And I think that also all the people want to know if you have time a little bit more between the difference between the open source version and the enterprise version. What is RTP analysis and what else? RTP analysis and support at the moment. Yep. That's an answer. Thanks a lot Oleg. Thank you guys.


Hi everyone, Joe for Jaspy's casebreaks.com coming at you with a random number block randomizer for this group of teams right here Which helps unlock pick your team number one That's how the number blocks work. If you're not familiar with it big. Thanks this group here Thanks to the people who bought their spots straight up. Congrats again to the people one spots in the filler And there are the numbers right there. Let's roll it. Let's randomize it three and a five eight times each one two three four five and Three six seven and eighth in final time We've got Steven down to Carl three and a five eight times for the numbers one two three four five six Seven and eighth in final time After eight we got three down to four All right, so Steven flat with three hon with six Carl with nine Chris with seven Steven flat with five Gretchen with two Carl with one Steven P with zero remember Steven Zero gets you any and all redemptions for that group of teams down there Including one of one redemptions as it says in the description Carl You'll still get live one of ones Carl with eight and four Let's sort by column a or a through z that is numerically and We'll see you in the next video for the break Jasper's case breaks calm