cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

TelePresence Conference displaying “number” instead of H.323 name/alias as the “Display Name”.

david.reid66
Beginner
Beginner

TelePresence Conference displaying “conference number” instead of H.323 name/alias as the “Display Name”.

 

A SIP registered system displays its SIP URI which is fine.

 

Currently none of the 100+ systems are set up as SIP and I don’t want to force everyone to dual register (SIP & H.323) unless absolutely necessary.

 

Have been testing with a couple of Tandberg  880MXP’s running F9.3.3 but other systems have the same problem.

 

Infrastructure: VCSc X8.5.3, TMS 14.6, Conductor (clusteredx2 {1 added to TMS}) XC3.0.3, TPS 4.2(4.18).

 

The calls connect and everything looks good except for the display name on screen.

 

Any ideas on how to fix this most appreciated.

 

Thanks,

 

David Reid

9 REPLIES 9

Typically when an H323 ID is applied to the codec, that becomes the display name used when identifying itself to other systems.  What do you mean by "conference number", can you explain?

Hi Patrick, As you say, the number should be the H.323 ID but it’s a very long “conference” number in this case: 1de31ad3-31dd-4715-8e81-8b1d6f7702a1

 

You get about half of the number on screen as it’s too long. It’s as if the Conductor/TPS doesn’t know what the endpoint is and uses the number format as shown. The number is different for every conference and for every endpoint you can see them in the VCSc logs (which I don't have at the moment).

 

The endpoint actually has an E.164 of 6106 and an H.323 ID of Leeds VC. It’s not SIP enabled.

 

I've attached a very small snapshot so you will get the idea.

 

If you add a SIP enabled endpoint in the same conference it displays its URI as you'd expect and not the random number.

 

Regards,

 

DR

Ah, sorry I missed the part where you said you were using Conductor.  What you're seeing is Conductor's GUID for that particular participant, and it's not unusual to see that for H323 calls.

I just did a couple different tests with a H323 only endpoint here, and it actually used the display name configured under SystemUnit.  I'm running TelePresence Server 4.2, Conductor XC4 and VCS X8.6.

Hi Patrick, I don't have access to the endpoints to check what the SystemUnit settings are but is that the same as the "System Name" field in an 880MXP as I've looked at a Tandberg MXP guide and can find the "System Name" but not the "SystemUnit" field? 

 

They have a range of endpoints from old Tandberg's (MXP's, C series, EX's) and newer Cisco MX's.

 

Thanks,

 

DR

 

 

 

 

 

The SystemUnit field applies to endpoints running TC software, ex: C/SX/MX Series codecs.  The testing I did was calling into a conference.

I'll do some more testing Monday when I return to work with an MXP codec, as well as scenarios where TMS is the initiator of the conference instead of the endpoint dialing in.

Dialing out from TMS, endpoints running TC based software appears to show the display name that is set in the SystemUnit configuration.  However, the MXP I tested with always showed the GUID that Conductor assigned that partcipant.

It would be interesting to see how the search history for this call looks like.

 

Did you try to set the h323id to a proper URI (including @yourdomain.com)

(you might want that anyhow, your search vcs rules might need some tweaking as well)

and set the following command on the MXP endpoint:

 

xConfiguration IdReport H323: H323Id

 

It still can be that there is no name send with the call but

by default mxp will present the e164 number first.

(though I just tried with F9.3.3 and it looked it always send out the h323id first).

 

Its at least worth giving a try. Besides that a dual or sip only registration cold be worth a try or contacting your Cisco partner/contact to file an enhancement request.

Please remember to rate helpful responses and identify

Hi Martin

The search history appears as you would expect to see it, it was a few days ago since I took a look at this, but basically we see a SIP call to the number@IP address, I believe the format is MCUconferenceID@VCS IP.

This call would then terminate as the registration would not be found, what we have had to do to work round this is apply a transform via a search rule pointed at the localzone which strips the IP address and allows the VCS to interwork the call to H.323.

I'm not sure if the interworking is having an impact here, I would expect not given that H.323 calls work OK for Patrick, I imagine you are running a similar setup, SIP only TPS (virtual TPS) and conductor establishing a call to a H.323 only endpoint.

SIP calls where the conference string dialled as such conferenceID@domainname show in the search history as that and appear to connect without issue, and we see the endpoint ID in these calls, registering and calling as SIP resolves the issue, however this is a rather large change to the deployment globally as the solution is currently H.323 only so a simpler solution is certainly preferable.

I'm not 100% certain about the actual call setup method given that TMS is establishing the call (or maybe more accurately providing the instruction to setup the call), does TMS tell conductor to tell the endpoint to call itself, then via the B2BUA routes the call to the MCU via VCS. I'd like to see a breakdown of the call setup steps, what part of the call setup goes where and what role does conductor play in the call setup, the GUID leads me to believe conductor has quite a high involvement in the call setup, outside of the standard H.323 and SIP call establishment.

Cheers

Dave

Think with Portals

Hi Patrick

We have checked the display names are configured as suggested, and also run the command Martin suggested below and we are still suffering from the exact same issue.

Cheers

Dave

Think with Portals
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: