 Hello, I'm Philipp Mayer, I'm working for this Macomb a bit less than a year now. I will show you how to use the Osmo Zip connector. Whoops, what is this on my laptop? I see the slide, but I don't know what happened. The laptop shows the slide, but the beam is probably not the digital stuff on the display board. Yeah, anyway, the project is around for about a year now, and basically what it does is adds a Zip trunk interface to Osmo NITP, so respectively in future to the Osmo BSC. The BSC MSC split is not fully done yet, but things are on the way. So by using the software, we can connect Osmo NITP to a voice of IP PBX. And yeah, it's not the case that it haven't been possible before. It was possible before using the LCR software, that's the Linux core outer, but the setup for that was a lot more complicated. I remember back in the days when I spent my first months getting all the open BSC, that was with the BS11 back in the days. It took me a month to get that running, but it took me even more time to get the LCR running. It was a really complicated thing, so I'm happy to introduce the Osmo Zip connector today, which makes things a lot easier. So again, the laptop shows the slide, but yeah. Okay, so there we have it. That's an overview of an average Osmo network with Osmo components. That's basically how you would set it up. Of course, you have the BTS and I have to mention this graph doesn't cover the old-fashioned E1 protocols. The talk only focuses off of an all IP network. That's important to know because voice traffic would be handled differently on an E1 line, of course. So the BTS is connected to Osmo NITP and then it would connect to some intermediate layer back in the days that was the LCR. That would connect to Asterisk, for example. That's only an example. It would work with any PBX software. We want to replace these huge LCR, but it also offers a lot of features we don't really need. Of course, if we have already, if you need ICN features and we have used it already, it's not a good option to replace it. But if you are only interested in having the wipe support in Osmo NITP, there's a lot of clutter we don't really need. I remember I had to configure call routes here and all the stuff that's not no longer needed. So we just put basically a simple component there which is the Osmo SIP connector. We have a closer look to this in the next slide. This slide I don't show how the voice traffic is routed. It's of course in an all IP network that will be RTP. Let's have a closer look to how things work. Here I shown the BTS, of course, and then we have the Osmo NITP and the Osmo SIP connector. They both are connected using a mobile network call-controlled sort of protocol. In reality, it's only primitives. The primitives are well-defined. But of course how you implement the primitives up to you. That's a connection that happens over UNIX domain sockets. They both have to be on the same machine. But since this is a very light byte component, it's no problem to do that. That's one thing left, which is important to mention. The call control, so the way how the call is handled is already implemented in Osmo NITP. We abandoned the call control implemented here. We just turned it off and used the call control stack implemented there. Then at the output, so to say, we have a real SIP trunk that carries all the signaling traffic, including the DTM-F tone. There's something special to have the DTM-F tone handling. As you can see, the Osmo SIP connector is only connected inside the signaling traffic. It doesn't even see the RTP voice. If you want to inject or handle DTM-F tones, you would have to look and process them into the RTP system. It uses SIP info messages, which is standardized by some RFC from Kaplan. I don't know the exact number, but anyway. That's important. The Osmo SIP connector has no ability to process any RTP system or alter the voice traffic. The SIP trunk has no authentication implemented, so when using it, there has to be a bit of care applied to security considerations. Of course, you don't have to put that on the internet somewhere. Of course, everything is happening via TCP-IP. The RTP voice stream, as I said, contains all the voice traffic here. It's tapped directly at the BTS. Usually, an RTP stream is routed from the origin to the very end, or there may be RTPs in-between in the simple graphic origins at the BTS and is then routed to the PBX or other end, whatever that is. It's important to know here there's no transcoding happened. I mean, there's no component here in that stream whatsoever, so no transcoding is happening. It's just the encoding as you would have it on the interface as well, so that it's a good thing and a bad thing at the same time. You get the undiluted RTP stream and can process how you want, but also your PBX software has to support it, of course, or you're called party. Maybe the PBX has to do some transcoding and has to support the codex use on the interface. Of course, it's UDP. You already know that for sure. The Osmo ZIP connector is basically acting as a translating entity between the MNCC protocol and between ZIP. When the call control is processed in here, at the same time it interacts with the ZIP trunk, basically translates the behavior on the classic GSM call control site to the ZIP trunk web site. There's one thing left I wanted to point out. Some of you might already have some experience with OpenBTS. There's some difference. The OpenBTS software is more behaving like a VoIP phone. In this particular setup, we have a ZIP trunk, so that might lead to some confusion if you configure wrongly your PBX software. You have to configure a ZIP trunk interface at the PBX and route your numbers. By the way, the authentication still stays as it is. In terms of authentication that still happens here, it's still the classic interface with the HLR and stuff. Let's have a look at the configuration. Even if it's very simple, we can go through that. The first thing you have to do on the Osmo ZIP site is to disable the internal call control and basically hand all things over to the Osmo ZIP connector. Here, I have a sample command line. For sure, you already know the stuff past the config file, which I don't touch, by the way. The config file of the Osmo ZIP completely remains untouched. It's really just this command line switch here, the M. You can also use the smaller letter M, but that's deprecated. With the capital M, you have to apply past to your UNIX domain sockets. That's your interface between the Osmo ZIP connector. Here, that's a config file snippet for the Osmo ZIP connector itself. We are already there. Of course, not much to configure. You just set up the past as UNIX domain socket. By the way, by picking different pastes there, you could also have different instances in parallel. The next thing is, apart from the UNIX domain sockets, you just configure IP address at the port. Important here is, and that's very important, you normally have Osmo ZIP connector, Osmo NITP and your PBX, which might be access or something else, on the same machine. You might think, I just put the local host IP address, but that wouldn't work because these IP addresses are also used to negotiate the RTP traffic. In most cases, most setups will be outside of your machine. I have setups where I can run the Osmo BTS software on my local host as well. Then I can put the local host there. Just to keep that in mind, you use the IP address of your machine that is also reachable from outside for the RTP stream. You have a remote and local IP address. In this case, they are the same. If your PBX were at some remote location, of course, you would have some different IPs there. Then you simply start it. The minus C, I think that's common with all Osmo products, is always for the config file. It should have some standard name, which I don't know. I usually do it that way. Once you start it, basically it doesn't matter in which order you started. You just start the Osmo ZIP connector and see NITP. They will find it negotiated each other via the UNIX domain socket and will negotiate with the PBX software. Then you should be able to make calls just as normal. Then you have it, your network in the box with Wipe backhaul, so to say. There's the detailed information in the Internet, how to, with sample configuration files. You find that for downloading at our wiki. The path is a bit longer, but I'm sure the slides are handed out afterwards anyway. You also find it with Google when you Google for Osmo ZIP connectors and you will immediately point it to the how to and that in detail explains with sample configuration files how to set it up. It's really not too difficult. I was very happy that the burden of LCR was taken from me and I have a simple component now to use. That's it. Other questions? My question is, when you use the Osmo ZIP connector and you point it to something like asterisk, a few things. One, the registration is still maintained, like a registration of valid peers is still maintained exclusively by the NITP. Then the other question is, does it present, it presents to asterisks not with any registration request just with peers? It just is a peer interface. It basically just says here's the call to something with send and then goes up into your diet plan whatever and the call gets connected. Yeah, who was next? On the slide you showed ZIP over TCP. Is it ZIP over TCP or ZIP over UDP? It's over TCP. UDP or TCP? Sorry, it's TCP IP. UDP? No, the RTP stream is UDP. ZIP still remains What? It's UDP. ZIP is UDP? Oh, sorry, I confused the two. Yeah, as perspective it can be both, but I think we're using UDP only, like most people. Yeah. Hello, can you support SMS? So convert ZIP simple to SMS? Oh, I must confess that I don't know if that will make it to the through the Osmo ZIP connector as well. I think not. I think that's still delivered within it be and we see mobile snitching center in a classic way. Yeah, indeed we have an S we already have an external interface for for handling handling SMS and that's SMPP. So there was no need to have yet another interface for SMS. So I mean, if you wanted to do SMS over SIP, I would I would recommend rather to go the route to to gate to either directly interface with SMPP or to then try to translate the SMPP into into SIP again by an external component, but it is already exposed in some way. But okay, there was a Keith next and then Alexander over there. Yeah, so I've done that. I have that working SIP simple to SMS gateway. With free switch chat plan. But so my question was about the Osmo NITB RTP proxy mode, which I think is capital P switch that when you implement that is that how does that operating in this way with in relation to the RTP stream UDP directly from the BTS to your SIP. So your PBX because this is something is still not quite clear to me that's not operating then. So there isn't audio going through the NITB. I don't know exactly that I didn't use this option before maybe Howard can say more. The expert. Hi. No, it goes directly from the BTS to the PBX. Okay, as I expected. What happens if you enable the RTP proxy? That will be just ignored because the the MNC interfaces are used to establish your RTP socket and it's implemented in a way that it just forwards it to IP based base stations. So if you ever want to add E1 base stations to use the Osmo sub connector, we would probably then use the RTP proxy to to map trial to to RTP first. But for the current use case, it should go directly from the BTS to the PBX. Yeah, one missing part of the sample Osmo sub connector is the concept of hand over or actually it's left to the PBX to either discover changes in RTP source IP, source address, source identifier, or we need to have a re-invite which is not implemented yet. So yeah, one more thing which is not yet implemented in Osmo SIP connector just as a warning to to the users is that the hold feature is a hold call feature is not implemented yet because it also requires a C pre-invite to which I think is also in to do least I hope. And in one more correction to the slide previously, if you could go back to the screen we were to the diagram with oops to with LCR. That's the very beginning. Yeah, one more. Okay. Yeah, so basically it's here. So it's here you mentioned that it's connected to Asterix we are via Chan LCR, which is the hard way to do that. And I'm not sure it's even supported like it's been supported anymore or anything like this and the easier way is to do exactly as you do with Osmo SIP connector. So basically you use LCR as a bridge between MNCC and a SIP trunk and in this case configuration is actually really simple. It's just couple lines in the configuration and I think I think it's published on the wiki. If not, it's you can publish it. It's just few lines of configuration. It's universal. It's not it's not complicated. The most complicated part is compiling LCR, which is okay. Just again, just from practical perspective. Because we are still using LCR because we need the call hold and some other features which LCR supports. Hi, so you mentioned that there is no transcoding done the audio stream is passed directly. Is there support for AMR and dynamically changing the codec depending on the channel condition and stuff like that? Oh, I don't already know that. Probably it has to be supported by the other party because it's not Osmo SIP connector doesn't see the RTP stream anyway. So if there are some changes, it would be up to the other party to handle that. Yeah, so basically changes in AMR modes are done inside the RTP stream. And on this on the SIP side, you only announce supported modes. So and then it's up to RTP stream to so it's up to the headers in AMR packet to announce which mode is used for this specific packet. So you don't have to do anything on SIP side to enable this. That said, I don't think Osmo come right now supports dynamic AMR change. I'm not sure. It does? Okay. So one reason to replace LCR was not only that like the classic ISDN interface is difficult, but we saw severe reliability issues in the field. So after a day, it stopped working connecting calls and in other parts. And we also didn't want to do busy polling for for the sockets, but be more efficient. So we wrote the simple utility and of course for call holding or conference calls patches are more than welcome. The other part for AMR here, it's not supported in a way that you could make really good use of it. So it starts with the radio interface where you have your multirate configuration sent to the device with hysteresis of when to switch codes, codecs on the BTS itself. That's something we probably send, but don't really configure correctly or don't implement correctly in the Osmo BTS also for the SIP part. Yes, there is the initial mode, there is the mode set. But if you look at all other PBX with AMR, they're severely limited in what you could do with AMR and what actually works or who actually looks at the STP file. So we're probably in the same class of doing a sloppy job there, but it gets us far enough. Okay, yeah, there's a question still. Ah, there's one more back there. Okay, because we again running out of time. So this will be the last question now. Sorry. So we switched over to using Osmo SIP connector and we've been seeing that some phones can negotiate early media, but others can't. So we're wondering how that's supported and yeah, we're wondering how you can implement early media support. Yeah, maybe Holger can say something more about this. So in fact, we didn't support it until recently. I don't know if you've updated recently. A few weeks could be okay. One of the issues like when to connect the audio and when actually the BTS is receiving parts. So there was a behavior difference between Osmo BTS and classic Nano BTS of when it would receive data from a socket. So in theory for the RTP handling, you can have like sent only receive only or sent and receive. And the way receive only was implemented in Osmo BTS didn't allow for audio to be received, but there's a workaround in Osmo SIP connector and I plan to make it more proper in Osmo BTS. Okay, but basically you don't know anything about phone specifically as it was normal. Okay, yeah, okay. Yeah, again, sorry. We have to move on to the next talk. Thank you for the talk.