 Yeah, my talks about mgcp and how Where we use it in osmo-com the talk is it's a net is it's two talks. I just it's split it into two talks, but Yeah, the topic is very very close change together Yeah, the mgcp Protocol Yeah, be nice if I could Move some hope forward that doesn't work Such a crap software, I'm sorry. Oh, yeah. Yeah, I hope we can cut that out Yeah, it's about the mgcp protocol and after that we I will show you some practical applications How we are utilizing that protocol? I'm not sure How familiar you are with mgcp, but if you ever have used the split as the osmo-psc split plan Just you you already had have some experience with it because the osmo-mgw or the osmo-mgm the osmo Bsc mgcp is Manatories there, so we need to switch the voice stream somehow mgcp stands for media gateway control protocol And there are some success losses I looked it up. It's the s Gcp and the IPTC and as you can see there, it's Cisco and bad core and level three that are as the three major figures in there who Basically where the driving force behind that and yeah, it became an ITF standard in 2003 So it's not exactly a very old protocol. So it's already appeared in the zero years You know the SM protocol the protocols use in the GSM, especially in 2g are much older, of course Yeah, and also mgcp includes Another protocol which is the STP also have these STP messages in SIP So you already might know that So this is basically an extension to the to the mgcp to describe the session further So they didn't intend a new protocol that I just included that So the intended use of mgcp is switching but also media conversion and Transcoding at least what that's what has happened since I see media gateway the classic Classic thing where mgcp we would use mgcp is you would have some media gateway and that's That's Yeah, so you have to take some by the word it's a it's a gateway that converts the RTP an ITP stream to let's say an E1 line or or an analog phone line and You would send your mgcp messages there set up the connection and then your RTP stream would be routed over pots We use it a little different Not very classic. We have RTP streams Everywhere at the moment at least Yeah, and of course If you use RTP with different codex you would need to require transcoding which is not yet implemented, but it's planned feature and Also the media conversion in the sense of converting something to completely different media like E1 is also a planned feature Yeah So mgcp is a Text-based protocol. It's made up pretty simple You see at the at the right is some example for an mgcp request as it would show up in wire shark and at the I Really have support pointer here. So that's how is he how it would look like on the wire. So The pretty simple ASCII text, but you have to pay a little attention about the line breaks That's specified so you don't have to must not use any Arbitrary line break Combinations, but yeah, that's how it looks like on the wire. It's basically When I when I did my first experiments with that I did I Just made up a text file and use netcat and piped it down there and that That would already work to control the media. Get off course. They are as you go through later There are more comfortable ways to do that Yeah, it's request response Oriented Which means basically you you send in a response and you send in a request and and you get a response to that So there's a fixed role. So you have you have a client or also it's also called a call agent That requests something at the mgw. Do's make that connection Modify the connection delete that connection and then you get responses Yeah, and it runs on UDP power 24 27 that Yeah Mgcp messages are Basically begin sort of with with the command word and And some other stuff if you later to see later, but there are a variety of command words available and In in our setups we use only three of them, which are basically the three most important is just create a connection Modifier connection and delete the connection again. And so of course there are Also other so for example the audit endpoint, which could be quite interesting if you want to request the The properties of what you have set up there, but we don't need that at the moment. I think that's my mgw Would respond to that but not very wearables. I think And this is basically what happens inside our mgw When the connection is fully set up You have basically an endpoint it's important to know and in a media gateway always Always consists of in series of endpoints if if you would have the classic setup with your Pots lines, for example, you would have if you have a maybe I was ten pots lines For example, you would have ten endpoints then Of course as we are in all in an all RTP setup, it's this is somehow more virtualized So we could have an arbitrary configurable number of endpoints here and Each endpoint has these these descriptions is basically this pass here RTP bridge sets our our series of RTP endpoints We plan also have to run endpoints in the future and there of course the path would look a little different and the other the The well behind see at this basically an identifier for the mgw itself Yeah, one on that endpoint you create connection it's two of them you basically have You do your CR six your create connection command and correct Set up the first connection then you set up the second connection and they implicitly find each other if they are connected on the same endpoint So if you want to route an RTP stream you have to create Two connections on one endpoint and they will find each other and route your RTP stream through It's basically the the model we implement on our media gateway there Yeah Let's look a bit at at a request response example of of an MGCP request Yeah So here this create connection commands is CR six Which which creates a connection it also gets a transaction ID that's That's nothing That's just a counter which basically that makes At some unique with makes your message distinguishable from recent so it's gives your Message a Distinguishable number which basically just increments, but more importantly we have these endpoint description here again RTP bridge Slash zero and this basically Means that we have selected endpoint number zero here Yeah, and we also specify a call ID This call ID thing is basically to make calls distinguishable It's technically not so important more like to add some plausibility so if you Create a call with this quality to and if you want to modify the call again with quality three The media gate we should say that's not okay. It's an error So each call gets an ID and We specify that if this is the first connection we create and we set the quality to two We have to keep that until the connection ends And yeah here we set up some a laser pointer would be Much better, I think but they don't have one Yeah, here's the codec set up my talk is more focused on the switching aspect rather than the codec and transcoding aspect as I have Delta so far with connection the most Yeah, basically what it says, it's just create a connection with 20 milliseconds interval Packetization interval codec should be RMR and it should be a send receive connection So it's not a loopback connection here. So it's in a sent receive mode. So And we also give it a we attach an STP Futter here Which specifies On which port and IP we expect the MGW to to send the RTP data to us. So that's basically in that situation we already Reserved support on our side and we want to tell that to the MGW so it can forward its RTP data to us Yeah, basically that means yeah, I'm listening I am listening on 127.0.018,000 Please send all your RTP information to me there Yeah, next slide And of course we get a response to that and in this case we got a 200 which means everything was fine the request was fulfilled. So it's basically a HTTP error codes very very similar and we got this this is an connection identifier we get from the MGW It's on the MGW's behalf to assign a connection identifier to to us so that we can later if you do a modify connection if you want to delete it So that we can reference to the connection Yeah So that's basically it it says yeah, well, I will fulfill your request Here's your connection identifier and I am listening on 127 4004 For incoming RTP data. So the MGW the MGW now tells us where it expects us to send RTP data So then we have one side fully set up and site is basically ready to receive some RTP data But of course we would need a second connection. Of course, this is only an example for a single request. So if you just assume that Message like this a request response like this before would have the two connections now and the RTP could stream could flow through Yeah, I have some examples of a typical session. So how that would look like it's You basically it's basically every time it's the same. It starts with the CR6. So it creates a connection and There are some situations where you do not know That where you want to receive your your data yet, so you just basically say into the blue we are create a connection, but I don't know Yeah, I expect your RTP data. I will tell you that later and then Then it creates a connection and the the integrated way already tells reserve support tells where it expects the data and then when you found out Where you want your data to be sent you can modify the connection and Then you would create for example a second connection They already know which which part you are expect the MGW to send the data to then It's only one message and when you're done with the call you just delete Just delete your connection again You actually can delete normally Yeah depends you can do a sort of wild card at BL6 Where you just don't reference to a specific connection and then it would delete drop all your connections Basically release the whole endpoint Or you can say I have two connections and I want to delete this connection with that can particular connection at you So you basically have multiple options there Yeah, and now you have a look at some Practical examples how we Use it This is a typical situation as we have it with the split branch today Sack if the BC is connected to an a interface to the to the Corner backhaul and we also have an RTP RTP stream pointing to the backhaul somewhere And the MGW is Controlled via MGCP that these sort of orange Wire here Yeah, and of course since this you repeat it's not a permanent connection It's just a request this once and in this setup by this example. I made up a network with two BTS and of course and if you have two BTS as we might end up having an end over and Yeah Let's Do the handover for moments. Well, let's assume the mobile is jumping over and What you already can see here Is whoops, this was one too much The RTP stream pointing to the corner work remains constant and that is the requirement. So if you do is the handover inside our Cornetworks the inside our BSS the corner work is basically not informed about that the corner work doesn't care if they are and over so if you at least in one if you are connected to One B stick one BSC. So if you have inter BSC handover, that's a different thing But the normal handover as you know it Would Change the RTP stream locations family. So there will be MDC X messages to the MGW for each handover and Basically, you need to Need to have the RTP connection constant and that's actually exactly what's the other what's the MGP does MGW does here. So it's Isolating the BTS RTP streams From the corner to record basically makes the corner work things everything is fine everything is stays as you Negotiated it on the interface Yeah, and of course Having an MDG P An MGW there is also a good if you later introduce the trans coding You could also do trans coding if necessary. So let's say if you are BTS We had our tool has problems with AMR for example, which is because it's an older model You could easily do the trans coding as well Yeah, and we also have a Co-located MGW to the MSC that's particular Osmo Osmo MSC Example of course in a third party with the third party MSC could be different The MGW is necessary for basically Yeah, but could could be a transcoder as well for transcoding Codecs for the whatever the PBX or what's what's the white world out there supports and it's also Plays an important role When we do do the local switching this Internal M and internal MNCC Yeah, yeah normal is this in this example I have an Osmo SIP connector here, but as you know, you could also have your internal MNCC right built into That is built into the MSC. You could also use that and And then you would have you would need to need a switchboard to To switch your RTP seems otherwise wouldn't work So yeah, that's that's pretty much the setup I run all day when I do test with these split branches. It's it's like that And also Some more exotic Topologies are syncopal as well. This is an example from where Where it was necessary to Overcome some limitations of the link that's the application where BSC not this involved and There's the MGC MGCP gets tunneled over in a satellite link inside an IPA multiplex along with SCP light gets demultiplexes in the BSC the BSC forwards it to the MGW and Yeah, then things finally get switched. That's just Just as As an example Okay, now I Still have a little bit of time through with the first part of my talk now and Yeah, are there any questions in particular for Regarding MGCP Okay, why the why the two media gateways if the is it is it necessary if the DSC and MSC Are co-located in the same Physical hardware or not. Is it actually it's strictly necessary that there be two media gateways? Yeah, the question was I don't have to repeat it. It's on the on tape anyway. Yeah Oh It's some noise. Yeah in the answer is no, it's not really necessary to have two but you must have one since we are supporting a Model where Dynamic endpoints are possible You could use one one MGW with with two call agents. They wouldn't interfere each other. They both would crave for connections They would basically issue a CR six with With RTP bridge slash star so just give me whatever end point is free And then it gives the end point whatever end point is free to the one side and if another side requests It would give you a give it another free end points not like Both sides Doing the end point assignment for themselves That's that was the limitation with Osmo BSC MGC P and this is the earlier versions of of the MGW But that problem is now solved so it's easily possible to summarize you can either run separate Osmo MGW instances one for the BSC one for the MSC you can also simply run one Osmo MGW that then is used by both the BSC and the MSC Yeah, exactly and another level of the question is Why do both the MSC and the BSC need a media gateway probably and then it was mentioned before that When the BSC does a handover you want to stay transparent to the MSC so BSC needs to have a switch a Switchboard to do handover properly so that it doesn't need to tell the MSC anything about it That's why the BSC has its separate MGW connection and it can be as its own MGW or it can be the same MGW that the MSC uses but still it needs to have a you know a juncture Okay Yeah, basically the rare in the very early setups we Made it without MGW and then the handover need to be needed to be reintroduced and then we exactly stumbled upon that problem Yes, one more. I don't know it's not a question just some feedback I Served this ago. I have I have installed MGV for split stack and I Was not able to find any documentation So it's really difficult to to configure because it's not obvious for I think okay Yeah, we are working on Providing documentation for that of course Yeah, yeah, I see That's a real problem. So Did you try the example files we ship with our various Finally, I Find a way to configure it and it works. So but it's what not not obvious it. Yeah, these things are not obvious. It's Probably the problems developers we have to think oh, it's it's so simple, but yeah, of course if somebody Listen back and tries it. It's it's a different thing. I understand that also It's another question. I saw in documentation that It should have some key some Some version of Osmo mix connector included Should be included in MGV. Can you say some words about us? You mean Osmo sub connector? Oh Yeah, that's My problem Osmo is the Osmox is There are fragments in the source group, but they do not work at the moment That is the feature that will be reintroduced at some later point again But at C in the current version of the Osmo MGW. It's non-functional basically. So Me we kept that in the code. We didn't remove it entirely because we plan to Fix that at some later point, but at the moment, it's it's deliberately disabled so Osmox The only working configuration at the moment is with Osmo BSC SCCP light and Osmo BSC net That's basically what Osmox was originally written for and that's used and tested and Power just in the last couple of days. He merged some jitter buffer in there for for certain satellite links To hide the jitter from from media gateways that don't deal well with lots of jitter So that is used in production, but the reintroduction of this Osmox feature in Osmo MGW is still on the to-do list at the moment. There's an open issue about it So regarding the mold we are you merged to MGWs. So how does RTP actually Works in this way, so is it going to MGW then goes to itself back and then forward it so is there any way to Collapse this to save on CPU power because when you have quite a few You know RTP streams on low power systems that might be an issue So your your basic address the local switch problem when we basically Talk to ourselves, so you know it's not a it's not a local call switching It's just when you have an ATB mode So you have two MGWs in one right, but in the current architecture as far as I understand It's still logically. Yeah. Yeah, so RTP is going to the first it goes from BTS to MGW Then it goes from MGW to MGW So it basically just goes through the loopback and then it goes fuzzer. Yeah, that's a that's a logical consequence of the setup like this Yeah That would require an optimization if you would have to detect That these three minutes you never could leave to the outside and Come back again. So we would forward it internally somehow It that would be an idea to think about but yeah as far As far as it is now We didn't basically didn't implement this but we thought about doing that and we we recognized the problem Just like how how difficult it is in terms of yeah, it's not sort of difficult, but it requires again some Implementation details some again some some other exception to handle and Yeah That's That's because we we are basically loaded with this other fixing other things and Making other things works that that's basically the problem, but yeah, so at the moment It's basically about making things work and fixing known bugs and optimization can always be done But it's not the top priority at the moment particularly in a non transcoding case. I think You would have to have a really small system with lots of rtp streams that you really see some some performance issues there, so Yeah, it's an optimization has two ways to do it one of it is in the media gateway Autonomously detect that basically that two endpoints that just send to each other and then try to sort of optimize the path And the other approach is basically to handle this at the BSE or the MSc level Which of course requires more intrusive changes, but that would basically map to The media gateway less operation Where basically we skip some state transitions in the BSE and or the MSc to the media handling So we can again work without a media gateway and then you could configure Let's say the BSE to not do a media gateway and only the MSc would use a media gateway And then you again achieve the same But that's of course more intrusive in terms of logic changes, but both options are possible Yeah, but that's a separate talk about it, I think at some point as And I'm not sure how much it relates to the question was about LCLS the local call local switch feature But I think we should wait for that discussion until we cover that Okay So any more question we had lots of questions already about the Osmo-com implementation I think the first presentation was only about MGCP as a protocol and the Osmo-com part actually is what What Philip wanted to present about now, so maybe let's give him a chance before Before it's become redundant for all the question Yeah, we are only three minutes over time First talk, it's fine Yeah Now we are at the Osmo-MGW One new Osmo-com media gateway So Yeah, the Osmo-MGW media gateway It's a relatively new New member in the Osmo-com family We introduced it in 2017 after we gave Osmo BSE and a score MGCP a good cleanup and Basically, we also removed the hacks which are contained in Osmo BSE MGCP. Those were Familiar with Osmo BSE MGCP. Probably might know Osmo BSE MGCP has some Auto-detection of the other end so it's Basically when you create a connection you create it only for one end. I believe it was the network side and then it says some magic involved to Auto-detect your BTS and there are formulas to calculate parts and So that Let us remove because it was a rather difficult setup. I Think the origins of that is because Osmo BSE MGCP was used before in a very specialized setup where this kind of hack was Appropriate, but yeah, since we were planning to you make it into a real Real media gateway There are some changes to be made Yeah, I said it temporarily removes Osmox and Yeah, and as I said before we have now a dual ported end points if you will so And the wild carded DIC x things which basically they can basically request the MGW to assign Whatever free endpoint to you it you do not get you don't say out of the blue like I want in point three You just say I want any end point star and then the media gateway gives you for example five If that is the next free endpoint it will give you that Yeah The applications which use the Osmo MGW They do not have to implement the whole MGCP protocol itself, even if it's a very simple protocol requires some handling and Osmo MGW will provide some tools to simplify that Basically provides you with the whole protocol stack you just fill out some structs and Call some functions and that's it. So you do not have to implement the whole thing from scratch and the libraries even come with It's own VTI so as soon as you use our libraries Osmo MGCP client to be precise You will get already made up VTI in your application So you don't have to worry about how how do we are structure my configuration interface and so and this also provides some uniformity to the Osmo products, which is basically shows you Configure the MGCP part of the BSC of CMS you configure it all the same way Yeah, so the API behind behind this in our MGCP client Comes basically into two different flavors. There may be situations where You need handcrafted MGCP messages for some specialized situations Then MGCP client provides you with some Some low-level API where you Basically can do that where I can handcraft an MGCP message you send it you get the response back you pass that response and Basically do it all by yourself. You also have to Take care about the timeout handling as well there So there's basically no no luxury about this, but you get a lot of implementation freedom and recently we introduced another way to ourselves found that the low level is pretty pretty complicated it's pretty hard to to get everything right to handle the timeout correctly to Pass the response and repeats itself also very often things are very similar. So that's why we provide Edison and you a kind of way to doing that. That's the MGCP client FSM that's Since you need an FSM anyway, if you do that kind of protocol handling Because how do you handle the timeout? How do you handle all this? You do it with an OSMO FSM of course so that's Why we built upon that so we made up a child FSM, which you can use and you already existing FSM, which Let's say handles your subscriber or something So you can use that child FSM and it has abstract it provides you with abstract commands. You can just say Can exactly do basically corresponds to these three commands words Command verbs we had in the beginning it can make connection can modify it and you can delete it and basically You very simply see very roughly say I want to make connection with that IP with that port Go ahead and do that And if it if you fail Tell me that tell me it had it to me by Responding back with an MS. It's an FSM event. This FSM event and if it if it worked Give me another FSM event. So here you have once more the model How that would work? I have the application and inside this application you Have the MGCP client running Which does the request sets up the connections on the endpoint and we're out CRTP stream. So and now basically, that's you will go ahead with some practical examples and I also have some Because I wanted to make it easy for you to to use Osmo MGW. So I think it's so that's what's most more interesting to show you how How we can control the MGW from your application rather than going to the technical details of the Osmo MGW itself. So And I've made up some examples for both API flavors, which which I can give you if you're interested And then you in this isn't this examples You find some ready-made up source code which is which you can just compile in the script which just Starts an MGW in the correct way and then you can explore it and Also into the package also contains some trace which which shows what's what matches the messages are expected So that's intended to provide some some kickstart if you want to implement an application that needs an MGW You can do it easily with just our tools and Here we have our first source code snippet What that does is it it basically does Nothing else than just setting up an MGCP message. So we find some Things here we are we're probably is we have a command about CR6 which basically means you want to make a CR6 message in this case and then we is that struct we get If a presence field you have to look up in the MGCP underscore client dot h file the strike but it's it's basically something like that you have a presence field basically Says I have an endpoint in that message. I have a call ID and a connection mode. So you have to since the the struct has Multiple fields and you not use all of them with any requests We introduce the presence flag which you say this truck that contains this this isn't this and the other stuff just ignores and ignored by the API And yeah, basically what I do there is I set up a call ID one two three four five six seven That's my call ID. That's how I want to identify the call. I initially set a set this That's to be precise. That's a value that I have to configure. I have to tell the MGW which call ID I have and the MGW will then respond back with with the connection I use it's a two different things that must not be mixed up And I also say I want to make a loopback connection. So that will be a connection that basically whatever I send to it via RTP It's it's just echo it back And yeah for the endpoint It's a bit more interesting. I need to Use an Osmo STI copy to copy a string to a buffer inside this truck So it's not not all that nice Yeah, and here we see the stars. That's a wild card request. So that's how I instruct the MGW to basically Ask it to give it give me any Whatever is free so and then once I have set set that up I generate the message and And basically what it does in this message profile, it will just set up these these ASCII encoded Viya protocols. So that's basically if you would do a print F with that Message with the data part of the message we would get exactly the string that is sent over the wire It's just the MGCP messages and if you execute the example you can already see it. I've prepared. So if you run that We basically see the messages goes over the wire and Then yeah, since we have the message prepared We just send it and we give it an A pointer to the MGCP client which is initialized Before the initialize from the configure file. You give it with the VTI and so on so if It's basically your client instance Your client handle you give it the M Give it the message itself and You also give it a callback function because somehow you want your response back You want to know what what's the outcome of your your request If you are not interested you can always issue a null pointer. That's okay So let's say if you want to DICX for a last resort you want to free you they are about to crash and want to free your source your You could have a null there and just Basically say I don't care about the response Whatever it is. So but but in this case we care and we have a the callback function for that But before you look Exactly How the callback function is structured? This is what we would get This is what it basically generates when we when we run that code and You can see our call ID. Unfortunately in the code I use decimal Wireshark depicts it in in hexadecimal But it's fine. It's all quality and Some educated guests about the codec, which will be extended later. It's a moment. It's It's fixed and You also see a loop back and we see our endpoint name And the transaction ID since this is this when I made that This is the first message. I sense it's one So Basically, what happens if you re-send a message? It's UDP you could run into timeout So let's say you send your message and you never get a response like you could try to do it one try it once more And what you then do is you just repeat the message with the same connection in the end the MGW will If it really didn't receive your message If everything will be okay, but let's say the response got lost and it received a message with CR I've seen that before I just respond the same way. I spawned before so the send and receive logic is implemented inside of small MGW Alrighty, so you don't no need to worry about that. But it's a moment since we are using this stuff on Basically locally everywhere and if you lose UDP pocket packets while you are in the same one of the same machine That's that doesn't happen in reality and if it happens Probably have some problem Okay, let's see how we How we dissect the response now, so this is a callback that gets called as soon as the client receives the response from the MGW to execute your callback with some private data and The first what you do would do is before you even pass it further you would check your response Your your response code. So in this case, it's 200 it should be 200 if it's not 200 your cases considered as failed So before you Call up the parser you would check the response code and you would check if parsing is needed at all And then When when you discovered everything is fine, you would pass the response with MG speed response past param and Yeah, basically then you get two results ports your address endpoint name you got issued by the from the MGW And your connection either connection idea set is very important you have to memorize that when you want to Deleting is not so difficult, but if you want to modify later, you need that Okay, let's have a look at the Response now I've marked the interesting So this is what came back in response to to the message we sent wire the client So you see our 200 okay? you see the You see that the MGW assigned M.0 See the connection ID see the IP address it where it expects RTP data see the port so yeah That's the That's the low-level way to do it and You also if you if you do it that way you also can run in a very difficult situations imagine your Your MGW answers late because there's some load on the MGW it answers late and your your Logic your protocol logic already decided It's timed out and our resource are freed it will cause a call back anyway, and it will dereference null pointers So there's the IPI of course provides a way to cancel pending messages And you have to remember to do that when you run into the time what you have to deliberately ask the The logic behind the client to to remove your message So basically you don't that you do not expect an answer anymore in case the MGW answers late Won't really happen in the reality, but it could so but There are ways to to get around to it now much more comfortable and That's the MGCP client FSM and Since we discussed this example since this has to be used from an FSM So there's no other way since this comes as a client FSM which you instantiate inside and a parent FSM we need to come up with some Simple state machine bodies In this case it's just Consist of one single state which we're just loops around Hopefully it won't won't die. So you agree on Basically for signals to start with a signal which we very Maybe Mention that later as a code that's better if you want to ever interested in a real-world example you could Look as to have a look at the subscriber Connection FSM in the in the BSC. That's where we exactly use that kind of model For the previous example The MSE still uses the old-fashioned Low-level way so both Both things are in the wild and they are real-world examples for that So we start with the Start very similar We start very similar to the MGCP client But in this yeah in this case we just we start by filling up the abstract with the message parameters we need so In this case Again, we have the wild carded request here and We agree on a quality We have the IP address in support. That's stuff. We want to pack in our request But in this case we it's it's more abstract. So it's basically what we do we configure a connection So we we configure on which endpoint it should run which color they should have which in which part we we expect the RTP data to arrive and Yeah, and then we basically tells the MGCP client a client underscore FSM to be precise That this connection shall be created now And basically that returns us an FS osmo FSM instance and Here we see here again as a pointer to the our MGCP client It's the same as with the MGCP Same as the in the next sample before that's our pointer to the MGCP client logic and We give it the pointer to the to the parent FSM. So basically that reference the FI here references our Our parent FSM so the simple body FSM I depicted before that's it and we agree on two two events Yes, Osmo FSMs are basically event controls. I need events We agree on one event which hopefully never occurs. It's when we when the MGCP client underscore FSM Discover some problem it it will die And then we get these event back and then we can handle accordingly So tearing down some other connections or do whatever is needed to To make our emergency landing And we also agree on a on a success event, which basically is in our case We we say this should be the event got CR6 response and We basically expect this event here to be transmitted to our parent FSM So we can move on so then we know the connection is created and we can do the other stuff And here we give it a pointer to the connection in for this just a local variable Which I just steered out before to be sure It's just filled here. So it's there's no waiting catch here Yeah, and then let's see What happens exactly when we execute that? And it's looks familiar to us again, we just it just generates the message it Again, we have the wild card as endpoints and the parts and the call ID that all gets generated automatically and if you are lucky we get the response back and Yeah, basically is the MGCP client underscore FSM can receive the response and pass it Anani's all this Anani's the MGCP client FSM the regular MGCP client does its work So this is basically an overhaul for that To to provide a more comfortable interface technically it's the same as you see before I will just internally Handle the creates a message send it and take care about the time out and have his own as I said It's a child FSM. It's its own little FSM that Basically handles all the nasty stuff for you and yeah, if you are lucky enough we get the Got CR6 response event back and yeah, then we can just Pick up The response information from from the struct. That's it. So there's no It's not not very difficult to So it's just the last Resistruct out and that's it. You don't even need to to pass things and Yeah In this example, I just set up a new thing. So I want to modify the connection In this example, so I want so I set it up How I wanted to have how I want to have the connection to be modified and Senators call mgcp con modify and I have again to agree on on an event which I get back These events basically takes the role of the cold callbacks in in mgcp underclaw underscore client So I agree on on on these that I on these events that I get the eevee got MD6 response man once I got that back, you know My my attempt to modify the connection was processed Correctly, we don't need to re-agree on on this on a failure event. So the eevee FSM died That's already agreed when I connected where I create the connection it memorized that so there's no need to To do that twice. So that's memorized and if something fades during the modification It gets you died even back and then you can do your emergency learnings as well Yeah, and then Simple as as before the same as before you you just would pick up. What's the mgcp? What's the osmo mgw responded and then finally you could In theory delete your connection and this example I deleted immediately And there I don't have to agree on any events. So in this model I'm not really interested to know if if it's deleted if there's an error. I will We get the diet event back And if it's fine Oh, no, no, no, that's wrong and I delete the The connection That's that's a trick here because I deleted and then the The Child FSM will unlink it for safe from the pound we do all the nasty work itself So if it should die it will die for itself So as soon as I do the lead I don't have to I don't need to care about whatever happens there So I can just tear down move on with my my tear on possessive. See I just terminate the parent FSM zero and go ahead So you just can if you if you don't need some connection anywhere just throw it away and It will have itself That's also provides a lot of comfort so you because in the if the if your parent FSM is modeling a more complicated protocol There will be lots of lots of error situations and situations where errors can occur and imagine if you would have to take care about Properly freeing MGW resources there. So there you can just call the function and then it's gone Yeah So now I'm through here for few minutes left. So Other questions. I hope that was a star understandable. We're as interested can Get to the example code for me and I also could help if it doesn't work on your machine I Think I will upload that in the wiki anyway, so we'll find it later at the point in the wiki where we Where we have your MGW stuff? Yeah other questions, I have one more question Is it possible to get or to export any RTP statistic from Osmo MGV because it's very important when you use system in production to you should somehow to detect to define the issue yes says In the in the MGW in particular we At the moment many of the counters you're probably interested in Still handcrafted so we are working on parting that over to Osmo com rate counters so you could read it out at any time and When you delete connections separately also in the RTP in the MGC P DICs responsible at you some statistics, but yeah, we are working on that So basically the the RT the RT CP statistics and the statistics That the media gateway itself generates which it also sends back in RT CP of course all the time to the into the opponent node those Should get or I think they are already aggregated in the DLC X So so when the when you delete the connection basically that information is returned back now We don't have anything in Osmo BSC or Osmo MSC that uses that information in any way But on the protocol level the MGW Sends this statistic information basically when you tear down the connection or you can also I think from protocol point of view You think you can also when you audit the endpoint or there's some some kind of request in an ongoing connection How will the call agent or any call agent could request some some information about the ongoing call? It's a moment as the It's the TS TS error, I think it's a timestamp error if there's timestamp error, it would be counted The patches really recent I I first I ported over exactly one one counter to be sure that The model how I doing it's right and then the next thing I will do there is To a pot over the remaining counters But the the the porting of those counters is independent of the reporting that happens on the protocol level these counters are just so with the control interface You can also extract the information if you're interested in that but that's independent of what happens on the protocol level And I think on the protocol level What currently happens is that The media gateway just works as a proxy for both RTP and RTCP So it's basically the the OSIP Implementation on the BTS side or on whatever on the other side is sending its statistics in RTCP And we just pass them through from left to right because on art like the current implementation, which is for historical reasons like Osmo PSG and PC MGW It's basically just a UDP proxy It's not actually terminating the RTP or interpreting it in any way Unless you would enable transcoding which is already present, but we haven't tested it. So it's most likely broken in the current code But Osmo PSG MGW the predecessor already had support for transcoding in there Then it's different but in the normal Having two RTP connections on one endpoint mode. You just pass the data left and right and we do Well, yes, you otherwise we couldn't detect the timestamp drops and things like that But it's not Like on an RTP protocol level. It's not really terminating the protocol. It's really just passing through I mean we look at some header fields, but we're not Acting as the end node for the RTP really right and on the asset on the on the BTS side I mean, I'm not sure if you ever looked at it, but Osmo BTS Sends plenty of statistics in the in RTCP all the time Which is basically what what Libosive is generating all the time RTP, yes, sorry. Yeah. Yeah Okay, then thanks to fit. Oh, sorry. Yeah One more question Is there already a way to control a port allocation? For MGW because it's important when you are exporting Basically for firewalling and So Is is it is controllable via you can define a port range in the configuration So basically can now the down which parts should be used and the old fashion Osmo a BSE underscore MGCP basically Had more options on that they they we had port pre-allocation, so it would at the moment where Osmo BC MGC MGC P starts it would allocate all the ports and Then that would be a fixed endpoint resource But in the way as the way as me MG W now works is the only possible way to narrow it down would be up a supply range We are actually do that in our test set of the way because we have to We have to have some some gate Some part what ranges so that we won't interfere accidentally. So yes, this is possible But you cannot predict Which part a connection it Will get next that we picked whatever is free from that defined range No, we don't need to predict We just need to be able to map those ports to for example from internal IP address to an external IP address Yeah, that would be possible. I think so I just wondering if in the research into MGC P and building the media gateway if Any of other third-party products have been looked at, you know, I'm thinking for example RTP engine which Is mainly used with the Camelius proxy and I haven't really used it. I'm using the previous Really previous version but previous incarnation so the RTP engine I understand is a user space demon that also Does transcoding and also talks to an internal module if it can to do like Direct packet forwarding at that level, but it's probably really designed for stuff Or you have many thousands of simultaneous RTP streams But I am I think it's controlled from Camelio by something called the RTP proxy module language Which is really some similar stuff sending STP But there might be some things in there that Are useful maybe and Maybe not at the same time. It's nice to have your own stuff, right? Yeah, I don't have to Fix something that some other product is not supplying for you and you just have complete control yourself But I don't know maybe I'm just asking if you if it's been looked at because maybe if Osmo MTCP client could ultimately control something like RTP engine It might be useful I think The mgcp client is at the moment very much tied to mgcp I'm aware of there are some of some alternatives to mgcp, but yeah, I have to confess Yeah We started out with mgcp with Osmo where we see mgcp that was already there and I continued Developing and building on that the important part to note is that Actually the we we soon hopefully will have real media gateway support So e1 and t1 support in there, and I don't think you can fend anything out there Because that it's actually one of the talks coming up later today is about reintroducing e1 support and Then you need not only RTP left and right, but you actually need to understand e1 interfaces and 64 kilovit slots and 16 kilovit subslots and all that stuff that used to be in Osmo NITB in terms of free software implementations of Media gateways that speak mgcp. I don't think there is any but of course there are lots of proprietary media gateways that speak mg mgcp So you can find quite a number of Cisco voice gateways for example that speak mgcp is one of the control protocols and That's we haven't really tested interoperability with that yet We have bought one of these units so we can test interop if we want to but Hasn't hasn't reached that point yet Just as a Future feature request Would be nice to also have support for something like HEP in mgw to Export RTP information to external and monitors for quality purposes Something to think about like for the roadmap Maybe it's also very easily to build that up on the control interface I mean since it's an epa multiplexer as example python code for that you could write a wrapper in theory Okay, good. We are over time already with this time slot. So I suggest we move on unless somebody has an urgent question left Okay, thanks, Philip