incoming call from SP

[Dmitriy_Nik]

Hi all. I have received a SIP IP-to-IP trunk from the provider without authentication. I configured it according to the scheme AvayaCM=>AvayaSM=>AvayaSBCe=>Provider side. Outgoing calls work, but the problem is with incoming calls. When dialling a number the call gets stuck at Avaya SM with the error "SIP/2.0 407 Proxy Authentication Required". But there is no authentication on Avaya SM. Please help me understand what could be causing this.
172.25.0.7 Avaya SM
172.25.0.62 Avaya SBC
172.25.0.9 CM
tracesbc

traceSM

 

[kyle555]

Just for yuks, in the far right of either the SIP entity or entity link, there's a tick box for trusted. I've never not had that box ticked...

 

[kyle555]

.

 

[Dmitriy_Nik]

Thank you all for the advice on my question. I solved the problem by removing SM from the chain, leaving only CM and SBC.

 

[kyle555]

That's working around the problem...not solving it. That's not a supported configuration, but if you're just labbing around for fun, go nuts.

 

[Dmitriy_Nik]

That's working around the problem...not solving it. That's not a supported configuration, but if you're just labbing around for fun, go nuts.

I'm trying to figure out why SM is giving an error, but I can't find out where to look. All entities are created, routes are specified....

 

[Instructor of Avaya]

Sorry, I should have been more specific about my suggestion for fixing Topology Hiding. First, put back the line that Overwrites the domain in the Request-Line.

You should have two Topology Hiding (TH) statements. The first one, "Default" contains no changes. In other words, the Action for all Headers is "Auto". The second TH is the one you are showing above (with the change suggested in my first paragraph). Let's call it "ASM Topo Hiding."

You should have two Server Flows. One that has the Service Provider's proxy server as the target. In that one the TH should be the default. The second Server Flow has Aura Session Manager as the target. That one should use the ASM Topo Hiding. (And I think that is the original mistake that needs to be fixed.)

Good luck!

 

[kyle555]

Did you check for that trusted tick box on the entity or entity link? First thing in your call processing trace is that the remote host is not trusted. Could be that.

 

[Dmitriy_Nik]

Did you check for that trusted tick box on the entity or entity link? First thing in your call processing trace is that the remote host is not trusted. Could be that.

Yes , I did. All entries are trusted in asm sip and sbc sip.That's why I can't understand why it lets outgoing calls through, but not incoming calls.

 

[Dmitriy_Nik]

Sorry, I should have been more specific about my suggestion for fixing Topology Hiding. First, put back the line that Overwrites the domain in the Request-Line.

You should have two Topology Hiding (TH) statements. The first one, "Default" contains no changes. In other words, the Action for all Headers is "Auto". The second TH is the one you are showing above (with the change suggested in my first paragraph). Let's call it "ASM Topo Hiding."

You should have two Server Flows. One that has the Service Provider's proxy server as the target. In that one the TH should be the default. The second Server Flow has Aura Session Manager as the target. That one should use the ASM Topo Hiding. (And I think that is the original mistake that needs to be fixed.)

Good luck!

Tried it, but nothing changed.

 

[Instructor of Avaya]

It appears you did the opposite of what I was suggesting.

In the Server Flow going to KCELL, the Topology Hiding should be: Default

In the Server Flow going to ASM, the Topology Hiding should be: ASM

 

[Dmitriy_Nik]

It appears you did the opposite of what I was suggesting.

In the Server Flow going to KCELL, the Topology Hiding should be: Default

In the Server Flow going to ASM, the Topology Hiding should be: ASM

, it was the middle of the night, I got confused. I corrected it, but the situation hasn't changed.

 

[Instructor of Avaya]

I understand how easily that sort of mistake can happen--I've made my fair share of 2:00 AM oops.

I believe the fundamental problem is that your SBCE is still not applying Topology Hiding to the traffic going to ASM. I'm looking at the Server Flow for KCELL you presented above. It looks misconfigured and therefore what needs to be changed to fix the problem.

When I teach SBCEs, I recommend that students put the source and destination in the flow name because it makes clearer what the settings should be. That is because all the settings are about the destination, with the exception of the Routing Policy which is about the source.

Here's what I think it the settings should be:

Name= From KCELL to ASM *** So this flow is focused on sending traffic to Aura Session Manager***
Server Config= ASM *** The destination for this Flow's traffic is ASM. ***
Received Interface= B1 *** The SBCE will receive the SIP Signaling from KCELL on this interface ***
Signaling Interface= A1 *** The SBCE will send the SIP to ASM from this Interface ***
Media Interface = A1 *** The SBCE will send the RTP to CM's G450 or AAMS from this Interface ***
Policy= ASM Policy *** The best design is to create a uniquely named Policy Group for each flow. It's a long explanation why. ***
Routing Policy= KCELL_RP *** This entry always points back to the source of the traffic. It "anchors the opposite side of the flow. Isn't that mindboggling? ***
Topology Hiding = ASM_TH *** This entry is what changes the Domain in the addresses to something like "training.com", which is what ASM really likes ***

The other flow should look like this:

Name= From ASM to KCELL *** So this flow is focused on sending traffic to KCELL ***
Server Config= KCELL *** The destination for this Flow's traffic is KCELL. ***
Received Interface= A1 *** The SBCE will receive the SIP Signaling from ASM on this interface ***
Signaling Interface= B1 *** The SBCE will send the SIP to KCELL from this Interface ***
Media Interface = B1 *** The SBCE will send the RTP to KCELL from this Interface ***
Policy= KCELL Policy *** The best design is to create a uniquely named Policy Group for each flow. ***
Routing Policy= ASM_RP *** This entry always points back to the source of the traffic. Trust me on this***
Topology Hiding = KCELL_TH *** This entry is what changes the Domain in the addresses to an IP, which is what everyone needs, except for Avaya ***

I'm optimistic that this will fix the problem.

 

[Dmitriy_Nik]

I understand how easily that sort of mistake can happen--I've made my fair share of 2:00 AM oops.

I believe the fundamental problem is that your SBCE is still not applying Topology Hiding to the traffic going to ASM. I'm looking at the Server Flow for KCELL you presented above. It looks misconfigured and therefore what needs to be changed to fix the problem.

When I teach SBCEs, I recommend that students put the source and destination in the flow name because it makes clearer what the settings should be. That is because all the settings are about the destination, with the exception of the Routing Policy which is about the source.

Here's what I think it the settings should be:

Name= From KCELL to ASM *** So this flow is focused on sending traffic to Aura Session Manager***
Server Config= ASM *** The destination for this Flow's traffic is ASM. ***
Received Interface= B1 *** The SBCE will receive the SIP Signaling from KCELL on this interface ***
Signaling Interface= A1 *** The SBCE will send the SIP to ASM from this Interface ***
Media Interface = A1 *** The SBCE will send the RTP to CM's G450 or AAMS from this Interface ***
Policy= ASM Policy *** The best design is to create a uniquely named Policy Group for each flow. It's a long explanation why. ***
Routing Policy= KCELL_RP *** This entry always points back to the source of the traffic. It "anchors the opposite side of the flow. Isn't that mindboggling? ***
Topology Hiding = ASM_TH *** This entry is what changes the Domain in the addresses to something like "training.com", which is what ASM really likes ***

The other flow should look like this:

Name= From ASM to KCELL *** So this flow is focused on sending traffic to KCELL ***
Server Config= KCELL *** The destination for this Flow's traffic is KCELL. ***
Received Interface= A1 *** The SBCE will receive the SIP Signaling from ASM on this interface ***
Signaling Interface= B1 *** The SBCE will send the SIP to KCELL from this Interface ***
Media Interface = B1 *** The SBCE will send the RTP to KCELL from this Interface ***
Policy= KCELL Policy *** The best design is to create a uniquely named Policy Group for each flow. ***
Routing Policy= ASM_RP *** This entry always points back to the source of the traffic. Trust me on this***
Topology Hiding = KCELL_TH *** This entry is what changes the Domain in the addresses to an IP, which is what everyone needs, except for Avaya ***

I'm optimistic that this will fix the problem.

II decided to try to build this circuit via tls, but when I got to the finish line I found out that there is no encryption license. I'll try to find one tomorrow.
Found an interesting article, maybe this is my situation

Sign On

 

[saev]

Hi,​

sorry to revive this old case of yours. I just stumbled upon this. Did you solve the problem?
If not, I would suggest you, to check whether you have included the domain that is coming from SBC in SMGR > Routing > Domains. This can also be a reason, why SM doesn't allow Invites from "unknown" sources even if you have them as trusted in your SIP Entities list. Having the domain in Topology Hiding is only one part. Accepting the domain name on SM the other.

Additionally from what I have also seen:
It is wise to block incoming OPTIONS from SP on SBC and do not let them go through to your SM, via Signaling policy. In rare cases this can have bad behavior on calls where SPs send OPTIONS in the middle of a call leg to check whether your SBC is still there or not. If you forward OPTIONS to SM in this case, these will also be forwarded to CM which will not handle it correctly and this can abruptly end calls from SP end.

 

[Dmitriy_Nik]

Hi,​

sorry to revive this old case of yours. I just stumbled upon this. Did you solve the problem?
If not, I would suggest you, to check whether you have included the domain that is coming from SBC in SMGR > Routing > Domains. This can also be a reason, why SM doesn't allow Invites from "unknown" sources even if you have them as trusted in your SIP Entities list. Having the domain in Topology Hiding is only one part. Accepting the domain name on SM the other.

Additionally from what I have also seen:
It is wise to block incoming OPTIONS from SP on SBC and do not let them go through to your SM, via Signaling policy. In rare cases this can have bad behavior on calls where SPs send OPTIONS in the middle of a call leg to check whether your SBC is still there or not. If you forward OPTIONS to SM in this case, these will also be forwarded to CM which will not handle it correctly and this can abruptly end calls from SP end.

Thanks for your interest in this post, I tried to solve the problem via TLS to make a trusted connection, but at the last moment I saw that when I bought SBCE, the manager did not include a free encryption license. As a result, I removed SMRG from the chain and left CM>SBE
It's all working steadily now. I will take your advice to heart. thank you