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

 

[Instructor of Avaya]

First, thank you for providing this level of detail. It helps enormously.

When Aura Session Manager (ASM) responds with a 407 Proxy Authentication Required response that means that ASM believes it is talking to a SIP endpoint. Essentially ASM is saying "I don't trust you. Prove to me that you are who you say you are. And if you are one of my SIP endpoints I will process your INVITE request".

So the question to resolve is: Why would ASM think the incoming request is from an Endpoint? The short answer is because it didn't think the request came from the SBCE.

This could be a domain issue that is not correctly administered in the SBCE's Topology Hiding screen for requests going to ASM. For the following headers, the action should be OVERWRIGHT, and the domain should be what you are using (e.g. training.com): TO, FROM, REQUEST-URI, REFER-BY and REFER-TO.

Alternatively, the Network Address Translation (NAT) abilities of your SBC should be changing the various "FROM" headers to match the IP on the internal interface of the SBC. In your case that should be: 172.25.0.62. The critical header to look at is: P-ASSERTED-IDENTITY followed by the CONTACT header. (It's better if the P-ASSERTED-IDENTY has a domain name (e.g. training.com) in the address, not an IP address, but there are other ways to fix that).

I hope that helps.

 

[kyle555]

Maybe you left udp and tcp transport in the server configuration on the sbc and made the sm entity link tcp only. I disagree with the above response. I think you're getting the 407 prompting as if it were a phone because SM doesn't see the ip/port/transport protocol as matching a known entity link to understand the call as coming from a known trunk.

If you left tcp and udp on the sbc server configuration, it'll use udp first I think for calls it sends to sm and if you're entity link is tcp only then sm will send outbound calls tcp and the sbc will accept that but sm won't accept incoming udp from the sbc

 

[Dmitriy_Nik]

First, thank you for providing this level of detail. It helps enormously.

When Aura Session Manager (ASM) responds with a 407 Proxy Authentication Required response that means that ASM believes it is talking to a SIP endpoint. Essentially ASM is saying "I don't trust you. Prove to me that you are who you say you are. And if you are one of my SIP endpoints I will process your INVITE request".

So the question to resolve is: Why would ASM think the incoming request is from an Endpoint? The short answer is because it didn't think the request came from the SBCE.

This could be a domain issue that is not correctly administered in the SBCE's Topology Hiding screen for requests going to ASM. For the following headers, the action should be OVERWRIGHT, and the domain should be what you are using (e.g. training.com): TO, FROM, REQUEST-URI, REFER-BY and REFER-TO.

Alternatively, the Network Address Translation (NAT) abilities of your SBC should be changing the various "FROM" headers to match the IP on the internal interface of the SBC. In your case that should be: 172.25.0.62. The critical header to look at is: P-ASSERTED-IDENTITY followed by the CONTACT header. (It's better if the P-ASSERTED-IDENTY has a domain name (e.g. training.com) in the address, not an IP address, but there are other ways to fix that).

I hope that helps.

I have J139 phones that are SM to CM adapted and running on the same port 5060 with the endpoint flag. Could this be related to this issue? Maybe I need to change the ports in 'SIP Entities' for asm => sbc=> SP mapping to a different one?

 

[kyle555]

What's in your server configuration in the SBC?

Regardless, you can't use same IP/port pairs for remote workers and sip trunks. From memory, I'm not even sure you can use the same IP Address. Every SBC I've setup or seen setup uses different IPs on the A1 interface for trunks vs remote workers.

 

[kyle555]

The endpoint flag just tells SM that that port can be used for endpoints and to expect endpoint traffic on it but not that it will exclusively be used for endpoints.

Nothing stops you from doing TLS on 5061 for all your endpoints and trunks.

Do you have your remote workers already setup ok? Might be easier to add another A1 IP and move your SBC trunk config over to that interface and add the new SIP entity and entity links in SM to pitch and catch that traffic.

Edit: now I'm remembering...
You need different A1 signaling interfaces for remote worker and trunks. Different IPs on A1 for those signaling interfaces makes your life easier when reading traces.

You're going to have a subscriber flow with a routing profile for incoming signaling from the remote workers and a server flow with a routing profile for incoming trunk traffic.

Even if you have different routing profiles, they're still going to point to the same server configuration where the destination IP/Port is being used.

If you're using the same signaling interfaces for your server and subscriber flows, and the same server configuration with IP/port of SM setup, that's where you trip up and use the same IP/port pairs for phone and trunk traffic and start getting 407s.

Look at your trace and open the initial invite from the SBC to SM and look at the source/dest port for a trunk call and see if it matches to an entity link.

And if you can, enable grooming in the interworking profile.

 

[Dmitriy_Nik]

What's in your server configuration in the SBC?

Regardless, you can't use same IP/port pairs for remote workers and sip trunks. From memory, I'm not even sure you can use the same IP Address. Every SBC I've setup or seen setup uses different IPs on the A1 interface for trunks vs remote workers.

A1 and B1 interfaces have internal addresses and interface b1 goes through NAT. There are no remote workers on sbc, only sip trunk of the provider.

 

[Dmitriy_Nik]

The endpoint flag just tells SM that that port can be used for endpoints and to expect endpoint traffic on it but not that it will exclusively be used for endpoints.

Nothing stops you from doing TLS on 5061 for all your endpoints and trunks.

Do you have your remote workers already setup ok? Might be easier to add another A1 IP and move your SBC trunk config over to that interface and add the new SIP entity and entity links in SM to pitch and catch that traffic.

Edit: now I'm remembering...
You need different A1 signaling interfaces for remote worker and trunks. Different IPs on A1 for those signaling interfaces makes your life easier when reading traces.

You're going to have a subscriber flow with a routing profile for incoming signaling from the remote workers and a server flow with a routing profile for incoming trunk traffic.

Even if you have different routing profiles, they're still going to point to the same server configuration where the destination IP/Port is being used.

If you're using the same signaling interfaces for your server and subscriber flows, and the same server configuration with IP/port of SM setup, that's where you trip up and use the same IP/port pairs for phone and trunk traffic and start getting 407s.

Look at your trace and open the initial invite from the SBC to SM and look at the source/dest port for a trunk call and see if it matches to an entity link.

And if you can, enable grooming in the interworking profile.

Sip phones are configured via SM, they are inside the corporate network. On the SBC only the provider's trunk

 

[kyle555]

What's the significance of the names of the entity links? 5060 is for endpoints.

I was interpreting you using 5060 for sets and 5070 for trunks or something like that. What are the 3 sip entities in your links on your sm? The names don't make it clear.

Regardless, post what's in the server configuration in your sbc where you punch in the SM ip address. I suspect there's tcp and udp listed in there.

Also post the complete invite from a trace of the first invite from the sbc to sm that gets the 407

 

[Dmitriy_Nik]

What's the significance of the names of the entity links? 5060 is for endpoints.

I was interpreting you using 5060 for sets and 5070 for trunks or something like that. What are the 3 sip entities in your links on your sm? The names don't make it clear.

Regardless, post what's in the server configuration in your sbc where you punch in the SM ip address. I suspect there's tcp and udp listed in there.

Also post the complete invite from a trace of the first invite from the sbc to sm that gets the 407

Acm sm trunk for j139 users
asm sbc trunk for sip provider
And the second one, just for test, acm asm 5070 tcp to release dialed numbers to the provider via a separate trunk to sm

Yes you are right, I saw tcp and udp ports in traceSM ,I will try to get the data tomorrow and show you.

 

[kyle555]

Yeah, so it's probably in the server configuration where you punch in the IP for SM in the SBC. If memory serves, it has TCP and UDP enabled and if you don't remove UDP, the SBC will use that first and that's why SM would be giving a 407 - because you don't have an entity link for UDP transport. You could either remove UDP from the config on the SBC or add UDP on the SBC link on the SM side but it would be better to just remove UDP on both sides and stick to TCP

 

[Dmitriy_Nik]

Yeah, so it's probably in the server configuration where you punch in the IP for SM in the SBC. If memory serves, it has TCP and UDP enabled and if you don't remove UDP, the SBC will use that first and that's why SM would be giving a 407 - because you don't have an entity link for UDP transport. You could either remove UDP from the config on the SBC or add UDP on the SBC link on the SM side but it would be better to just remove UDP on both sides and stick to TCP

I have checked the SBC configuration again and have not found that the UDP protocol is used. However, when exchanging INVITE messages, the following is received from the provider side:
│Via: SIP/2.0/TCP 172.16.240.132:5060;branch=z9hG4bK71b7.0d5f7945.0;rport │
│Via: SIP/2.0/UDP 172.16.240.140:5060;received=172.16.240.140;rport=5060;branch=z9hG4bKPjd4d8257e-fbf7-48e0-995e-a20030c5ad57
I want to show the full trace to SM.
1. INVITE From SP to SM (via SBC)

SBC to SM

2. Trying =>From SM to SP (via SBC)


3. SBC


4. ACK SBC


ACK SM

 

[kyle555]

So it's something wrong between your SBC and the SIP carrier. The 407 isn't coming from SM, or at least you haven't posted that message. The initial 407 is from the SBC to the carrier. Are you using registration trunks with your carrier? Maybe it's something about them sending you calls on a source port that isn't 5060. Is there some way you could get that tested with them sending you inbound calls from port 5060? Do they always use the same port 51037 for calls that they're sending you?

 

[kyle555]

I'm just looking over your initial post and the 407 comes from SM. I guess you didn't post that message.

In the advanced tab of the server configuration in the SBC towards Session Manager, can you tick the enable grooming check box

 

[Dmitriy_Nik]

So it's something wrong between your SBC and the SIP carrier. The 407 isn't coming from SM, or at least you haven't posted that message. The initial 407 is from the SBC to the carrier. Are you using registration trunks with your carrier? Maybe it's something about them sending you calls on a source port that isn't 5060. Is there some way you could get that tested with them sending you inbound calls from port 5060? Do they always use the same port 51037 for calls that they're sending you?

Sorry, last time (first post) i fogot refresh trusted links from SM / initTM. This trace from SBC,it shows that the response is coming from SM towards SBC



Grooming enfble on both sides


SIP trunk without registration, outgoing communication works fine

 

[kyle555]

Do you have "enable grooming" on the SM server? You posted that you have it on KCell.

I'm pretty positive you're getting a 407 because SM wants to match you to an entity link on same IP/port and if that doesn't line up, then it tries processing you as a set and answers with a 407 to get authenticated.

If you look at an outbound call from the SBC to the carrier on the B1 side, are you using source port 5060? If you don't use grooming on that server, do you notice using an ephemeral port in some high up range like the 30000s? Enable grooming is supposed to channel all your connections on 1 port. I'm thinking maybe if that grooming thing isn't working, that's why the SBC is using "not 5060" as a source port and that's why SM isn't matching it to an entity link.

What patch level of SBC are you running? Patch it maybe?

 

[Dmitriy_Nik]

Do you have "enable grooming" on the SM server? You posted that you have it on KCell.

I'm pretty positive you're getting a 407 because SM wants to match you to an entity link on same IP/port and if that doesn't line up, then it tries processing you as a set and answers with a 407 to get authenticated.

If you look at an outbound call from the SBC to the carrier on the B1 side, are you using source port 5060? If you don't use grooming on that server, do you notice using an ephemeral port in some high up range like the 30000s? Enable grooming is supposed to channel all your connections on 1 port. I'm thinking maybe if that grooming thing isn't working, that's why the SBC is using "not 5060" as a source port and that's why SM isn't matching it to an entity link.

What patch level of SBC are you running? Patch it maybe?

Yes, on the SM server this option is also enabled. Media ports in the range 40000-52000, Signal ports 5060

1. 2.xx.xx.xx:47317 ──TCP─► 172.25.0.63:5060 | INVITE sip:+77*******40@172.25.0.63:5060 SIP/2.0
2. 172.25.0.63:5060 ──TCP─► 2.xx.xx.xx:47317 | SIP/2.0 100 Trying
3. 172.25.0.62:44493 ──TCP─► 172.25.0.7:5060 │INVITE sip:+77*******40@172.25.0.7:5060 SIP/2.0
4. 172.25.0.7:5060 ──TCP─► 172.25.0.62:44493 | SIP/2.0 100 Trying
5. 172.25.0.7:5060 ──TCP─► 172.25.0.62:44493 | SIP/2.0 407 Proxy Authentication Required
6. 172.25.0.62:44493 ──TCP─► 172.25.0.7:5060 | ACK sip:+77*******40@172.25.0.7:5060 SIP/2.0
7. 172.25.0.63:5060 ──TCP─► 2.xx.xx.xx:47317 │SIP/2.0 407 Proxy Authentication Required
8. 2.xx.xx.xx:47317 ──TCP─► 172.25.0.63:5060 |ACK sip:+77*******40@172.25.0.63:5060 SIP/2.0



SBC 8.1.2.0-31-19809
GUI 8.1.2.0-19794

Can i use a circuit without SBC, directly with AVAYA CM=>AVAYA SM=> SP ?

 

[kyle555]

No, you'll need an SBC.

You can try doing a traceSM with call processing enabled to confirm the idea that the invite doesn't match a known entity link.

I have no idea why you`re having so much trouble...

 

[Instructor of Avaya]

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.

 

[Dmitriy_Nik]

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.

I changed B1's IP address. But the situation has not changed. I did topology hiding as you said in your first reply. I'm doing something wrong...
Yes, like you said, for some reason the connection is not trusted.


and when receiving OPTIONS from the provider, the SM responds with