Dialing SIP Voice Calls To SIP Trunk (Avaya SM)

[frank.calderon]

Hi. I'm working with out telco team to send sip voice calls from our VTC endpoints to an Avaya Session Manager.

I believe I have all the zones and search rules in order on the VCS side to forward the call to the SM.  I am able to confirm with the telco team that the call reaches the SM but they receive the error "Cannot determine realm".

On the VCS side, I see the below output.  Is the problem on the VCS or SM side?  Do I need to create a trust with the SM? Thx. - F 

• searchRule (2)
• • Name: Audio SIP Outbound Rule2
• • Zone (1)
  • • Name: TEST Session Mgr
  • • Type: Neighbor
  • • Protocol: SIP
  • • Found: False
  • • Reason: Server Internal Error (Cannot determine realm)
  • • StartTime: 2015-03-09 13:21:58
  • • Duration: 0.05
  • • Gatekeeper (1)
    • • Address: 172.x.x.x:5061
    • • Alias (1)
      • • Type: Url
      • • Origin: Unknown
      • • Value: 15555555555@company.org

[Martin Koch]

Best is to do a trace on the VCS or the Avaya system (seems to be TLS so not so easy to look at a pcap).

Sounds pretty much that its the Avaya.

Realm is often used in authentication. I am not aware that the VCS can initiate or answer

a authentication request for a neighbor zone. Just fishing a bit in the blind, but maybe you

need to add some trust of the domain or ip of the VCS to your avaya server to allow such

kind of sip trunk.

[frank.calderon]

Yes. I think you are onto something. TLS port 5061 needs to be open and probably in both directions.  We were able to confirm that traffic was being sent to the SM but there was no entity set up for our VCS on the AVAYA SM on port 5061.  It was only set up for 5060. When that entity rule was configured, our neighbor zone on the VCS failed to connect to the Avaya SM.  We suspect that the Avaya SM does not have a rule sourcing from TLS 5061 to our VCS.  I'll circle back with the network team.  THx

[Martin Koch · Accepted solution]

An other option is to see if you get it up with 5060/udp or 5060/tcp, that might make it easier to trace. But yea, I prefer encryption as well.

Often its that you have define some kind of trust for a specific connection which might include src or dst domain, ip, port, ...

good success ;-)

[frank.calderon]

TLS was a challenge and we were under a tight timeline.  So instead we used SIP port 5060.  We were able to connect to the Avaya Session Manager for signal communication and the border controller for media.  The call works well from the endpoint but we will have to put more effort in for a proper TLS handshake. FYI.

[frank.calderon]

Forgot to mention that we had to set up a custom zone and use filters.