When calls go out our long distance trunk (at&t provider) to at&t cell phones the calls show up as unknown number. If the call goes out our local trunk (level3) to at&t cell phones caller id shows up fine. We have Avaya communication manager 6.3 running in our environment. I had a lot of back and forth conversation between at&t wireless, Avaya, and at&t (trunk provider). Everyone wants to blame each other for not being able to pass caller-id but the root cause is the call screening: user provided not screened.
The solution is to change the call screening to user provided screened. This is the response Avaya is saying in their support documents.
Doc ID: SOLN129396
Version: 5.0
Status: Published
Published date: 08 Jul 2008
Updated: 03 Jun 2014
Author: Bartlomiej Jarmocik
Details
All CM / VCM releases
First observed Software release string:S8720-014-00.1.731.2 with update 15215
Feature working as designed.
Please see: ETSI EN 300 092-1 V2.1.1 (2001-02)
Problem Clarification
User checked the setup message going out from the trunk. Switch sends the screening message as 'user provided not screened'.
Please note that in the example below the Calling Party Number and Called Party Numbers have been replaced ficticious numbers.
<- PROGRESS IND local pvt netwk |cv pub netwrk serv local usr, ORIGination is non-ISDN
| Reference page(s): P-IV-4-82, P1-84, B-IV-B-18, A-62
| 1e=oct1 ie identifier: Progress Indicator
| 02=oct2 contents length: 2
| 81=oct3 coding standard: CCITT
| location:local pvt netwk |cv pub netwrk serv local usr
| 83=oct4 progress descrip: ORIGination is non-ISDN
<- CALLING PARTY NUMBER .................................. 18664628292
| Reference page(s): P-IV-4-34, B-IV-B-6, A-53, A3
| 6c=oct1 ie identifier: Calling Party Number
| 0b=oct2 contents length: 11
| 21=oct3 type of number: national
| numbering plan:ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
| 80=oct3a presentation ind: presentation allowed
| screening: user provided not screened <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
| 31=oct4 number digits: 18664628292
<- CALLED PARTY NUMBER .................................. 7204444000
| Reference page(s): P-IV-4-29, B-IV-B-4, A-51
| 70=oct1 ie identifier: Called Party Number
| 0b=oct2 contents length: 11
| 81=oct3 type of number: unknown type
| numbering plan:ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
| 30=oct4 number digits: 7204444000
The goal is send out a Calling Party Number (CPN) via the trunk which is not in the DID-range of that trunk. The provider does allow this only when the following condition is met: The Screening Indicator (in octet 3a) of the Setup-msg must either have the value 'network-provided' or 'user-provided, verified and passed'.
Currently the Screening Indicator is 'user provided not screened' and this causes the CPN to be ignored when it does not match the DID-range. The question is: Can the Screening Indicator be set to 'network-provided' or 'user-provided, verified and passed'?
Cause
Feature working as designed under legal restraints.
Solution
It is not allowed to send the CPN as user-provided-verified-and-passed or network-provided to the public network. The CPN send must always match so that nobody can send a CPN from anyone else.
This is used for law enforcement for malicious call traces.
The only way to send a non matching CPN is with the feature CLIP no screening and two number delivery for the trunks on provider side.In that case the CPN is verified by the provider and if it does not match, a second CPN is added to the SETUP message with the main number of the user and this one is network-provided.
The CPN you send stays in user-provided-not-screened
The provider will take an additional charge for this feature.
Legacy ID
KB01046036
The solution is to change the call screening to user provided screened. This is the response Avaya is saying in their support documents.
Doc ID: SOLN129396
Version: 5.0
Status: Published
Published date: 08 Jul 2008
Updated: 03 Jun 2014
Author: Bartlomiej Jarmocik
Details
All CM / VCM releases
First observed Software release string:S8720-014-00.1.731.2 with update 15215
Feature working as designed.
Please see: ETSI EN 300 092-1 V2.1.1 (2001-02)
Problem Clarification
User checked the setup message going out from the trunk. Switch sends the screening message as 'user provided not screened'.
Please note that in the example below the Calling Party Number and Called Party Numbers have been replaced ficticious numbers.
<- PROGRESS IND local pvt netwk |cv pub netwrk serv local usr, ORIGination is non-ISDN
| Reference page(s): P-IV-4-82, P1-84, B-IV-B-18, A-62
| 1e=oct1 ie identifier: Progress Indicator
| 02=oct2 contents length: 2
| 81=oct3 coding standard: CCITT
| location:local pvt netwk |cv pub netwrk serv local usr
| 83=oct4 progress descrip: ORIGination is non-ISDN
<- CALLING PARTY NUMBER .................................. 18664628292
| Reference page(s): P-IV-4-34, B-IV-B-6, A-53, A3
| 6c=oct1 ie identifier: Calling Party Number
| 0b=oct2 contents length: 11
| 21=oct3 type of number: national
| numbering plan:ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
| 80=oct3a presentation ind: presentation allowed
| screening: user provided not screened <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
| 31=oct4 number digits: 18664628292
<- CALLED PARTY NUMBER .................................. 7204444000
| Reference page(s): P-IV-4-29, B-IV-B-4, A-51
| 70=oct1 ie identifier: Called Party Number
| 0b=oct2 contents length: 11
| 81=oct3 type of number: unknown type
| numbering plan:ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
| 30=oct4 number digits: 7204444000
The goal is send out a Calling Party Number (CPN) via the trunk which is not in the DID-range of that trunk. The provider does allow this only when the following condition is met: The Screening Indicator (in octet 3a) of the Setup-msg must either have the value 'network-provided' or 'user-provided, verified and passed'.
Currently the Screening Indicator is 'user provided not screened' and this causes the CPN to be ignored when it does not match the DID-range. The question is: Can the Screening Indicator be set to 'network-provided' or 'user-provided, verified and passed'?
Cause
Feature working as designed under legal restraints.
Solution
It is not allowed to send the CPN as user-provided-verified-and-passed or network-provided to the public network. The CPN send must always match so that nobody can send a CPN from anyone else.
This is used for law enforcement for malicious call traces.
The only way to send a non matching CPN is with the feature CLIP no screening and two number delivery for the trunks on provider side.In that case the CPN is verified by the provider and if it does not match, a second CPN is added to the SETUP message with the main number of the user and this one is network-provided.
The CPN you send stays in user-provided-not-screened
The provider will take an additional charge for this feature.
Legacy ID
KB01046036