Jabber on iPhone IOS registered as SIP phone on CME, outbound call fails. Link for configuration: https://supportforums.cisco.com/document/130876/cme-cisco-jabber-apple-iphone NOTE: Even though we have g711ulaw configured under voice register pool for jabber client, in the INVITE message from Jabber client we always see g729 codec. Config: ! voice register pool  1  registration-timer max 720 min 660  id mac 30F7.C583.E8D8  session-transport tcp  type CiscoMobile-iOS  number 1 dn 1  dtmf-relay sip-notify  Codec g711ulaw  username 6810 password cisco !   Received: INVITE sip:0531005065@192.168.131.253 SIP/2.0 Via: SIP/2.0/TCP 192.168.131.197:63438;branch=z9hG4bK3451ff19 From: "118216801" <sip:118216801@192.168.131.253>;tag=000000000000005800f06918-2783a723            To: <sip:0531005065@192.168.131.253> Call-ID: 00000000-00000025-57d72c94-6fafd599@192.168.131.197 Max-Forwards: 70 Date: Mon, 02 Mar 2015 08:57:41 GMT CSeq: 101 INVITE User-Agent: Cisco-SIPIPCommunicator/9.2.1 Contact: <sip:118216801@192.168.131.197:63438;transport=tcp> . . . v=0 o=Cisco-SIPUA 27969 0 IN IP4 192.168.131.197 s=SIP Call t=0 0 m=audio 16412 RTP/AVP 18 101 c=IN IP4 192.168.131.197 a=rtpmap:18 G729/8000  ----------------->g729 only a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv   ++++CME sends 488 Not Acceptable Media in response, since under voice register pool we had only g711 configured. SIP_UNACCEPTABLE_MEDIA_ERR Mar  2 08:30:29.458: //15204/37EECCC3BF4A/SIP/Error/sipSPIContinueNewMsgInvite: Unacceptable media indicated for INVITE Sent: SIP/2.0 488 Not Acceptable Media Via: SIP/2.0/TCP 192.168.131.197:63438;branch=z9hG4bK3451ff19 From: "118216801" <sip:118216801@192.168.131.253>;tag=000000000000005800f06918-2783a723 To: <sip:0531005065@192.168.131.253>;tag=46749EC-1C3A Date: Mon, 02 Mar 2015 08:30:29 GMT Call-ID: 00000000-00000025-57d72c94-6fafd599@192.168.131.197 CSeq: 101 INVITE Allow-Events: telephone-event Warning: 304 192.168.131.253 "Media Type(s) Unavailable" Reason: Q.850;cause=65 Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0   ++++After Disabling the Low bandwidth option on Jabber client. Config: ! voice register pool  1  registration-timer max 720 min 660  id mac 30F7.C583.E8D8  session-transport tcp  type CiscoMobile-iOS  number 1 dn 1  dtmf-relay sip-notify  voice class codec 1  username 6810 password cisco ! voice class codec 1  codec preference 1 g711ulaw  codec preference 2 g711alaw  codec preference 3 g729r8 ! +++We can see now,  Jabber client sending now all the configured codecs in the INVITE message to CME for outbound call. v=0 o=Cisco-SIPUA 27969 0 IN IP4 192.168.131.197 s=SIP Call t=0 0 m=audio 17388 RTP/AVP 0 8 18 101 c=IN IP4 192.168.131.197 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv   NOTE: Make sure we do "create profile" under "voice register global" and restart the jabber application, every time a change is made under "voice register pool"   ====Fix==== -Disable low bandwidth option on Jabber on iPhone IOS -We can keep low bandwidth option on jabber, but then g729 codec as to be there under voice register pool or voice-class codec applied on the voice register pool. So all the calls from/to Jabber client will be on g729 codec.   ... View more

This explains How Jabber Client(JC) Login works, Types of JC login and how to troubleshoot JC login issues.   Jabber Client Login and Login Issues   •Jabber Client Login •Two Types:       -Automatic Login       -Manual Login     Flow that the Jabber client uses to connect to services: In this doc we are not discussing WebEx Messenger service.   Note: Expressway also called collab-edge(one of type of login request from jabber client) which you would see in coming slides.           >>Automatic Login: Here you just need to enter the userid@domainname , when you click on Continue, below requests are sent from Jabber client to DNS SRV(service Record). First always Jabber client sends:  SRV_cisco-uds._tcp.example.com  (example.com is domain name like cisco.com,ccie.com, changes from company to company what they have configured) to get the CUCM IP address. If DNS query fails(i.e in DNS SRV there was record for this service type), then Jabber client sends below.   SRV_cuplogin._tcp.example.com------> To get CUPS(presence server) IP. If this fails, then below is sent.   SRV_collab-edge._tls.example.com------>Jabber client thinks that it is outside company network on WAN, so through internet it contacts VCS servers to contact Presence Servers.   >>If any one of the above succeeds(Jabber client sends http request to CUCM/CUPS IP), if the userid exists in CUCM/CUSP, then password would be prompted   If All fails, then we need to go for Manual Login(explained in coming slides)         >>Basically, in DNS SRV you define here for every “service type” of DNS query a resolution.               >>>Above shows, that a service record added for service _cisco-uds in DNS. So here, when Jabber client request for SRV_cisco-uds._tcp.ccie.com, the DNS SRV sends the CUCM IP to Jabber client. Also it sends the port number through which the Jabber needs to contact the CUCM Server. Priority:  If you are defining multiple CUCM IP, you can give priorities to each IP’s, based on priorities Jabber client contact those IP. Weight: You mention values here, if you mentioned same priorities for CUCM IP’s. Inside same priorities CUCM IP’s, one with more weight would be preferred.   Once Jabber gets, the IP address, it sends http request to CUCM IP along with the port number.   >>Similarly we add here for service “_cuplogin” for CUPS IP.             For Manual Login, click on Advanced Settings: -Automatic which is explained in previous slide(When Jabber starts initially for the first time after installation this is checked by default) -Cisco IM & Presence: when this is clicked you can select “user the default server(in this case jabber always sends SRV_cuplogin._tcp.example.com request to DNS SRV) or you can select “user the following server” with CUPS server IP(so jabber client contacts CUPS server) -WebEx Messenger: this is something managed Cisco cloud WebEx service, not discussed here. - Cisco CM 8.x or 9.x(or later) : when this is clicked you can select “user the default server(in this case jabber always sends SRV_cisco-uds._tcp.example.com request to DNS SRV) or you can select “user the following server” with CUCM server IP (so jabber client contacts CUCM server)     •When CUCM 8.x is chosen in previous side, the Jabber client(JC) just acts as a normal SIP phone(in 8.x there is no service profile option in end user page, so JC will not get details about it’s CUPS). JC will act as a deskphone mode with no chat options. •When 9.x is selected, JC gets CUPS details and it can be used for calling and chat purpose.               The above service profile selected in the end user page, as above configs. VM profile: VM options for jabber client Directory profile: Jabber client contact this when there is contacts search in jabber client. IM and presence Profile: contains Presence(CUPS) details.       ++ Below shows Tomcat security logs from CUCM, how CUCM checks in LDAP and authenticates this user. We can track this request from JC in logs with number 47(which is same for this user login process) and number keeps changing for other user login request. 2014-11-05 11:59:07,716 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - authenticateUserWithPassword: userName=nirmal2014-11-05 11:59:07,716 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - SearchUserDn for nirmal   2014-11-05 11:59:07,908 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - makeConnection: ldapURL[0]=ldap://10.106.89.210:389   2014-11-05 11:59:07,916 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - searchUserDn: performing search with userBase=CN=users, DC=ccie, DC=com, filter=(&(&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))(sAMAccountName=nirmal)), constraints=javax.naming.directory.SearchControls@c201cb   2014-11-05 11:59:07,921 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - authenticateUserWithPassword: calling auth as dn search is successful for user nirmal and the dn is CN=Nirmal Issac, CN=users, DC=ccie, DC=com   2014-11-05 11:59:07,938 DEBUG [http-bio-443-exec-47] impl.AuthenticationLDAP - auth: successful for dn CN=Nirmal Issac, CN=users, DC=ccie, DC=com           Events which occur, when JC contacts CUPS. ++ JC sends a SOAP Login request to CUPS. Client Profile Agent service on CUPS(which talks on SOAP) does two things here.       1) With the help of Tomcat security service on CUPS, it authenticates this user against Active directory(similarly as in CUCM) and gets this user info table, if this user exists in the                     database.        2) If the user exists, it does XMPP authentication, which checks whether this user as presence feature enabled(right to contact presence server), license etc.     Note: All these users are added in end user page in CUCM and synced through LDAP.   CUPC: Cisco Unified Presence Client(Jabber client, Android and other Devices Client Profile Agent: A service in CUPS which talks on SOAP.       ++ Once both the authentication is, as explained in previous slide note, the Client profile agent sends login response to JC as above and JC gets the config file(JC gets service profile config etc, similar to what we see in CUCM) Below is the example of outputs from Client Profile Agent service logs from CUPS: - Incoming SOAP request from JC to CUPS. 2014-11-12 10:26:43,969 DEBUG [http-bio-443-exec-23] soap.SoapServlet - Incoming Request<?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope" xmlns:SOAP-ENC="http://www.w3.org/2003/05/soap-encoding" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns1="urn:cisco:epas:soap"><SOAP-ENV:Body><ns1:login client-version="9.7.5.19280" client-type="CUPC" force="true"><ns1:username>nirmal</ns1:username><ns1:password>...</ns1:password></ns1:login></SOAP-ENV:Body></SOAP-ENV:Envelope> - Client profile checks this user agianst Active directory and authenticates this user with the help of tomcat security service in CUPS. 2014-11-12 10:26:44,155 INFO  [http-bio-443-exec-23] handlers.LoginHandlerNonSSO - doLogin:IMS login result is success for nirmal| IMS result code:0   -XMPP authentication 2014-11-12 10:26:44,159 DEBUG [http-bio-443-exec-23] imdb.ImdbLoginAccessorUtil - Insert session succeeded for userid:nirmal 2014-11-12 10:26:44,159 INFO  [http-bio-443-exec-23] handlers.LoginHandlerAbstract - SOAP Login was successful 2014-11-12 10:26:44,159 INFO  [http-bio-443-exec-23] handlers.LoginHandlerAbstract - doLogin:IMDB check completed & session created for user:nirmal. SessionKey is: cfd514ad-49e5-2e97-6a2c-64cdfda98cc8 2014-11-12 10:26:44,161 INFO  [http-bio-443-exec-23] soap.SoapServlet - SOAP request URI: /EPASSoap/service/v802014-11-12 10:26:44,162 DEBUG [http-bio-443-exec-23] soap.SoapServlet - Service version requested: v80     - Once the SOAP authentication is successful, the JC sends Token request(which acts as One Time password) to Client Profile Agent in CUPS. - Client Profile Agent responds back to JC with Token.   Through this Token JC starts conversation with other services in CUPS(XCP services).(Just like token based authentication)   Example from Client Profile Agent Service logs :   2014-11-12 10:26:44,278 DEBUG [http-bio-443-exec-23] ext.SoapRequestParserExt - Parsing SOAP request securely with a SecurityManager set 2014-11-12 10:26:44,279 INFO  [http-bio-443-exec-23] soap.SoapServlet - SOAP request for: get-onetime-password, version: v80 2014-11-12 10:26:44,285 INFO  [http-bio-443-exec-23] handlers.GetOneTimePasswordHandler - GetOneTimePasswordHandler: successful 2014-11-12 10:26:44,285 INFO  [http-bio-443-exec-23] handlers.GetOneTimePasswordHandler - GetOneTimePasswordHandler: Returning response for get-onetime-password   Example Logs: Connection Manager Logs: XCP connection Manager service receives Token from JC. 10:26:46.981 |076a1b70| debug| SASLManager.cpp:426 SASLManager::stepSession sending: <auth mechanism='CISCO-VTG-TOKEN' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>dXNlcmlkPW5pcm1hbEBjY2llLmNvbQB0b2tlbj05MTEyMTU=</auth>10:26:46.987 |07ce6b70| debug| SASLManager.cpp:259 xdbSessionCB: id=jtx_56   XCP Authentication Service Logs: - XCP Authentication Service receives msg from XCP Connection manager to verify the Token. 10:26:46.982 |00000000| debug| auth-1.10-106-89-222 AuthXCPComponent::onPacket() 10:26:46.982 |00000000| debug| AuthXCPComponent.cpp:211 AuthXCPComponent::onPacket(): <xdb from='cm-1_jsmcp-1.10-106-89-222' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='ccie.com' type='set'><auth mechanism='CISCO-VTG-TOKEN'   -Token Verification is successful 10:26:46.986 | debug| SXComponent::authenticateVTGToken(): Authentication success for userid: [nirmal@ccie.com] 10:26:46.986 | debug| SXComponent::_sendAuthSuccess(): JID: [nirmal@ccie.com] 10:26:46.986 | debug| SXComponent::_sendAuthSuccess(): [PACKET_OUT]: <xdb from='ccie.com' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='cm-1_jsmcp-1.10-106-89-222' type='result'><success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/><x><field var='FORM_TYPE'><value>http://www.jabber.com/schemas/saslprops.xsd</value></field><field type='text-single' var='sasl-service'><value>ccie.com</value></field><field type='text-single' var='sasl-mechname'><value>CISCO-VTG-TOKEN</value></field><field type='text-single'     XCP Authentication Service Logs: -XCP Authentication Service receives msg from XCP Connection manager to verify the Token. - 10:26:46.982 |00000000| debug| auth-1.10-106-89-222 AuthXCPComponent::onPacket() 10:26:46.982 |00000000| debug| AuthXCPComponent.cpp:211 AuthXCPComponent::onPacket(): <xdb from='cm-1_jsmcp-1.10-106-89-222' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='ccie.com' type='set'><auth mechanism='CISCO-VTG-TOKEN'   -Token Verification is successfully done by XCP Authentication Service. 10:26:46.986 | debug| SXComponent::authenticateVTGToken(): Authentication success for userid: [nirmal@ccie.com] 10:26:46.986 | debug| SXComponent::_sendAuthSuccess(): JID: [nirmal@ccie.com] 10:26:46.986 | debug| SXComponent::_sendAuthSuccess(): [PACKET_OUT]: <xdb from='ccie.com' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='cm-1_jsmcp-1.10-106-89-222' type='result'><success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/><x><field var='FORM_TYPE'><value>http://www.jabber.com/schemas/saslprops.xsd</value></field><field type='text-single' var='sasl-service'><value>ccie.com</value></field><field type='text-single' var='sasl-mechname'><value>CISCO-VTG-TOKEN</value></field><field type='text-single'     XCP connection Manager Informs JC about Token Authentication Successful. 10:26:46.987 |076a1b70| debug| SASLManager.cpp:272 _xdbSessionCB: <xdb from='ccie.com' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='cm-1_jsmcp-1.10-106-89-222' type='result'><success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/><x><field var='FORM_TYPE'><value>http://www.jabber.com/schemas/saslprops.xsd</value></field><field type='text-single' var='sasl-service'><value>ccie.com</value></field><field type='text-single' var='sasl-mechname'><value>CISCO-VTG-TOKEN</value></field><field type='text-single' var='JID'><value>nirmal@ccie.com</value></field></x></xdb>     From XCP Router Service Logs: - Connection Manager Initiates communication with the XCP Router Service 10:26:46.982 |f743bb70| debug| MIOByteSource.cpp:96 Got Buffer (249) <xdb from='cm-1_jsmcp-1.10-106-89-222' id='jtx_56' ns='http://jabber.com/protocol/sasl' to='ccie.com' type='set'><auth mechanism='CISCO-VTG-TOKEN' xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>dXNlcmlkPW5pcm1hbEBjY2llLmNvbQB0b2tlbj05MTEyMTU=</auth></xdb>           NOTE: CUP server contacts the LDAP server to authenticate the user who logs-in into the client by providing username/password. Client Profile Agent logs (commonly called epassoap logs) will show some 'Reason Codes' that indicate why the authenticaiton failure occurred. These are seen when LDAP is used to synchronize and also authenticate the end users in the UC environment. So the 'Action' item defined here has to be done on the AD server. Note that these codes are specific to only LDAP authentication step of overall login sequence and are helpful to conclude if the issue is with LDAP to start with.       •Suuccessfull Login: •2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e9 •2011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :0 • •The next step is to continue looking into epassoap(client profile agent service) logs to investigate further. • • •In the added notes below are few login issues related logs. •Also, you can click on File—create problem report in jabber client for login issues just to get an overview idea, but to get full idea about what’s the issue is we need to collect logs from Presence server.       Login Failures Account related 1) Wrong credentials   2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e9 2011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :1   Action: Collect $TOMCAT_HOME/logs/security/log4j/security*.log 2) Account hack locked   2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e9 2011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :3   Action: Reset user account 3) Admin has locked account   2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e9 2011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :2   Action: Reset user account 4) Account locked due to inactivity   2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e9 2011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler - IMS result code is :4   Action: Reset user account 5) Account LDAP inactive   2011-04-26 10:05:51,513 INFO http-8443-3 soap.LoginHandler - Created Authentication instance=com.cisco.security.ims.authentication.AuthenticationImpl@b492e9 2011-04-26 10:05:51,826 INFO http-8443-3 soap.LoginHandler -IMS result code is :5   Action: Reprovision user on LDAP & res-sync from LDAP             jabber login error code 14   Problem  Jabber Client received “Cannot communicate with the server” when login into Jabber for windows   Solution In jabber problem report we have seen the error code 14 when login. [JabberWerx] [IMPStackCap::Log::log] - [JabberWerxCPP.DLL]: JWLoginSink::OnError, lerr:14   For Error code 14, it is due ot the cups server is not defined using fqdn or ip address  client cups server under system->cluster topology, it is not using fqdn nor ipaddress   After changed server to ip address, then client is able to log         Few links: http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/jabber-windows/116334-trouble-jabber-problem-00.html   http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide.html           ... View more