I have a scenario where UE requests for the VoPS service in the Attach Request, but the network is sending eps_netwk_feature_support_incl as 0, which as per my knowledge signifies that the voice service over PS is not supported.
Further, I can see that the UE is initiating the PDN connectivity Request for the "ïms" apn.
My question is if it is normal for the UE to initiate the PDN connectivity request for the "ims" APN. What is the use case of this?
eps_netwk_feature_support_incl indicates whether network supports the features like ims over ps, emergency call over ims.
If the value of this information element is zero then network does not support any ims related features in that particular tracking area.
There is no point in initiating ims pdn if network does not supports it.
So,UE should not initiate IMS PDN.
Related
I am building a browser multiplayer game. For latency, I want to use WebRTC DataChannel to sync the game state. In my setup, one peer is always the server, which is always reachable (no NAT on server side, maybe on user side).
Most setups recommend using a websocket as the signaling channel. I saw some setups with manual copy-pase signaling, with one peer sending an offer to the other peer, the other peer sending an offer back.
Now, this sounds to me like a REST API - Browser does POST request with a SDP offer to the server, then receives SDP answer from server, both can establish connection. When the connection drops, they do that again. Client can always reach server, since that's on a public IP.
What is the disadvantage of doing it this way vs. establishing a websocket and keeping that open?
in a signaling session the SDP is not the only thing you are sending back and forth. So a short answer to why not to use REST API might be that when you trickle ICE candidates other than SDP there are so many messages going back and forth. I believe the SDP only will not have many problems with REST API but overall websocket is preferable basically even just because of websocket faster.
I am trying to do an IoT project where a node needs to receive some commands from cloud.
Previously, I made this with MQTT protocol. But searching about other protocols on internet I have found REST, which makes possible to communicate over HTTP. However I have seen that this protocol is more used for getting data (makeing a request to the node and receiving the data from it in the response).
I am very new with this protocol. So, I would like to know if it would also be possible to send commands to the node from the cloud, like in MQTT.
Thank you very much for your help.
The HTTP protocol and thus is based in a Request/Response model and using it for IoT device commands can have its drawbacks:
Your Devices will need to be accessible over the Internet and this can be a security compromise when you can have the Device with internet access using MQTT subscriptions but no incoming connections to it are allowed.
You will need to have some mechanisms for retrying and handling offline Devices in your cloud application sending the commands.
There is also more overhead on HTTP than MQTT given that MQTT has long lived connections. With HTTP you will waste more power on connecting and disconnection, also the network packets will be bigger than MQTT.
Can you use REST/HTTP for sending commands to Devices? Yes. Should you do it? Probably not, it all depends on your actual Device requirements and capabilities and why are you wanting to replace MQTT.
An IoT protocol that is similar to REST is CoAP. If you are thinking about using REST in the IoT context I recommend to have a look at it. If your nodes are always connected/reachable there is nothing that speaks against going in this direction. CoAP is a decentralized service protocol where each node might speak with another node.
MQTT is a publish/subscribe protocol with a central broker. As such your cloud could just send the commands to the broker and whenever the node connects to the broker it will receive the commands. So the node doesn't have to be online the whole time.
I am investigating the SIP signaling and RTP media in VoLTE traffic. I can see RTP header but was told that the RTP payload and the SIP packets are all encrypted in IPsec. Is this true? If yes, at what interface I can see the decrypted packets?
Thanks.
LTE is based on IMS (IP Multimedia Subsystem) which is a very broad and encompassing set of specifications for an architectural framework that enables multimedia communication between IP connected end points.
Because it is so broad and all encompassing there are actually many different security points and interfaces - for example there are security specs for communication between an access network connected device (such as a mobile phone) and the core, for communication between different nodes within a single core network, for communication between different operator's or organisation's core networks etc.
3GPP and LTE build on the IMS specs and include specific security specs for the Mobile world also. There is a 3GPP spec which looks at access security for IMS (3GPP TS 33.203) and it includes the following diagram:
Each of the numbers in the diagram above is a different security 'association' and the above standard references one or more specifications for each one.
The result of all this security complexity and these many security layers is that the answer to your question depends on the point in the network you are looking at. For example, if you intercept the traffic between the phone and the base station you will not be able to see anything as it will all be encrypted at a lower layer (notwithstanding the latest GSM/3G security hacks etc). Similarly if you are looking at the traffic between the core network nodes or between different networks this may be over IPSEC tunnels etc and again you will not be able to see it.
If your aim is to intercept and eavesdrop on VoLTE voice calls then you are going to find this very hard as many of the above mechanisms are designed to prevent this - I won't say it is impossible as I'm sure someone will reference a hack or a 'government backdoor' example for similar technology etc.
If your interest is academic, or in profiling the performance of the network etc then you may be able to achieve what you want using one of the open source IMS solutions - e.g. http://www.openimscore.org.
Or, if you are working for, or with, one of the network equipment vendors then you may be in a position to insert or leverage network management and/or OSS 'hooks' or mechanisms which allow you gather info from some unencrypted data at certain points in the end to end flow.
I'm using zmq to develop a distributed application having the following network topology: a client node that initiates a request and a server node that replies to requests. Since the client is a node.js application I can't block after a send call to wait the response, so the scenario is that the client could emit multiple send calls to the same endpoint. On the other side the server is a mobile application that processes one request a time in one thread, blocking if there are not any requests.
If this configuration sounds odd, I'm trying to build a sort of RPC initiated by the server to mobile.
I thought to use a DEALER socket client side and a REP socket server side. From zmq guide about DEALER/REP combination:
This gives us an asynchronous client that can talk to multiple REP servers. If we rewrote the "Hello World" client using DEALER, we'd be able to send off any number of "Hello" requests without waiting for replies.
Can it be applied to asynchronous client that can talk to one single server? And could it be a good choice? If not which pattern should I use?
Can it be applied to asynchronous client that can talk to one single server? And could it be a good choice?
REQ/REP is not recommended for traffic going over the Internet. The socket can potentially get stuck in a bad state.
The DEALER/REP is for a dealer client talking to multiple REP server. So this does not apply for your use case.
If not which pattern should I use?
In your case it seems to me that using the traditional DEALER/ROUTER is the way to go. What I usually do is prepend my messages by a "tag frame", ie a frame that contain an UUID of some sort that allows me to identifies my request (and their reply) at the application level.
I have a SIP Server running OpenSIPs 1.11.3
configured with built-in STUN module (full mode with 2 IPs)
configured with MediaProxy 2.6.1 to relay RTP (using engage_media_proxy in routing script)
Using IMSDroid from doubango as the SIP client.
Calls between wifi-wifi is good, I do not need to turn on any STUN, ICE, TURN option in the client.
However, calls between 3g-wifi or 3g-3g isn't that good. 3G can make outgoing call but it cannot receive call. Which means 3g-3g call can NEVER happen. All I see in the OpenSIPs logs are repeated retransmissions of INVITE because it cannot reach the 3G side.
I read that TURN server can solve this kind of problem, so I enabled TURN in IMSDroid sip client, but still 3G side cannot receive any call.
The TURN server I am using:
url: 'turn:numb.viagenie.ca'
credential: 'muazkh'
username: 'webrtc#live.com'
Is there any solution / module I can use to solve this problem?
EDIT:
If I use TCP protocol, I am able to receive call! Although the call terminate due to transport error after 30 seconds, but at least the call went through. Any idea what happen here?? Mobile carrier blocking incoming call? But definitely not port blocking because I am able to register whether I use port 80 or 5060.
EDIT 2:
I tried using free SIP accounts to make calls (sip2sip.info and sip.antisip.com), and I have the same problem too! As I know, sip2sip.info is using OpenSIPS too but AntiSip.com is using something like AmSIP. So the problem is with my mobile carrier?
Thank you!
If your UA can't receive calls, it means it is not reachable for signaling. In order for your UA to be reachable, it needs to register and keep the NAT mappings alive. To keep a NAT mapping alive, your UA must send keepalive to the server periodically. Another option is that the server sends keepalives to the UA but some NATs don't refresh mappings for incoming traffic.
When you solve this first issue, comes the media part where technologies like STUN, TURN and ICE will help.