Caller ID Reformatting

[anco]

We have got the following issue with reformatting the CLI.

We are receiving: From: sip:1XXXXXXXXXX;verstat=[email protected]

Source Pattern: (1)(..........)(.*) Replace Pattern: 1\2 this wil result in: sip:[email protected]

We got the result, but we want to have a more general rule. Any phone number with any lenght before the ";" will remain and anything behind the ";" will be removed.

On the explanation page: https://www.3cx.com/docs/cid-reformatting/ I can't find an example for this.

Someone any ideas?

 

[NickD_3CX]

May I ask which provider you are using?

Generally providers put this information in the PAID header and leave the 'From' as is.

In regards to having a more general rule, I can't think of some way, but seeing that from the looks of it, the is a US number, you are lucky as the digit length a fixes 11-digits and always starting with a '1', so that should be fine.

 

[anco]

Thanks for your answer.

It is not just one specific provider in our case. We have several carriers sending us calls. Behind our switching platform we use 3CX for complex IVR solutions.

This is why we look for a more general rule as in some cases callers can be from other countries also.

 

[NickD_3CX]

Ok, do all carriers send the verstat value in the 'From' header?
Which are these providers?
Could you paste here a sample INVITE of each case where you are facing this?

 

[anco]

No, not all carriers, for now at least, but we want to be prepared in any case.

See example (anonymized) invite below:

INVITE sip:[email protected]:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP xxx.xx.xx.xxx:5060;branch=z9hG4bK3vvuft30egd7or3pdss0.1
From: <sip: 1xxxxxxxxxxx;verstat=[email protected];isup-oli=62>;tag=SDlbe0301-EXP6RA
To: <sip:[email protected]>
Call-ID: SDlbe0301-cb545f962c5621dc2d42210bdc5e0d4f-v300g00050
CSeq: 238144 INVITE
Max-Forwards: 63
Allow: INVITE,ACK,CANCEL,BYE,UPDATE, OPTIONS, REFER, PRACK
Accept: application/sdp,application/isup,application/dtmf,application/dtmf-relay,multipart/mixed
Contact: <sip:xxx.xx.xx.xxx:5060;transport=udp>
P-Early-Media: supported
P-Asserted-Identity: <sip:1xxxxxxxxxxx;verstat=[email protected]-business.com:5060>
Supported: precondition,geolocation
P-Charging-Vector: icid-value=a1bb62ae-8f4b-4d1f-9a7d-15ca31dae574
Diversion: <sip:[email protected]>;limit=10;reason=unconditional;counter=1
Content-Length: 258
Content-Type: application/sdp

 

[NickD_3CX]

With this INVITE, I see your point.

Usually providers leave at least 1 field untouched, which doesn't seem to be the case here, so I'm afraid I don't have a suggestion.
The best is what you have already tried.

I shall discuss this though and see if there is something we can do moving forward.

 

[anco]

Thanks