feat(call): add caller phone number to offer call event

[vinikjkkj]

#2154

[whiskeysockets-bot]

Thanks for opening this pull request and contributing to the project!

The next step is for the maintainers to review your changes. If everything looks good, it will be approved and merged into the main branch.

In the meantime, anyone in the community is encouraged to test this pull request and provide feedback.

✅ How to confirm it works

If you’ve tested this PR, please comment below with:

Tested and working ✅

This helps us speed up the review and merge process.

📦 To test this PR locally:

# NPM
npm install @whiskeysockets/baileys@WhiskeySockets/Baileys#add-pn-on-call-offer

# Yarn (v2+)
yarn add @whiskeysockets/baileys@WhiskeySockets/Baileys#add-pn-on-call-offer

# PNPM
pnpm add @whiskeysockets/baileys@WhiskeySockets/Baileys#add-pn-on-call-offer

If you encounter any issues or have feedback, feel free to comment as well.

[Salientekill]

Vini, would it be possible to detect calls in groups where the project number wasn't mentioned in the call?

[github-actions]

This PR is stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 14 days

[CDPPF]

Tested and working ✅

[purpshell]

is it known if we get caller_lid sometimes rather than pn? It would be good to be consistent with the addressingMode & Alt strategy

[github-actions]

This PR is stale because it has been open for 14 days with no activity. Remove the stale label or comment or this will be closed in 14 days

[purpshell]

Nevermind my earlier comment. I double checked there's no lid field

[CDPPF]

callerPn is returning incorrect trailing zero for 12-digit numbers (Brazilian Landlines)

Testing the new call.offer properties, I identified a consistent bug when receiving calls from Brazilian landlines. In Brazil, landlines have 12 digits (55 + DDD + 8 digits), while mobiles have 13.

The library is incorrectly appending a 0 to these 12-digit numbers (e.g., 551738025555 becomes 5517380255550).

I have verified that this is not a formatting error in my implementation, as the raw value of call.callerPn already contains the extra digit before any regex processing.

Likely Cause: It appears the decoder might be assuming a fixed buffer length for PNs or failing to trim padding bits when converting the Protobuf binary data to a string. Since 13-digit numbers are the "standard" for mobile-first regions, the 12-digit landlines are likely hitting an off-by-one error in the string conversion logic.

Impact: Any attempt to reply to this number using ${callerPn}@s.whatsapp.net fails because the JID becomes invalid.

[CDPPF]

callerPn is returning an incorrect trailing zero for Brazilian numbers (landlines and mobiles)

While testing the new call.offer properties, I identified a consistent bug when receiving calls from Brazilian numbers. In Brazil, landlines have 12 digits (55 + DDD + 8 digits) and mobiles have 13 digits.

However, the library is appending an extra 0 at the end of the number.
Examples:

Landline: 551738025555 becomes 5517380255550

Mobile: 5517999999999 becomes 55179999999990

I verified this is not a formatting error in my implementation, as the raw value of call.callerPn already contains the extra digit before any regex or processing.

Likely Cause: It appears the decoder might be assuming a fixed buffer length for PNs or failing to properly trim padding bits when converting the Protobuf binary data to a string. Since 13-digit numbers are common in mobile-first regions, both 12-digit landlines and 13-digit mobiles are ending up with an off-by-one error in the string conversion logic.

Impact: Any attempt to reply to this number using ${callerPn}@s.whatsapp.net fails because the generated JID becomes invalid.