Azure / Azure/communication-ui-library

Dial in users phone number not displayed in @azure/communication-common

Open
#6,064 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
204
Forks
84
Avg merge
1d 12h
Merged PRs (30d)
4

Description

**Describe the bug; what happened?**

When a PSTN participant joins a Teams meeting, their display name in the video gallery and participant list shows an internal Teams telephony routing identifier (e.g. `d14d0b25-85ea-418e-94be-6ee3c582c565_9f13c5a086df4950a061d2fba6edff04`) instead of their phone number (e.g. `+351 *** *** 595`).

This is caused by two compounding issues:

1. `buildPhoneNumberIdentifier` in `@azure/communication-common` naively treats everything after the "4:" prefix as the phoneNumber field. Teams uses `"4:"` as a prefix for internal PSTN routing IDs (format: `4:_`), not just for real PSTN phone numbers (format: `4:+`). This means `identifier.phoneNumber` ends up as a GUID-based string rather than the human-readable phone number.

2. `_updateUserDisplayNames` in `@azure/communication-react` (`calling-component-bindings/src/utils/callUtils.js`) unconditionally replaces `participant.displayName` with `participant.identifier.phoneNumber` for any `PhoneNumberIdentifier`:
```ts
// https://github.com/Azure/communication-ui-library/blob/main/packages/calling-component-bindings/src/utils/callUtils.ts#L130
if (isPhoneNumberIdentifier(participant.identifier)) {
return { ...participant, displayName: participant.identifier.phoneNumber };
}
```

This discards the actual phone number that Teams correctly populates in `participant.displayName` (e.g. `"+351 *** *** 595"`), replacing it with the internal routing ID from the identifier.

The `onFetchProfile` callback (callAdapterOptions.onFetchProfile) cannot work around this because `_updateUserDisplayNames` runs in the selector layer after the adapter state modifier, overwriting whatever `onFetchProfile` set.

**What are the steps to reproduce the issue?**

Create a Teams meeting using loadCallComposite or loadCallWithChatComposite from `@azure/communication-react/javascript-loaders`.
Have a participant join the meeting via PSTN dial-in (phone call).
Observe the video tile and participant list for the PSTN participant.

**What behavior did you expect?**

The PSTN participant's display name should show their phone number (e.g. +351 *** *** 595), which is correctly available in `participant.displayName` on the adapter state and in the `defaultProfile.displayName` argument of the `onFetchProfile` callback.

**If applicable, provide screenshots:**

Image

**In what environment did you see the issue?**

@azure/communication-react npm package version: 1.32.0

@azure/communication-calling npm package version: 1.43.1

@azure/communication-chat npm package version: 1.6.0

OS & Device: macOS on Mac Mini M4 Pro

Browser: Google Chrome

Browser Version: 150.0.7871.124 (Official Build) (arm64)

**Is there any additional information?**

The fix should be in `_updateUserDisplayNames` (`callUtils.js`) — it should fall back to `participant.displayName` when `identifier.phoneNumber` does not resemble a real phone number (i.e. does not start with "+"):

Alternatively, `buildPhoneNumberIdentifier` in `@azure/communication-common` could be updated to strip the `_` suffix and validate that the result looks like a phone number before storing it in the phoneNumber field.

Contributor guide

Open the contributing guide

Research direction

Start in packages/calling-component-bindings/src/utils/callUtils.ts at _updateUserDisplayNames, then inspect buildPhoneNumberIdentifier in @azure/communication-common. Reproduce through loadCallComposite or loadCallWithChatComposite with a PSTN participant and verify that a routing identifier does not replace the existing phone-number display name in the video tile and participant list.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, react, typescript
Domain
audio-video-rtc, frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
70/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.