[VoLTE]Android IMS implementation research - LineageOS News & Discussion

The IMS service were introduced as early as in UMTS/EVDO early days,but it's getting hot when the PS-only LTE are widely deployed by the carriers.The implementaion of IMS Voice over PS domain,AKA VoLTE,on the UE side is not standardlized by the 3GPP,but most of them have the same diagram and level logic.Here are some key points that related to the IMS parts.
Radio side
First,the carrier's network must set it's network capability of IMS service to true in the signalling to tell the UE that it's capcable of IMS voice service,and the UE's radio firmware must process this signalling message properly and activate its IMS voice related code function routine,like mutilple PDN context support to established the IMS PDN bearer as well as the default Data PDN bearer at the same time,parse the P-CSCF address of IMS domain from the PCO portion of IMS PDN activation response message.
In this stage the IMS configuration related stuff needed to be check :
IMS feature control switch(currently no Android API,some vendors may provides android side configuration API,some not )
IMS PDN's APN configuration(configurable through Android API,but the Radio firmware may process IMS type APN inproperly)
Android side
After the established of IMS PDN bearer in radio,the android may face the problem that how to estabshed the second network interface to the modem's IMS PDN connection,for many not factory-ready android phones there is no vendor RIL API to configure the second IMS data connection,this may vary quite a lot beacause most of this fuctions are implemented in vendor RIL binary & Linux kernel which are not opensource, Upon the RIL level,IMS implementaion are opensource,so it's not a problem,but the IMS client which controls the registration need to get the P-CSCF address from Radio through RIL with some API,which is not standardlized,then the IMS client has to face the problem of IMS USIM-AKA procedure which need RIL API to do AKA challenge again,so most works were done through RIL API layer,If you want to support some specific phone's IMS,analyzing the IMS API is quite important
So the major work has to be done for AOSP to standardlize&userspace IMS in AOSP is:
implemented some standard API to control the IMS service on or not in radio(it's not necessary I think just able to establish multiple PDN is enough)
some public API to configure the IMS PDN's APN
API to get PCO P-CSCF address from modem's signaling message
accessible to the IMS connection network interface
USIM AKS challenge API to comply the authencation of IMS domain
a userspace IMS client to do the IMS service functions

Related

Salvaging the hours and euros sunk

Since I'm having a couple of problems lately that will ultimately require me to hard-reset my TyTN in the near future, I figured I could document the steps I take to salvage the configuration as I go and learn this stuff.
My primary tool will be the Windows Mobile 5.0 Pocket PC SDK, especially the rapiconfig tool, that allows to process and query configuration information in the form of provisioning xml files.
RapiConfig sends the provisioning file to the device, processes it and saves the answer to RapiConfigOut.xml.
Lesson #1:
How to retrieve Messaging account settings, even if they appear to have vanished, using the EMAIL2 configuration service provider:
<!-- query-email2.xml -->
<wap-provisioningdoc>
<characteristic-query type="EMAIL2" recursive="TRUE" />
</wap-provisioningdoc>
C:\>RapiConfig.exe /p query-email2.xml
The result will be a list of manually configured messaging accounts, plus Hotmail and MMS.
The result will not include passwords (parm name="AUTHSECRET). To be later able and use the output file for restore, these params should be added for those accounts with (parm name="AUTHREQUIRED" value = "1") and the file should be saved under a meaningful name. Since MMS will be commonly setup by the ExtRom setup, it should be removed.
Next time we'll look at wireless connection setup.
Lesson #2:
How to enable RAPI access with manager privileges and retrieve WLAN settings.
The attempt to retrieve WLAN settings using the "Wi-Fi" characteristic will fail with "Access denied", because the Wi-Fi configuration provider requires manager level access, which is like Administrator on a PC.
By default, RAPI only uses user access level, and users can obviously not be allowed to manage WLAN settings using RAPI.
The SDK provides a way around this. Allowing RAPI access to manager-level features can be enabled by a security policy. This policy must be set using a signed configuration file.
The SDK contains a file "RapiAllowed.cpf" in the rapisecurity folder that can be used for this purpose.
However, first the certificate used to sign this file must be installed on the device.
For this, the SDKCerts.cab must be run on the device. This step might fail however, if the network provider chose to prevent the user from using unknown certificates.
The the RapiAllowed.cpf can be copied and run as well. There will be no feedback other than a SMS confirming the installation.
RAPI is a powerful interface, so the inverse, RapiRestricted.cpf, must be run before the device is brought into possible hostile enviroments (e.g. where some people might run Bluetooth scanners, USB ports on public computers, etc).
There is also a tool available from Microsoft called "Security Configuration Manager" that allows reviewing and resetting device security.
With RAPI security disabled, querying Wi-Fi is a piece of cake:
<!-- query.xml -->
<wap-provisioningdoc>
<characteristic-query type="Wi-Fi" recursive="TRUE"/>
</wap-provisioningdoc>
C:\>rapiconfig /p query.xml
The RapiConfigOut.xml will show all configured WLANs grouped into access-point-based and ad-hoc networks, with a characteristic for each network.
The network key is included as dummy string "****************" that needs to be replaced by the real passphrase.
I guess the next thing is to take a look into the network settings provided by CM_Networks and CM_GPRS_Entries.
HB_TyTN, very interesting stuff in your lessons, thanks for your effort
Also you may like to check rapi unlocker here:
http://forum.xda-developers.com/showthread.php?t=252356
Excellent thread! Will definitely keep mentioining it in my forthcoming, related articles!
About networks
The network thing in Windows Mobile seems pretty messed up. In an attempt to make things easier, safer and more automated, I think, Microsoft left anybody on the way.
Here is what I understand and (warning), I may be totally off.
There are four pre-defined networks Internet, Corp, WAP and Secure WAP.
Although those may have different names based on OS language and HTC, provider or user choosing, the IDs of these networks are fixed and can be looked up in the SDK/include/connmgr.h file. E.g. Internet, is identified by 436EF144-B4FB-4863-A041-8F905A62C572.
These networks describe different setups in terms of routing, security or proxy settings or are used from different applications (e.g. WAP/MMS).
Of all networks, one is selected as Internet (public) and another can be chosen as private under Select Networks in Advanced Connections.
Internet will provide TCP/IP only. Private will provide access to Windows shares, and may connect to the internet, usually thru a proxy.
The Connection Manager separates the world into Internet and private, based on the URL of the server.
Non local server names, e.g. www.xda-developers.com will be connected with the network specfied as Internet.
Yes, this includes any directly entered IP address, as the detection is based on the occurrence of a "." dot in the server name. The only way around this is to specify the URL in Settings, Connections, Advanced, Exceptions (using * as a wildcard if necessary).
Sole server names and except URLs will be connected thru the network designated as private.
With each network, connections, network cards and wireless networks can be associated, so that, finally, the connection manager uses or dials one of those connections based on the network it chose to use.
That's a long intro into lesson #3: Querying network information
I'll start resetting RAPI security to restricted, by copying RapiRestricted.cpf to the device, running it and checking the SMS message for success. This should prevent any actual messing up something.
Now to querying networks using the CM_Networks configuration provider.
<!-- query.xml>
<!--<!DOCTYPE wap-provisioningdoc SYSTEM "msprov.dtd">-->
<wap-provisioningdoc>
<characteristic-query type="CM_Networks" recursive="TRUE"/>
</wap-provisioningdoc>
C:\>rapiconfig /p query.xml
C:\>notepad RapiConfigOut.xml
The introduction above is to explain why this query does not reveal anything useful, other than a list network names, their ID and an obscure "Secure" value, which is 0 for all my connections.
I find it more interesting to query the CM_PPPEntries or the CM_GPRSEntries providers. They use a similar, yet somewhat convoluted schema.
Here are the notable parts:
DestID associates the entry with one of the networks I talked about and queried above.
Phone is the number to dial for the connection. For GPRS, this entry is set to "~GPRS!". I wonder who came up with that string.
Username and Password are obvious and so is RequirePw.
DnsAddr, AltDnsAddr are not out of the ordinary, and if SpecificIpAddr is "1", the ip address is in IpAddr, although I'd assume it is assigned dynamically in most cases.
DeviceType and DeviceName are set to "modem" and "Cellular Line" for the connections that use the phone network.
DeviceSpecificRAW is the most dangerous entry here, since it contains the parameters for the phone device in binary form. I wonder if there is any point in looking into those other than to inflict pain.
Some of the device parameters are set verbosely, so let's rather look at those. However, your provider may not like it if you modify these vigorously.
If BearerInfoValid is 1, BearerInfoService and BearerInfoSpeed are supposed to specify the type of modem and it's speed. Values in my case are 1 -Async Modem and 15 - 9600 v32, which goes to show that the latter value is rather useless, because I know I get more than that with both UMTS and GPRS. So better not tamper with these.
CompressionInfoValid and RadioLinkInfoValid are set to 0 in my case, so one can easily do without.
GRPSInfoValid is set to 1, but the only real interesting parameter is GPRSInfoAccessPointName, which must be set for the GPRS connection to know whom to talk to.
GPRSInfoQOSSettingsValid and GPRSInfoMinQOSSettingsValid are 0, which is sad, because I'm really not happy with my GPRS Quality of Service and would have loved to improve it.
Now, that was a joke. QoS is a way of classifying network traffic for bandwidth and latency and I doubt any provider supports it for Joe Average.
For all the parameters documentation is in the Smartphone SDK about the Telephony and TSP API structures.
Finally, a list of default URL mappings, as found in the CM_Mapping provider documentation.
*://*.*/* The Internet
*://*/* My Corporate Network
wsp://*/* WAP Network
wsps://*/* Secure WAP Network
To query my personalization settings, next time I'll dive into the registry and see what I can do with RAPI configuration queries.

BT Broadband Voice & WM6 Internet Calling

I have been attempting to get my HTC Wizard running WM6 working with BT Broadband Voice but I have hit an issue.......
I have managed to get a PC Softphone working with the service (3CX Phone) and have captured the SIP registration with a network Sniffer (Wireshark). I have replicated the settings into the provisioning XML file and installed this on the Wizard through the .CAB method described in another thread. However when using the Wizard I never get a response to any of the registration requests it sends. I have managed to get the Wizard working with a test-lab Asterisk server I have so I know the SIP client works.
The differences in the traces between the PC softphone and WM6 registrations seems to be a 'Branch' message that is sent in the SIP header that isn't sent from the Wizard:
From 3CX Phone:
Code:
P.WES=Dd<Qj(rWREGISTER sip:btsip.bt.com SIP/2.0
Via: SIP/2.0/UDP 192.168.100.60:5061;branch=z9hG4bK8019d72590f1db11be898000600fe800
From: <sip:[email protected]>;tag=16764
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 2 REGISTER
Contact: <sip:[email protected]>
Max-Forwards: 70
User-Agent: SIPPER for 3CX Phone
Expires: 0
Content-Length: 0
From WM6:
Code:
[email protected]/->2E>b)REGISTER sip:btsip.bt.com SIP/2.0
Via: SIP/2.0/UDP 192.168.130.1:5061
Max-Forwards: 70
From: <sip:[email protected]>;tag=04d52dd0d6;epid=0ceca78c1f
To: <sip:[email protected]>
Call-ID: 000098f4000012188099efbe2d87c701
CSeq: 1 REGISTER
Contact: <sip:192.168.130.1:5061thods="INVITE, INFO, OPTIONS, BYE, CANCEL, ACK"
User-Agent: RTC/1.5.5374
Event: registration
Content-Length: 0
I am thinking there may be some additional stuff that needs to go into the provisioning file but I am not sure what
Has anyone managed to get this working with BT Broadband Voice? If so what changesdid you have to make? Does anyone know what the 'Branch:' header is and whether this is implemented in the WM6 SIP stack?
Thanks
Andy
Replying to my own posts.....
Right after a bit more playing around and debugging pre and post firewall logs I think I have narrowed this down to being a NAT/Firewall issue.
I originally thought the issue was the lack of the 'Branch' message in the SIP header from the WM6 device - it isn't. It is in fact the 'Contact' header. With the WM6 registration packet this includes the source IP address of the SIP User/Server Agent (the Wizard's SIP Phone) which is using RFC1918 private addressing (sip:192.168.130.1:5061) as I am behind a router/firewall performing NAT. In the 3CX Phone registration it contains the phone number in the Contact header (sip:[email protected]). I checked on my router/firewall and this was not receiving any replies from the SIP Registrar/Proxy, however it was sending the Registrations. Luckily my Router supports SIP Protocol inspection so can intercept the SIP headers and modify them. I enabled this feature and now I can see the router changing the Contact header in the SIP Registrations and can see the replies returning from the SIP Registrar/Proxy
I'll continue testing this and let you know my results..........
Andy
Did you ever resolve this??? I've noticed the same thing, and my SIP provider keeps sending a 400 bad request when trying to register because the contact header isn't how it should be.
chavonbravo said:
Did you ever resolve this??? I've noticed the same thing, and my SIP provider keeps sending a 400 bad request when trying to register because the contact header isn't how it should be.
Click to expand...
Click to collapse
Yes it is resolved but only because my router supports SIP inspection. When my phone attempts to register with BT Broadband my router intercepts the registration packets and replaces the RFC1918 address in the 'contact' header with it's own 'real' IP address.
Andy

APN lookup based on SIM

Can someone explain on a technical level the process a modern smartphone goes through to establish the APN for a particular SIM? Does the SIM contain any information about the APN itself? I would prefer not to prejudice the explanation beyond those questions.
Thank you for any information you can provide.
AFAIK, vendors include a database of service providers and their associated APNs in the firmware. Once service provider is identified based on SIM (IMSI) and country/network code (MCC/MNC), connection parameters are configured based on the contents of the database.

New Voice Authentication Process

New Voice Authentication Process
Effective today, new security enhancements are in place to prevent unauthorized access to Sprint's network. Due to these new enhancements, you may encounter a device that is not recognized on the network after you have performed a ##RTN (786).
If you receive the message "Due to Error #16, your call has failed to complete" while placing a test call, you'll be required to contact a dedicated Care Team to have the device authenticated on the network.
For complete details, see the Voice Authentication Error M&P located at ISC > Service and Repair > Resources > ASC Methods and Procedures > Voice Authentication Error (5/2/11). ISCPortal Link: Voice Authentication Error (5/2/11)
What would this affect?
Its not like we could import other CDMA phones to begin with.
The only phone/ devices I'd even expect them to allow would be the Nokia N810w & the New $1,500 Qualcomm Phone... Maybe.
Noiro said:
What would this affect?
Its not like we could import other CDMA phones to begin with.
The only phone/ devices I'd even expect them to allow would be the Nokia N810w & the New $1,500 Qualcomm Phone... Maybe.
Click to expand...
Click to collapse
It looks like it would not do hands free activation anymore. It has to be called in so the device can retrieve the network settings so it can establish a data connection with the towers.

Privacy concerns on IPV4 implementation on Mobile networks.

Edit:
I have figured out that you can have logging softwares within the system however the logging system will log all details from NAT to the client but what it cant log is the Transversing of Port numbers at the gateway...so my question is do mobile operators keep log of these tables after the expired session. So here is the scenario, to backtrace. you would need the website host to give you the ip address, source and destination port, timestamp etc to start the process, the ISP will then look at its Logs to find out the traffic requests but map each of these requests, the ISP will need to know the table which was used for transversing but according to my knowledge the table gets deleted or releases the port number and ip address information after its timed out idle.
Anyone who can let me know if network operators keep a copy of this table?
Thanks
Gents,
I was looking for some information regarding IPV4 implementation on mobile networks. I have read in detail the IPV4 implementation on mobile networks and also IPV6 theoretical implementation on mobile networks. So here is my analysis so far – For IPV4 on mobile networks.
Mobile networks use NAT for giving dynamic IP addresses to its mobile device users who connect to the internet. On the outside the mobile network operator might have a few external static or dynamic IP addresses. You can get a static external ip address for your mobile device or group of devices but you will have to pay for it. GPRS runs on the back of GSM or UTMS (3G) but looking at GPRS implementation, you have GSGN, SGSN and mobile node all working in harmony in a triangular modulation however where I am lost is with CDRs (call detail record) which are sent by CGF (charging gateway function). Do these records keep a record of internal IP assigned to the mobile device for which the packet was transmitted or not? So far what I have found looking at the format of a CDR is it records the ip of GSGN but not the mobile device. What I am trying to understand is if the mobile users can be traced back from external ip all the way back like reverse lookup? Please note this question is in regards to IPV4 on mobile networks not IPV6.
Can someone please shed some light on this?
Many thanks in advance
V

Categories

Resources