G`day,
I've got a few instances where the trunk is configured with Inbound Caller ID rules so that the received number can be easily used for speed dialing on the Yealink T23G phones. In a specific instance, if the caller ID nativley shows as +12221234567 then the Inbound caller ID rules will format for 92221234567 so that when speed dial is hit, the 9 will be included as is configured for outbound rules. It shows up on incomming caller ID with said format but no big deal currently.
The issue I'm having is when I've enabled OriginaterCallerID on the trunk's Outbound Parameters and the system tries to forward that Caller ID, it keeps the formatted Caller ID and sends it out which adds additional digits and throws off the caller ID of whoever is receiving the transfer. In the above case, the caller ID that was received would look like:
+91 22 2123 4567
Example rule set:
I figure no problem, I can just adjust the Outbound rules to re-format on the way out. I tried this:
The intent of this rule is to catch anything with the "+ 9 1 (area code) (number)" and only send out the 3rd and 4rth variable being the area code and number.
This worked on my tests but I apparently did not account for everything. I had a few complaint calls that paniced me into removing my new Outbound Caller ID rules and apparently broke the ability to include the "1" when dialing long distance numbers such as dialing: 9>1>areacode>number
I'm sure I just need to do more specific testing and get the actual results of the failed tests, what was dialed, and what was shown so I can include appropriate rules but it's a live 24/7 system and I would prefer to avoid as many tests as possible. I was hoping someone more expierienced in this issue might share some insight I've overlooked or yet to figure out.
Much appreciated,
I've got a few instances where the trunk is configured with Inbound Caller ID rules so that the received number can be easily used for speed dialing on the Yealink T23G phones. In a specific instance, if the caller ID nativley shows as +12221234567 then the Inbound caller ID rules will format for 92221234567 so that when speed dial is hit, the 9 will be included as is configured for outbound rules. It shows up on incomming caller ID with said format but no big deal currently.
The issue I'm having is when I've enabled OriginaterCallerID on the trunk's Outbound Parameters and the system tries to forward that Caller ID, it keeps the formatted Caller ID and sends it out which adds additional digits and throws off the caller ID of whoever is receiving the transfer. In the above case, the caller ID that was received would look like:
+91 22 2123 4567
Example rule set:
I figure no problem, I can just adjust the Outbound rules to re-format on the way out. I tried this:
The intent of this rule is to catch anything with the "+ 9 1 (area code) (number)" and only send out the 3rd and 4rth variable being the area code and number.
This worked on my tests but I apparently did not account for everything. I had a few complaint calls that paniced me into removing my new Outbound Caller ID rules and apparently broke the ability to include the "1" when dialing long distance numbers such as dialing: 9>1>areacode>number
I'm sure I just need to do more specific testing and get the actual results of the failed tests, what was dialed, and what was shown so I can include appropriate rules but it's a live 24/7 system and I would prefer to avoid as many tests as possible. I was hoping someone more expierienced in this issue might share some insight I've overlooked or yet to figure out.
Much appreciated,
