Instructor of Avaya
Instructor
thread690-1746822
Problem:
When using traceSM, and having enabled the option to display Call Processing, administrators frequently see the message Remote Host is Not Trusted.
The message is not unique to any type of SIP Request, meaning it is observed after INVITE, SUBSCRIBE, REGISTER, etc.
Digging into the ASM Call Processing message provides this explanation: "The remote host is not trusted. This could indicate P-AV-Transport header does not contain th."
This is behavior is expected & desirable, and (usually) does not indicate a problem.
Cause:
To state the obvious, this message indicates the SIP request came from a User Agent that ASM does not trust.
SIP Requests from a SIP Entity across a Entity Link that is flagged (by default) as "trusted" never experience this. Similarly, requests sent to a SIP telephone are trusted (presumably because ASM trusts itself?)
For security reasons, ASM does not trust any request that comes from a SIP endpoints.
Background
Notice that the request was rejected with a 407 Proxy Authentication Required. Within that rejection, ASM provides the information the untrusted UA needs to properly resubmit the request. See the header: and Proxy-Authenticate
The SIP telephone will repeat the SIP request, this time including the the phone's credentials, namely its extension number (e.g. 1001@training.com) and its password (e.g. 123456) but in an encrypted format. See the header: Proxy-Authentication
Assuming the credential are valid this repeated request will be accepted by ASM and processed.
Geeky Detail
Built into Aura Session Manager (ASM) is the security module (SM-100) (sometime referred to as the "Asset"). The SM-100 is responsible for: 1) decrypting TLS packets into TCP for hand off to the ASM's Application Server module (and vice versa for outgoing packets), 2) providing a firewall to protect ASM, and 3) validating communication.
If the SM-100 validates the communication, it injects the header P-AV-Transport header into the request, and includes the parameter "th" that means the request is from a "Trusted Host." Then the SM-100 forwards the request off to the Application Server module within ASM.
Troubleshooting Detail
The SM-100 will not validate the communication from a SIP Entity (e.g. CM or SBC) if there is a mis-match between the configured transport protocol (TLS/TCP/UDP) on the Entity Link versus what is actually received.
Problem:
When using traceSM, and having enabled the option to display Call Processing, administrators frequently see the message Remote Host is Not Trusted.
The message is not unique to any type of SIP Request, meaning it is observed after INVITE, SUBSCRIBE, REGISTER, etc.
Digging into the ASM Call Processing message provides this explanation: "The remote host is not trusted. This could indicate P-AV-Transport header does not contain th."
This is behavior is expected & desirable, and (usually) does not indicate a problem.
Cause:
To state the obvious, this message indicates the SIP request came from a User Agent that ASM does not trust.
SIP Requests from a SIP Entity across a Entity Link that is flagged (by default) as "trusted" never experience this. Similarly, requests sent to a SIP telephone are trusted (presumably because ASM trusts itself?)
For security reasons, ASM does not trust any request that comes from a SIP endpoints.
Background
Notice that the request was rejected with a 407 Proxy Authentication Required. Within that rejection, ASM provides the information the untrusted UA needs to properly resubmit the request. See the header: and Proxy-Authenticate
The SIP telephone will repeat the SIP request, this time including the the phone's credentials, namely its extension number (e.g. 1001@training.com) and its password (e.g. 123456) but in an encrypted format. See the header: Proxy-Authentication
Assuming the credential are valid this repeated request will be accepted by ASM and processed.
Geeky Detail
Built into Aura Session Manager (ASM) is the security module (SM-100) (sometime referred to as the "Asset"). The SM-100 is responsible for: 1) decrypting TLS packets into TCP for hand off to the ASM's Application Server module (and vice versa for outgoing packets), 2) providing a firewall to protect ASM, and 3) validating communication.
If the SM-100 validates the communication, it injects the header P-AV-Transport header into the request, and includes the parameter "th" that means the request is from a "Trusted Host." Then the SM-100 forwards the request off to the Application Server module within ASM.
Troubleshooting Detail
The SM-100 will not validate the communication from a SIP Entity (e.g. CM or SBC) if there is a mis-match between the configured transport protocol (TLS/TCP/UDP) on the Entity Link versus what is actually received.
