So, trying to summarize the discussion.
Problem: Outgoing calls work, but incoming calls from SP, through SBCE, are being rejected by ASM with the error "
407 Proxy Authentication Required".
Reason: ASM does not recognize the request as coming from a SIP Entity, namely the SBCE.
Background: The meaning of the
407 Proxy Authentication Required is ASM saying "I do not trust you and will not process this request. But if you submit a new request and provide me with your login credentials and encrypted password, I'll check my database to see if you are legitimate. If you are, I'll process this new request."
The 407 response will contain instructions on how to combine your password with a long random NONCE number provided by ASM, and encrypt (actually hash) the result using MD5.
What is ASM trying to match: The ASM Entity Link identifies the acceptable Port and Transport, namely 5060 and TCP and whether the server is Trusted. The SIP Entity provides the IP address, namely 172.25.0.62. Reading the INVITE request, it looks to me like that is exactly what is being received by ASM.
Mistake(?): I think your Topology Hiding is not correctly assigned. It should be changing the domain of the address to whatever text is hidden by your red marker. Let's pretend it says: training.com. So, in the INVITE leaving SBCE going to ASM, the REQUEST-URI header should read: sip:+77*******
40@training.com instead it reads: sip:+77*******
40@172.25.0.63
ASM really wants to work with domain names, (not IPs). So on ASM's Listen Ports, if it sees a request coming on TCP port 5060, and the domain is an IP (not a name) it will change the domain to the one hidden by that red marker. Let's pretend that domain name is: phones.training.com. Notice that that particular domain is explicitly associated with SIP endpoints. So, when ASM goes to identify the source of the request, it will look for a phone match and not look for a match among the SIP Entities. Thus, thinking it might be phone, would respond with the 407 rejection.
++++++++++
Digression: The transport protocol on the outside SBCE (B1) interface must be UDP (unless you have a special arrangement). All SIP trunking service providers use UDP because they don't want the overhead of TCP (or even worse, TLS). The transport protocol on the trusted inside interface of the SBCE may be either TCP or TLS. It should not be UDP because CM does not support UDP on SIP trunks.
By the way, Avaya documentation asserts that A1 and B1 must be in different subnets. Yours are in the same subnet (.63 and .62). I think that's a security requirement (which means you can get it to work, but at your own peril), not a software-enforced requirement.
To answer your question, do you really need an SBC? Absolutely!!!! All SBCs perform at least three services: 1) Security device that protects your environment at Layer 7 in the OSI model (Historically, Firewalls have only provided protection up to Layer 4). (Would you ever knowingly connect your PC to the Internet without the protection of a Firewall?) 2) It performs Network Address Translation at Layer 7 (i.e. deep inside the SIP message, and not just on the outside of the envelope) and 3) SBCs adapt the SIP messages so they are understood by the recipient. There are four major types of adaptations that are often required.
Things you can ignore for now:
Having grooming enabled only becomes an issue when you have several active calls (I seem to recall the quantity is 16, 20, or maybe 32 calls.) Turn ON Grooming for ASM. Having Grooming enabled when it is not needed does not hurt you, so it doesn't matter if you also have it ON for the Service Provider side.
Media Ports are also a non-issue in this problem. The RTP media packets do not start flowing until the 200 OK is received (unless doing Early Media). This problem is occurring long before a 200 OK is likely to arrive.
I hope this is helpful.
