 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 the mgcp, but if you ever have used the split the Osmo BSC split branches You you already had have some experience with it because the Osmo mgw or the Osmo and the Osmo Bsc mgcp is Manatories there, so we need to switch the voice trims somehow mgcp stands for media gateway control protocol And there are some successors is I looked it up. It's the s GCP and the IPTC and as you can see there it's Cisco and core and level three that are where the three major figures in there who Basically where the driving force behind that and yeah, it became an ITEF 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 protocols 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 to new protocols as 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 the mgcp is you would have some media gateway and that's That's Yeah, you have to take some by the word it's a it's a gateway that converts the RTP stream to let's say an e1 line 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 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 the 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 It's specified so you don't have it must not use any arbitrary line break Combinations, but yeah, that's that's how it looks like on the wire. It's basically When I when I did my first experiments with that I I did I Just made up a text file and used netcat and piped it down there and that That would already work to control the media get off course. They are As if it goes 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 you get a response to that So there's a fixed role. So you have you have a client or it's also called a call agent that requests something at the MGW do makes that connection Modify the connection delete that connection and then you get responses Yeah, and it runs on really people 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 modify a connection and delete the connection again, and so of course there are Also others so for example the audit end point 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 and 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 end point has these these descriptions is basically this pass here RTP bridge that's our our series of RTP endpoints we plan also have to Run endpoints in the future and there of course the pass would look a little different and the other the The well behind see at this basically an identifier for the MGW itself Yeah on on that endpoint you you create connection two of them you basically have Do you do your CR6 your create connection command and corrects a 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 That's basically 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 CR6 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 It's some unique with makes your message distinguishable from recent so it's gives your Message a Distinguishable number which is 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 small like that 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 gateway should say that's not okay. It's an error and 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 laser pointer would be Much better, I think but they don't have one Yeah, yeah, here's the codec set up my talk is more focused on the switching aspect rather than the Codic and transcoding aspect SIF 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 our MR and it should be a send receive connection So it's not a loopback connection here. So it's in send receive mode. So and We also give it a we attach an SCP 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 the port 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 001 8000, 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 risk quest 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 says, yeah, well, I don't feel to request Here's your connection identifier and I am listening on 127 404 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 The 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 there where The message like this request response like this before would have the two connections now and the RTP could assume could flow through Here I have some examples of a typical session. So how that would look like it's You basically it's 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 Where I expect your RTP data yet I will tell you that later and then Then it creates a connection and the the integrate way already tells reserve support tells it 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 wildcard BLCX Where you just don't reference to a specific connection And then it would delete drop all your connections would basically release the whole endpoint Or you can say I have two connections and I want to delete this connection with that particular connection at you So you basically have multiple options there Yeah, and now we have a look at some Practical examples how we Use it This is a typical situations as we have it with the split branch today Sack if the BC the BC is connected to an a a interface to the to the Corned work 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 Why are here? Yes, of course since the CODP 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's we might end up having an end over and Yeah Let's Do the handover for a moment. So let's assume the mobile is jumping over and What you already can See here is This was went too much The RTP stream pointing to the corner work remains constant and that is the requirement. So if you do the handover inside our Corned works the inside our BSS the corner work is basically not informed about that The corner work doesn't care if they aren't 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 Normal handover as you know it Would Change the RTP stream locations permanently. 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 the RTP does MGW does here. So it's isolating the BTS RTP streams From the corner to work and basically makes the corner to work things. Everything is fine. Everything is stays as you Negotiated it on the interface Yeah, and of course Having an MGW there is also a good if you later introduce the transcoding You could also do a transcoding if necessary. So let's say if your BTS you handover to Has problems with AMR for example, which because it's an older model You could easily do the transcoding as well Yeah, and we also have A co-located MGW to the MSC. That's a particular Osmo Osmo MSC Example, of course in a third-party with a third-party MSC could be different The MGW is necessary for basically Yeah, but I could be a transcoder as well for transcoding Codecs for the whatever the PBX or what's what's the wipe world out there supports and it's also Plays an important role when we do do the local switching with internal internal MNCC See 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 Then you would have you would need to need a switchboard to to switch your RTP steams. Otherwise wouldn't work So, yeah, that's that's pretty much the setup I run all day when I do a test with these split branches. It's it's like that And also Some more exotic Topologies are synchable as well. This is an example from where That was necessary to Overcome some limitations of the link That's the application where BSC not as involved and they are the Mgcp gets tunneled over and a satellite link inside an IPA multiplex along with SCP light gets the multiplex 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 necessary if the DSC and MSE are Co-located in the same Physical hardware or 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 site requests It would give you give it another free end points not like Both sites Doing the end point assignment for themselves That's that was the limitation with Osmo BSC MGCP and this is the earlier versions of of CMGW 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 there were 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 MGW 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 Yes, finally, I Find a way to configure it and it works so but it's not not obvious it. Yeah, these things are not obvious. It's it's Probably the problems developers we have you think oh, it's it's so simple, but yeah, of course if somebody It's nobody can trace 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 MG week. Can you say some words about us? You mean osmose connector? Oh Yeah, that's My problem Osmo is he osmox is There are fragments in source. 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 osmux The only working configuration at the moment is with Osmo BSC SCP light and Osmo BSC net That's basically what osmux 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 osmux feature in Osmo MGW is Still on the to-do list at the moment as an open issue about it So regarding the mode where you merge 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 the low power systems that might be an issue So you're basically address the local switch problem when we basically Talk to ourselves. No, no, it's not a it's not a Local call switching. It's just when you have an ATB mode. Oh, so you have two MGWs in one, right? But in the current architecture as far as I understand, it's still logically Yeah, yeah, of course. So RTP is going to the first is got 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 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 And 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 against some some other this 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 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 There are 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 there'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 Hey now we are at the Osmo MGW Or a new Osmo-com media gateway So Yes, 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 BSC and a square MGCP a good cleanup and Basically, we also removed the hacks which are contained in Osmo BSC MGCP those were Familiar with Osmo BSC MGCP probably might know Osmo BSC 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's there's some magic involved to how to detect your BTS and their formulas to calculate parts and so that Let us remove because it was rather difficult to set up I think the origins of that is because Osmo BSC MGCP was used before in a very specialized setup where this kind of hack was 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's It temporarily removes Osmox Yeah, and as I said before we are we have now a dual ported endpoints if you will so And the wild carded DLC x things which basically they can basically request the MGW to assign Whatever free endpoint to you it you don't get you don't say out of the blue like I want endpoints three You just say I want any endpoints 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 labels even come with With its 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 basically ensures you configure the MGCP part of the BSC of the MSC 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 to handle this via 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 can only repeats itself also very often Things are very similar. So that's why we provide editor and a new 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 awesome 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 We 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 MSF FSM event with 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 You have the MGCP client running Which does the request sets up the connections on the endpoint and routes your RTP 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 in this examples you find some ready-made up Source code which is which you can just compile and 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 a 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 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 familiar with 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 Have a presence Field you have to look up in the MGCP underscore client dot H while the struct 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 F Connection mode so you have to since the the struct has Multiple fields and you not use all of them with any requests 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 idea have and the MGW will then respond back with with the connection. I use that'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 by RTP. 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 us how I instruct the MGW to basically Ask it to give it give me any Whatever is free So and then once I have said set that up I generate the message and Basically what it does in this message buff, I 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 method of you get exactly the string that is sent over the wires Just the mgcp Messages and if you execute the example you can always see it. I've prepared. So if you run that We basically see the message that goes over the wire and then yeah, since we have some message prepared We just send it and we give it an A pointer to the mgcp client which initialized Before the initialize from the configured 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 Di6 for a last resort you want to free or they are about to crash and want to free or a source so 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 via shark depicts it in in hexadecimal But it's fine. It's our 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 is when I made said 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 of 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 Osmo MGW All righty, 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 that's the 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 to result supports your address endpoint name you got issued by this from the MGW And your connection I use a connection ID is 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 and I've marked the interesting So this is what came back in response to to the message that we sent wire the client So we 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 some 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 very I Mentioned 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 very we 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 and 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 quality should have which Which part we we expect as the RTP data to arrive and Yeah, and then we basically tells the mgcp client a client underscore fsm to be precise and That this connection shall be created now And basically that returns us an FS as more fsm instance and Here we see here again as a pointer to the our mgcp client It's the same as with the mgcp The 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 you the simple body fsm. I depicted before that's it and we agree on two two events Yes, also my fsm's 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 will die And then we get these event back and then we can handle accordingly. So tearing down some other connections or do whatever this needed to To make our emergency landing And we also agree on a on a success event which basically is in our case 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 teared out before to be sure It's just filled here. So it's there's no way to 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 carded endpoints and the potency call ID that all gets generated generated automatically and If we are lucky we get the response back and Yeah, basically is the mgcp client underscore fsm can receive the sponsor and pass it Anonese all this anonese 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've seen before I will just internally Handle it 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 his own little fsm that Basically handles all the nasty stuff for you and yeah, if you are lucky enough we get the God's here six response event back and yeah, then we can just Pick up the response information from from the struct. That's it. There's no It's not not very difficult to So this is just the last Restruct 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 Then I just 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 under claw underscore client So I agree on on on these that I on this event that I get the eevee got MD6 response, man, once I got that back, you know Mary 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 landing there as well Yeah, and then Simple as as before the same as before you you just would pick up what's the mgcp was 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 possess to 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 show it away and It will have itself That's also provides a lot of comfort So you because in the if see if you're parent FSM's modeling a more complicated protocol There will be lots of lots of error situations the situations where errors can occur and imagine if you would have to take care about Properly freeing MGW resources there. So they can just call the function and then it's gone Yeah, so now I'm through here for few minutes left. So The 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 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 we are working on that So basically the RT the RTC P statistics and the statistics That the media gateway itself generates which it also sends back in RTC P of course all the time to 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 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 a 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 in 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 a 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 live Osif is generating all the time RTP, yes, sorry. Yeah, yeah Okay, then thanks to Phil. 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 And basically for firewalling and So Is this 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-fashioned Osmo a BSE underscore MGCP basically Had more options on that they there we had port pre-allocation so it would At the moment where Osmo BC MGCP starts it would allocate all the ports And then that would be a fixed endpoint resource, but in the way as the way as many MG W now works is the only possible way to narrow it down would be up a supplier 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, that's 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 MGCP and building the media gateway if Any of our third-party products have been looked at you know, I'm thinking for example RTP engine which Is mainly used with the camera alias the 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 Kamailio 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? You 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 there are some of some alternatives to mgcp, but yeah, I have to confess Yeah We started out with mgcp with Osmo baby 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 kilobit slots and 16 kilobit sub slots and all that stuff That used to be in Osmo and ITV 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 mgcp So you can find quite a number of Cisco voice gateways for example that speak mgcp as 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. It 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 road map Maybe it's also very easily to build that up on the control interface I mean since it's an epa multiplex there's example python code for that you could write a wrapper in theory Okay, good. We are over time already with this time. So I suggest we move on unless somebody has an urgent question left Okay, thanks Philip