cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3880
Views
5
Helpful
7
Replies

Jabber Android 9.6 Phone Services

ruimartins1000
Level 4
Level 4

Hello all,

can we share all amoung us which Android Smartphones can really connect to the Phone Services?

In my scenario:

CUCM: 10.0.1.11900-2

IMP: 10.0.1.10000-26

Jabber Android: 9.6.1

Galaxy SII with v4.1.2 + Kernel: 3.0.31-889555 - Phone Services gets Connected - OK

Galaxy SIII Mini with v4.1.2 + Kernel: 3.0.31-1332988 - Phone Services Do NOT get Connected - NOK

Vodafone with v4.2.2 +  Kernel: 3.4.0-gb7c1b96-00208-gb0d13c4: Phone Services Do NOT get Connected - NOK

 

I've used the same user on all 3 devices.

 

From the logs I can see SIP interaction on Galaxy SII:

csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_MSG_SEND: ccsip_dump_send_msg_info: <10.2.101.100:5060>:REGISTE: <sip:100@10.2.101.100> :101 REGISTER::146e6c44-74770002-61b7377e-688b2af8@10.2.100.158
JABBER.TELEPHONY.AlarmService: [setAlarm] +++++ alarmSet= true tiem=33000
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_MSG_RECV: ccsip_dump_recv_msg_info: <10.2.101.100:0   >:100 Try: <sip:100@10.2.101.100>;tag=146e6c44747700021178f010-19f97741 :101 REGISTER::146e6c44-74770002-61b7377e-688b2af8@10.2.100.158
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_REG_STATE: 51/1, sip_reg_sm_process_event: SIP_REG_STATE_REGISTERING <- E_SIP_REG_1xx
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_MSG_RECV: ccsip_dump_recv_msg_info: <10.2.101.100:0   >:200 OK
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_REG_STATE: 51/1, sip_reg_sm_process_event: SIP_REG_STATE_REGISTERING <- E_SIP_REG_2xx
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-UI_API: ui_update_registration_state_all_lines: ***********ALL LINES UN-REGISTERED****************
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_CC_PROV: ccsnap_gen_deviceEvent: event type : DND
: INFO [0x58cc8210] [ftphonewrapper/CC_SIPCCService.cpp(2538)] [csf.ecc] [raiseDeviceEvent] - raiseDeviceEvent(evDNDChanged, 0x00000, [BOTMONOFRE] )
: INFO [0x58cc8210] [control/CallControlManagerImpl.cpp(2958)] [csf.ecc.evt] [notifyDeviceEventObservers] - DEVICE_EVENT: evDNDChanged, 0x00000, CC_STATE_IDLE, CC_CAUSE_NONE
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_DEVICE_MGR: registration_processEvent: Event EV_CC_INSERVICE, current State MGMT_STATE_REGISTERING
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_DEVICE_MGR: setState: new registration state = MGMT_STATE_REGISTERED
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_CC_PROV: ccsnap_gen_deviceEvent: event type : STATE

 

From the Logs on the other Devices this SIP interaction fails:

src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_MSG_SEND: ccsip_dump_send_msg_info: <10.2.101.100:5060>:REGISTE: <sip:100@10.2.101.100> :109 REGISTER::97a36381-79810006-75aff2f9-123cd88a@10.2.100.37
JABBER.TELEPHONY.AlarmService: [setAlarm] +++++ alarmSet= true tiem=33000
: ERROR [0x641bb608] [ftphonewrapper/CC_SIPCCService.cpp(1541)] [csf.ecc] [waitUntilSIPCCFullyStarted] - Timed out waiting for SIPCC Service to start.
: INFO [0x641bb608] [/softphonewrapper/CC_SIPCCDevice.cpp(40)] [csf.ecc.api] [getDeviceInfo] - getDeviceInfo()
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_DEVICE_MGR: registration_processEvent: Event EV_CC_STOP, current State MGMT_STATE_REGISTERING
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_CC_PROV: ccappClearAllCalls: called
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_DEVICE_MGR: setState: new registration state = MGMT_STATE_STOP_AWAIT_SHUTDOWN_ACK
csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_CC_PROV: ccsnap_gen_deviceEvent: event type : STATE
: INFO [0x6328cc70] [ftphonewrapper/CC_SIPCCService.cpp(2538)] [csf.ecc] [raiseDeviceEvent] - raiseDeviceEvent(evStateChanged, 0x00000, [BOTMONOFRE] )
: INFO [0x6328cc70] [control/CallControlManagerImpl.cpp(2958)] [csf.ecc.evt] [notifyDeviceEventObservers] - DEVICE_EVENT: evStateChanged, 0x00000, CC_STATE_OOS, CC_CAUSE_SHUTDOWN

 

Can you share your successful or not sucessful Jabber Android Smartphones?

 

thanks,

Rui

 

1 Accepted Solution

Accepted Solutions

Could you please try this workaround with your Samsung Galaxy SIII Mini that doesn't work ?

 

I just found a workaround (for Jabber for Android, iPhone works for me since the beginning) that worked for me and I think it's maybe useful and helpful. (I read about the kernel issues of many Android devices about large SIP messages over TCP).

The workaround is

- Copy the Phone Security Profile (under System > Security > Phone Security Profile) of "Cisco Dual Mode for Android - Standard SIP Non-Secure Profile" and name it Crazy Android - SIP Non-Secure Profile
- Force the Transport Type to "UDP" only. (change the Transport Type the default is TCP+UDP) and save.

 

- Apply the Phone Security Profile to the BOT device under "Protocol Specific Information" > Device Security Profile and select "Crazy Android - SIP Non-Secure Profile" (or whatever you named it).

 

- Save and apply settings. (I assume that the other parameters are correctly configured, you can have a Samsung Galaxy S4 or something supported like that which works perfectly since the beginning without any hassle, so to clone its config and just change the Security Profile parameter)

 

- Connect to Jabber for Android (the blue one! I tested this method with Jabber Voice (the green one) and it didn't work though).

- Login with Jabber for Android to IM & P.

- It worked for me (It's an Infinix Race Bolt Q smartphone, not very familiar hein)

 

 

I found some logic in this workaround since the problem is related to "large SIP messages over TCP". Turning this to UDP made things work for my chinese Android phone.

 

 

 

View solution in original post

7 Replies 7

chenriquevz
Level 1
Level 1

Hello, Rui.

 

Did you get to solve your problem?

 

I have the same problem here, however I only have a S2 (same OS and kernel as yours) and is not working!

 

06-04 15:38:59.828 16097 16365 E csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(330)| _SIPCCLoggerFunction | SIP : sipTransportCreateSendMessage : sippmh_write() SIP_UDP_MESSAGE_SIZE=2362
06-04 15:38:59.828 16097 16365 I csf.ecc.sipcc: src/softphonewrapper/CC_SIPCCService.cpp(336)| _SIPCCLoggerFunction | SIPCC-SIP_MSG_SEND: ccsip_dump_send_msg_info: <10.30.194.167:5060>:REGISTE: <sip:7701234@10.30.194.167> :101 REGISTER::bbcccd67-516c0003-1fd679b3-5e5c41be@10.25.226.110

06-04 15:38:59.828 16097 16363 I JABBER.TELEPHONY.AlarmService: [setAlarm] +++++ alarmSet= true tiem=33000
06-04 15:39:00.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:00.538 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:01.018 16097 16097 E SpannableStringBuilder: SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length
06-04 15:39:01.018 16097 16097 E SpannableStringBuilder: SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length
06-04 15:39:02.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:02.538 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:03.743 16097 16322 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:03.743 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:03.743 16097 16097 I threadipc.so: msgsnd:tid=1, msg=21
06-04 15:39:03.743 16097 16097 I threadipc.so: 0--set_bind_info::item = 4c5215e0, bind_count=17
06-04 15:39:03.743 16097 16097 I threadipc.so: msgsnd:tid=0, msg=21
06-04 15:39:04.323 16097 16329 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:04.323 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:04.323 16097 16097 I threadipc.so: msgsnd:tid=1, msg=21
06-04 15:39:04.328 16097 16097 I threadipc.so: 0--set_bind_info::item = 4c5215e0, bind_count=16
06-04 15:39:04.328 16097 16097 I threadipc.so: msgsnd:tid=0, msg=21
06-04 15:39:04.328 16097 16097 I threadipc.so: msgsnd:tid=1, msg=1792
06-04 15:39:04.328 16097 16097 I threadipc.so: HandleMessage: 12
06-04 15:39:04.328 16097 16097 I threadipc.so: richmsg<:func-5676ef5f, param:52881050, msg: 1792, (0,0)(0, 0)
06-04 15:39:04.328 16097 16097 I threadipc.so: invokemsg>
06-04 15:39:04.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:04.528 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:06.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:06.533 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:07.663 16097 16097 V SlidingMenu: changing layerType. hardware? true
06-04 15:39:07.688 16097 16097 V SlidingMenu: changing layerType. hardware? true
06-04 15:39:07.688 16097 16097 V SlidingMenu: changing layerType. hardware? true
06-04 15:39:08.098 16097 16097 V CustomViewBehind: behind INVISIBLE
06-04 15:39:08.123 16097 16097 V SlidingMenu: changing layerType. hardware? false
06-04 15:39:08.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:08.538 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:10.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:10.528 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:12.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:12.533 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:14.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:14.533 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:16.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:16.528 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:18.528 16097 16311 I threadipc.so: msgsnd:tid=1, msg=11
06-04 15:39:18.528 16097 16097 I threadipc.so: HandleMessage: 11
06-04 15:39:19.543 16097 16343 E         : ERROR [0x50766508] [ftphonewrapper/CC_SIPCCService.cpp(1541)] [csf.ecc] [waitUntilSIPCCFullyStarted] - Timed out waiting for SIPCC Service to start.
06-04 15:39:19.543 16097 16343 I         : INFO [0x50766508] [/softphonewrapper/CC_SIPCCDevice.cpp(40)] [csf.ecc.api] [getDeviceInfo] - getDeviceInfo()

Hello,

Not Yet. I've opened a TAC case and they give a polite answer refering the supported smartphones described on the Release Notes.

 

I'll try to use port 5061 as workaround stated on the v9.6.1 release notes, but that may or may not result.

I'll take some weeks to go back to that, but I'll post then.

 

for your case, SII is a supported phone so should be working. Can you share the CUCM and IMP version you are using? Do you have any working Android phone to be sure that the user you are logging in is correctly configured?

Rui

Hello,

I've tested smartphones from service provider, which are not listed on the RNs and where their Phone Services couldn't get registered. Now in a secure mode they can register using port 5061:

SIPCC-SIP_MSG_SEND: ccsip_dump_send_msg_info: <10.2.101.100:5061>:REGISTE: <sip:100@10.2.101.100> :113 REGISTER::27988b41-39c70008-54d858be-21fffe1a@10.2.100.35
(...)
SIPCC-SIP_DEVICE_MGR: setState: new registration state = MGMT_STATE_REGISTERED
 

I used the Jabber Android Server Setup Guide 9.6 to implement the secure mode and cliente configurations.

I've tested the normal setup with Galaxy S4 and S5, which are listed on RNs, successfully.

Resuming, at this point with 9.6 clients, if they are described on RNs as compatible devices there were no issues as expected.

With other smartphones where the Phone Services cannot get registered, using the 5061 port with the secure mode may seem a good workaround approach.

 

regards,

Rui

 

 

Could you please try this workaround with your Samsung Galaxy SIII Mini that doesn't work ?

 

I just found a workaround (for Jabber for Android, iPhone works for me since the beginning) that worked for me and I think it's maybe useful and helpful. (I read about the kernel issues of many Android devices about large SIP messages over TCP).

The workaround is

- Copy the Phone Security Profile (under System > Security > Phone Security Profile) of "Cisco Dual Mode for Android - Standard SIP Non-Secure Profile" and name it Crazy Android - SIP Non-Secure Profile
- Force the Transport Type to "UDP" only. (change the Transport Type the default is TCP+UDP) and save.

 

- Apply the Phone Security Profile to the BOT device under "Protocol Specific Information" > Device Security Profile and select "Crazy Android - SIP Non-Secure Profile" (or whatever you named it).

 

- Save and apply settings. (I assume that the other parameters are correctly configured, you can have a Samsung Galaxy S4 or something supported like that which works perfectly since the beginning without any hassle, so to clone its config and just change the Security Profile parameter)

 

- Connect to Jabber for Android (the blue one! I tested this method with Jabber Voice (the green one) and it didn't work though).

- Login with Jabber for Android to IM & P.

- It worked for me (It's an Infinix Race Bolt Q smartphone, not very familiar hein)

 

 

I found some logic in this workaround since the problem is related to "large SIP messages over TCP". Turning this to UDP made things work for my chinese Android phone.

 

 

 

ruimartins1000
Level 4
Level 4

Hello,

 

I don't have access anymore to a Galaxy SIII mini, but we've tried your workaround on a 

HTC Desire 600 dual
Android: 4.1.2
kernel: 1.20.401.3
 
That previously was not getting registered, and now it works as well.
 
Thanks for sharing, 'cause that solution is more simple.
 
Rui

ruimartins1000
Level 4
Level 4

Hello,

 

Just to add another phone that can get registered with the workaround provided by Mohamed:

SAMSUNG GT-I9070

Android version: 4.1.2

Kernel version: 3.0.31-1122398

UPDATE on Jabber Android Version:

With Jabber Android 10.5 the issue keep valid -> for non-supported devices the Phone Services do not register.

The good news is that the workaround kept valid.

regards,

Rui

Thank you very much Rui for your feedback :)

I have a kind of (weird I have to say) another problem when using Jabber for Android on unsupported devices.

Please find the issue in this thread https://supportforums.cisco.com/discussion/12286466/jabber-android-wont-connect-if-user-associated-standard-ccm-end-users-group#comment-9905126 and please tell me if you also face this problem or not. Please tell me (whether positively or negatively) if this problem occurs in your Jabber deployment and thanks.