Hello,
is "Alternate Line Service (ALS)" supported by XDAII?
kingstone99
Related
Hi,
I have developed a test app to communicate between two Pocket PC's over GSM using the TAPI line functions. I want to send data over the line (The Cellular Line device's devcaps says that it supports 9600 baud). I open the line on both ends with:
lReturn = ::lineOpen(m_hLineApp, m_DeviceID, &m_hLine, m_ApiVersion,0, 0, LINECALLPRIVILEGE_OWNER, LINEMEDIAMODE_DATAMODEM | LINEMEDIAMODE_INTERACTIVEVOICE, 0);
It works fine when I make a normal voice call using LINEMEDIAMODE_INTERACTIVEVOICE call i.e. I can talk at both ends. However if I change this to LINEMEDIAMODE_DATAMODEM, although I get the LINE_REPLY message back, I donot get the LINECALLSTATE_OFFERING message, so I cannot answer the call. I get no messages at all on the receiving end's callback. I am using the "Cellular Line" device.
Is there any other parameter that I should know about when making a data call ?
I am developing in C++ using MFC (MSVC++ 2005) (Windows Mobile 2003).
Mark.c
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
Hi,
as far as I know, Windows Mobile for Smartphone supports the "Alternate Line Service", a feature allowing one to have two phone numbers on one contract and switch between these numbers. The necessary menus for this service are only visible if the service has been activated in the CSP of the simcard.
However, eplus (Germany) offers this service, but does not activate the simcard. Therefore it is necessary to activate the menus manually, which could be done on e.g. Nokia phones by so called CSP-override.
I wonder if it is possible to activate these menus in windows smartphone as well, e.g. by a registry hack?
Thanks,
Chris
Every time somebody phones, it says private number. How can i change so i can see whos calling.
japes10 said:
Every time somebody phones, it says private number. How can i change so i can see whos calling.
Click to expand...
Click to collapse
Either the calling parties were using the CLIR service (Calling Line ID Restriction), either you are deactivating the CLIP service (Calling Line ID Presentation).
To check for the CLIP service, install my app Advanced Call Settings, select 'Line ID' tab, select CLIP, and tap the button Interrogate.
To activate it again, tap the button Activate.
You may ask your service provider for the availability of the service (it may depends on your contract with the service provider, or the local policy...)
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