Problems with TS 8710 after 2.3 upgrade

[Nick Halbert-Lillyman]

We have upgraded out Telepresence Server 8710 to version 2.3 as there are issues with version 2.2 dialling CTS 1.9 units.  However, after the upgrade, the TS 8710 is no longer dialling using TIP to pre-configured CTS endpoints, meaning that CTS-3000s are only connecting with one screen.

E.g. under version 2.2, we had a "Legacy CTS endpoint" added to the TS 8710 with dial out paramaters - e.g. it would be configured as "Meeting Room 1" with a dial-out address of 123@domain.com.

When the TS 8710 dialled 123@domain.com, the list of participants would show "Meeting Room 1" and if it was a CTS-3000, would connect with all 3 screens.

Under version 2.3, when the 8710 dials 123@doman.com it just shows 123@domain.com under the list of participants, rather than matching the pre-configured "Meeting Room 1"  TIP/CTS endpoint.  In addition, it only connects with 1 screen rather than 3.  We have tried deleting and re-adding the endpoint but it still doesn't work.

Once we downgrade the TS 8710 to version 2.2 it starts working again.

Note that some documentation states that we don't need to manually add CTS units that run version 1.74 or later and it will work automatically, however we have found that this makes our units connect with only 1 screen, even if they are a 3-screen endpoint.

Any thoughts?

[luchand]

Which version of CUCM are you running? There is also a dependency on CUCM version to get auto-detection of CTS systems working - version 8.5 or later is required.

Also, how are you dialling out to the endpoints? Are you selecting them from the list of pre-configured participants, or just typing the address into the TS web interface manually?

[Nick Halbert-Lillyman]

Hi - we did a bit more testing on this today.

Our call path is: TP-Server > VCS-C > CUBE > CUCM.  We did some direct routing to bypass the CUBE (not viable for a permanent solution) and auto-detection started working.  Looks like the CUBE is stopping it from working unfortunately - we have logged a TAC case to get this fixed.

As for the TIP matching the pre-configured endpoints, we are just typing the URI and/or adding via TMS.  If we manually select the endpoint from the list on the MCU then it dials using TIP, but this means that it won't work for scheduled conferences from TMS so this isn't viable in the long term.

I can't see anything in the release notes about changed behaviour for matching pre-configured endpoints - is this an undocumented "feature" perhaps ?

I should note that this has been tested using all the versions shown as compatible in the CTS 1.9 compatibility matrix.

[luchand]

Yes, it is good to get auto-negotiation working, as relying on the preconfigured behaviour will limit your functionality moving forward. I suspect it will turn out ot be something to do with the CUBE rewriting the 'Contact' header in the SIP messaging, as this carries the information required to inititate TIP negotiation.

I think an 'undocumented feature' might be a good way of describing the behaviour you have been relying upon up until now With the improvements in the past few releases this should no longer be necessary - it is still possible to force TIP to pre-configured endpoints, but these will need to be added from the pre-configured endpoint list; matching of manually-entered input was never part of the intended design.

[Nick Halbert-Lillyman]

Thanks Luc - we'll have a play with header passing settings on the CUBE and see how we go to see if we can get auto-matching working.

[Michael Honeyman]

Hi Luc,

I operate the CUBE in this scenario. You were spot on about the Contact header. I created a sip-profile that appended x-cisco-tip and auto-matching started working. The sip-profile config was as follows:

voice-class sip-profiles 1

request INVITE sip-header Contact modify "$" ";x-cisco-tip"

!

voice service voip

sip

  sip-profiles 1

!

What I'm trying to achieve now is something that doesn't globally append x-cisco-tip to every egress INVITE message. I'd like to copy the string (where it exists) from the ingress INVITE Contact header into the egress INVITE Contact header, is this possible? I thought something like the below might do it:

voice-class sip-profiles 1

request INVITE peer-header sip Contact copy "x-cisco-tip" u01

request INVITE sip-header Contact modify "$" ";\u01"

!

voice service voip

sip

  sip-profiles 1

!

However the initial copy into variable u01 doesn't seem to match, so u01 remains blank.

TIA.

[Michael Honeyman]

Got it working, the final solution ended up looking like this:

voice-class sip-profiles 1

  request INVITE peer-header sip Contact copy "(;x-cisco-tip)"

  request INVITE sip-header Contact modify "$" "\u01"

voice-class sip-copylist 1

  sip-header Contact

!

voice service voip

  sip

   sip-profiles 1

   sip-copylist 1

!

Now I just need to find a reference document with all the TIP extension headers to make sure the CUBE is passing everything through.

Thanks again for pointing us to the Contact header Luc.