So if you have seen the first post, it gives a fair idea to someone who has worked on VoLTE, but to new person it might be confusing.
So let me try to explain it in easy manner.
We all use our mobiles for making call, that CALL is known as Circuit Switch call, since in this the it is basically our voice packets which are send or receive .
Whereas when you use SKYPE, whatsapp, facebook for making call, then it is PACKET SWITCHED. Our voice will be encapsulated inside TCP/IP packets and will be send , the other party should decode this.
Now if you pay attention to the diagram on the previous post, there is a audio engine/ which is shown as speaker whose input and output will be VOICE PACKETS.
Then comes VCE ( voice engine) which depending on implementation can receive RTP packets or TCP packets will extract VOICE PACKETS from it and send to SPEAKER/AUDIO engine.
Same way it will also encode VOICE PACKETS to RTP packets.
RTP stands for Real Time Transport Protocol.
It is application layer protocol in OSI layer.
Now this RTP has to use transport layer and network layer protocol , since this is PACKET SWITCHED or simply put INTERNET , we will be using UDP/TCP and IP layer respectively.
Thats where TCP stack comes into picture.
So what is left now , we need some module for signalling . Makin call, activating voice , deactivating voice once call is on hold, stopping tcp and voice engine once call is ended.
That will be handled by IMS stack.
What is AT CMD . It is simply a interface which can be used to communicated between all these modules .
Programming wise , we can have API for each functionality which each module has to share with others.
But it will limit the porting or make our implementation close-source. If tomorrow you have to use some other TCP stack or VCE , then again you have to implement those API.
API is simply functions provided to access data and method of a particular module.
Therefore untill you are getting paid :) , have the code as much open source as possible .
Now in the next post we will see a brief flow of flow of MO call and then in subsequent post we will see how to implement ( which I think will be hard , since I don't have experience of writing code of any one of the module involved in my post ).
So let me try to explain it in easy manner.
We all use our mobiles for making call, that CALL is known as Circuit Switch call, since in this the it is basically our voice packets which are send or receive .
Whereas when you use SKYPE, whatsapp, facebook for making call, then it is PACKET SWITCHED. Our voice will be encapsulated inside TCP/IP packets and will be send , the other party should decode this.
Now if you pay attention to the diagram on the previous post, there is a audio engine/ which is shown as speaker whose input and output will be VOICE PACKETS.
Then comes VCE ( voice engine) which depending on implementation can receive RTP packets or TCP packets will extract VOICE PACKETS from it and send to SPEAKER/AUDIO engine.
Same way it will also encode VOICE PACKETS to RTP packets.
RTP stands for Real Time Transport Protocol.
It is application layer protocol in OSI layer.
Now this RTP has to use transport layer and network layer protocol , since this is PACKET SWITCHED or simply put INTERNET , we will be using UDP/TCP and IP layer respectively.
Thats where TCP stack comes into picture.
So what is left now , we need some module for signalling . Makin call, activating voice , deactivating voice once call is on hold, stopping tcp and voice engine once call is ended.
That will be handled by IMS stack.
What is AT CMD . It is simply a interface which can be used to communicated between all these modules .
Programming wise , we can have API for each functionality which each module has to share with others.
But it will limit the porting or make our implementation close-source. If tomorrow you have to use some other TCP stack or VCE , then again you have to implement those API.
API is simply functions provided to access data and method of a particular module.
Therefore untill you are getting paid :) , have the code as much open source as possible .
Now in the next post we will see a brief flow of flow of MO call and then in subsequent post we will see how to implement ( which I think will be hard , since I don't have experience of writing code of any one of the module involved in my post ).
No comments:
Post a Comment