Cisco Jabber 4.4 connect to Cisco Jabber 4.3

I have recently installed Cisco Jabber Video 4.4 (beta) on my home PC (windows XP and windows 7) I am unable to connect to Cisco Movi uses ( Movi 4.3) via my company Express server, any ideas re what I can do to overcome this issue would be much appreciated.

Share:

Replies

First thing I would look at is the VCS-E logs to see if you're actually hitting it at all, and if you are, what happens to the call from then onwards. (The error message you get when attempting to connect could give you a clue as well.)

Is it only JabberVideo (aka Movi) users you cannot connect to? Can you connect to other SIP devices, i.e. end-points behind the VCS-E at all?

If these do not connect, will they connect if using Alias@VCS-E_IP_address instead of Alias@domain?

If yes, then there is a DNS issue, most possibly lack of SRV records, if no, then there is countless possibilities involving VCS-E configuration incl. zone authentication setting etc etc etc.

I'll try it here when back at work Monday morning just to make sure it works as we're using 4.3 at work as well, and I know this works fine whether I'm external or internal - so I'll be surprised if this "free" version behaves any differently.

Edit:

Can you, in fact connect to any other sites, i.e. loopback.sip@cisco.com ? (This is a C20 which will loop your video back to you and it works fine for me).

Thanks Jens, our network admin team have looked at the VCS-E logs and have not been able to find a trace of the incominng call.In answer to your question, I will attempt to test the calls to end points as you have described, previous attempts direct to the device to the alias have failed. The call to the loopback alias worked so it definitely looks like our network envoirenmnet is the cause of the issue, I'm not sure if it helps, but I can successfully call from JabberVideo ( AKA Movi) via the VCS-E to any Jabber 4.4 user. If you are able to share any information regarding possible configuration issues in the VCS-E that would be appreciated.

I've just discovered, through further testing, that this "free version" will not play nice with the "not free version", at least not in my case - the calls will connect, but getting no video and only occasional one-way audio.

Did some investigating on our network too, made test call as you suggested to Alias@VCS-E_IP_addressand call was detected by express gateway logs but was unsuccessful, we checked further and found that SIP SRV tls has been disabled by our server team to support a trial of Microsoft Lync, is the tls service critical to the success of the Jabber call and do we need to disrupt the trial of Lync to test further?

I wanted to jump in to let you know that I had a call today from my enterprise client jabber4.3 to a free Jabber4.4 and had no issues. Video was great. We were connected at 768Kbps for about 30 minutes. My SIP TLS setting is on in the Expressway.

Edit: Just realised I've forgotten an important part of the puzzle...to get alias@IP_address to work you also need to implement a pre-search transform on the VCS-E which replaces IP_address with the domain of your choice;

Without any changes made to our corporate envoirenment I have now made some test calls from the 4.4 client on my home desktop to an MXP 1700 on our network and the call is intermittently successful, still no luck with calls from 4.4 to 4.3 though.Is there the slightest chance that given the 4.4. client has to register to the Cisco "cloud" that there are changes being made by Cisco in their "cloud" that are affecting results.

Yeah, well, it is a beta version, so Cisco would be making changes as different issues are discovered by different users.

What had me going was the fact I could not get 4.3 and 4.4 to play nice, but connecting the two together on our Codian MCU worked fine - and then finding out from other users that, no, 4.4 and 4.3 worked perfectly together.

Heh, I had one Cisco engineer telling me "no, it won't work" and another Cisco engineer telling me "yes, it works fine".

Turned out they were both correct, 4.4 and 4.3 works for at least some users, particulary if located in USA/Canada, whereas other users, myself included, have the "one way" media problem - which they are aware of.

At least now I know it's got nothing to do with what happens here at my end.

You might want to look at the logs of the unsuccessful calls though and see it you can see how far they get before they fail. Does the same thing happen with other sites, i.e. loopback.sip@cisco.com, or is it only happening when connecting to a device on your network - will 4.3 consistently connect from your external site to the 1700?

If it does, then you might have to do a wireshark trace between your 4.4 and the 1700 to see what's going on.

I just tried a few calls now from home, with very mixed results, only one connected, but no media - however, I don't know if the very wet weather we're having here at the moment could be partly to blame as I'm on ADSL at home, which mean copper, potentially flooded pits etc. We've had over 300mm of rain during the last few days and forecast is for up to 400mm more during the next 24 - 48 hours.

I know that the 4.4 version of Jabber Video is not in general avaliable for enterprice customers yet, but have you tried to test 4.4 versus 4.4 ( registered with enterprice settings ) ? Between 4.3 to 4.4 it basically is a lot of testing with the jabber video back-end. We have seen your error report, and we have not been able to re-produce at all in our network ( Oslo, Norway ).

Could I also ask wheter you provision ICE on your enterprice VCS network for the 4.3 clients? That would be of interest.

This is interesting indeed. We have done some tests indicating that the combination with ICE, Cisco Jabber 4.3 and a certain amount of packetloss, we migth end up with "No media" scenarios.

So, I would hope that either running 4.4 all over ( ICE issues are fixed ) or by disabeling ICE on the VCS provisioning for 4.3 would help. The reason it works great with the MCU in the middle, or to most other endpoints, is that the MCU does not announce ICE capabillities, hence the ICE interop issues will not be provoked. Crossing my fingers for this to make your deployment more successfull.

Thanks for the re-test, though the 4.4 version would probably not run with ICE towards the local VCS, since the setting was a 4.3 only provisioned setting. If you would like to isolate this test for 4.4 only, it should be easy to upload a 4.4 template to TMS by copying the 4.3 template, and edit the xml slightly.

The xml should be part of the official 4.3 distrubution zip. Rename the file to JabberVideoProvisioning4.4 and modify the first line of the xml ( replace 4.3 with 4.4) ( See under, and ups... there is still some pointer to Movi left )

This way you could enable ICE for the 4.4 clients only.

Again, just if you have time and would like to verify the 4.4 ICE implementation.

Apologies for not contributing over the last couple of weeks, I have been on holiday. I caught up with our Cisco account manager a few days ago to let him know that we continue to have issues with connecting calls from Jabber 4.4. to devices within our corporate envoiremnment using the domain addresses of the devices, also, that I have no issues when I replace the domain adress with the IP address of the VCE. My question was, is Cisco aware of any problem relating to their "cloud" DNS resolution that may be a factor in this issue? The answer from the account manager was, "yes, Cisco are aware of the issue, he admitted that Cisco seriously underestimated the interest in Jabber 4.4 and they had not provided sufficient back end infrastucture to support the trial, the errors that I am experiencing are re-produceable at other locations and that Cisco in due course will resolve the problem", he gave me no timeline for the fix. While I fully understand that we are taking part in a Beta tria, I must say I am disappointed with Cisco's performance and their ability or willingness to respond to issues identified in this discussion as well as the many others that are taking place with regard to Jabber.

I do hope Cisco get things locked down properly rather soonish so we won't run into more problems, as we're just about to roll out the free version to all of our undergraduate students - we're not a very big university, but we are still talking about around fifteen thousand potential users, and we need these to work well with around 3000 enterprise version users, being staff and postgrads. Shall be interesting to see how this evolves.

I've still to see any feedback from Cisco after uploading the VCS logs re our "ICE issue", so got no idea if this has been fixed. Guess I'll have to turn ICE back on again and see what happens...

These logs were really pointing giving some great hints of what migth causing the issues.

First of all, I would be interested in understanding your internal VCS deployment. It is clear from the logs that there is some mangeling with the ICE candidates in your VCS deployment, and hence, ICE does not negotiate succesfull.

In fact, this is good, because the issue we see is a effect of the failure of a succesfull ICE negotiation.

I notice that we have not recieved the SIP log from the free client. I noticed also that in your logs.ini file, you have two declarations of the SIP debug flagg. It seems that the client reads the first, and ignores the second. Hence, no SIP logs

It would be interesting to have the SIP log from the external client as well.

So, thanks for the logs, we will start look into this error scenario ASAP.

But at the same time, ICE seams to fail with the current VCS set-up. Do you have clusters ? Forced interworking etc. etc...

I am not a super expert in does and donts on VCS set-up. Maybe this would be worth a request through the VCS support channels ?