IP Intercom behind SBC

[lukekenny]

I have 3CX running on a VPS with a 3CX SBC deployed at site. The site is connected by 4G LTE (double NAT plus GCNAT). There are several Yealink phones provisioned and they work just fine.

I am attempting to setup a Vingtor Stentofon TCIS-3 IP Intercom. It's a SIP device. With the server domain and outbound proxy set to the IP of the SBC, the unit registers, receives and makes calls. There seems to be no issue when the unit receives calls at all.

However, when the unit dials another extension, the call establishes, both parties can hear each other, but the call terminates after 32 seconds.

Thinking this is a SIP ALG issue, I confirmed no SIP ALG's are turned on. So I looked at the logs.

3CX log:

02/13/2021 2:27:50 PM - [CM503021]: Call(C:18): ACK is not received from sip:[email protected]:5060 02/13/2021 2:27:50 PM - ACK not received from "Intercom 1"<sip:[email protected]:5060>;tag=2071512103 to <sip:[email protected]:5060>;tag=81271648

Intercom log:

817 1 27:09.726 SipConnection::updateStatus ---- status 2 ----- 818 1 27:18.396 handle_rcv2xx handle_rcv2xx (id=16) state 2 819 1 27:18.399 SipCall_handle2xxInviteResponse handle_rcv2xx_for_invite (id=16) 820 1 27:18.401 SipCall_sendAckFor2XX Sending ack 821 1 27:18.403 send_sip_message Send SIP Message ACK 127.0.0.1:5060 822 1 27:18.405 SipConnection::sendData Sending SIP message from port 5060 to 127.0.0.1:5060 write(648) 823 1 27:18.407 SipCallLine_onCallAccepted SipCallLine_onCallAccepted 824 1 27:18.411 SipCallLine_checkSdp SipCallLine_checkSdp audio local state is SDP_SENDRECV remote state is SDP_SENDRECV calculated state SDP_SENDRECV 825 1 27:18.412 SipLineManager_updateCallStatus SipLineManager_updateCallStatus 4 826 1 27:18.419 ZapToSip_notifyCallUpdate ZapToSip_notifyCallUpdate 827 1 27:18.420 ZapToSip_callToJson ZapToSip_callToJson 828 1 27:18.425 SipMain_updateGeneralStatus SipMain_updateGeneralStatus STATE_OUTGOING_CALL 829 1 27:18.426 SipMainDigitalOutputs_callEvents_timed SipMainDigitalOutputs_callEvents_timed 830 1 27:18.432 SipMainDigitalOutputs_callEvents_timed Script, key or delay not configured: 0 831 1 27:18.433 SipConnection::playTone Tone off 832 1 27:18.433 EdgeAudioControl::playTone playTone(21) - duration:0 833 1 27:18.434 EdgeVoiceEngineIntegrIt0::setVoiceEngine VE Options - micFadeInDelay: -1, duplexStartDelay: -1, toneGain: -2200 834 1 27:18.435 EdgeVoiceEngineIntegrIt0::playTone Stopping tone 835 1 27:18.436 EdgeAudioControl::playTone playTone(102) - duration:100 836 1 27:18.437 EdgeVoiceEngineIntegrIt0::setVoiceEngine VE Options - micFadeInDelay: -1, duplexStartDelay: -1, toneGain: -2200 837 1 27:18.438 EdgeVoiceEngineIntegrIt0::playTone Playing custom tone f1:500,f2:0 - Tone400,Silence100 843 1 27:18.446 SipConnection::onSdpReceived Sdp received v=0 o=3cxPS 23973678182039552 483041063469057 IN IP4 127.0.0.1 s=3cxPS Audio call c=IN IP4 192.168.1.190 b=AS:84 t=0 0 a=X-nat:0 m=audio 20000 RTP/AVP 9 101 c=IN IP4 192.168.1.190 b=TIAS:64000 b=AS:84 a=sendrecv a=rtpmap:9 G722/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 844 1 27:18.452 SipAudioChannel_startChannel start ch type 0, lport 61000, rport 20000, rip 192.168.1.190, codec g722, vol 0db pri 2 845 1 27:18.453 SipConnection::setupAudio channel 0 ip 192.168.1.190 port 20000 codec g722 dtmfpt 101 846 1 27:18.464 EdgeAudioControl::audioStreamSetup New config for audiostream: 1 847 1 27:18.465 AudioStreamConfig::setStreamSetupConfig Masks: Modify[1111111111111111] - Config[ 100001] 870 1 27:18.516 SipCallLine_debug Call info: direction outgoing - state established 871 1 27:18.522 SipCallParams_printDebug SipCallParams_printDebug: remote sipid 666 nick (null) domain (null) port 5060 872 1 27:18.523 SipCallParams_printDebug SipCallParams_printDebug: local sipid 401 nick "Intercom 1" domain (null) port 5060 873 1 27:18.524 SipCallParams_printDebug SipCallParams_printDebug: header name user-agent value 3CXPhoneSystem 16.0.7.1078 (1078) 874 1 27:18.525 SipCallParams_printDebug SipCallParams_printDebug: header name supported value timer 875 1 27:18.526 SipCallParams_printDebug SipCallParams_printDebug: header name supported value replaces 876 1 27:18.527 Sip_handleOsipMessage Done processing SIP event. 877 1 27:18.535 Sip_handleNewRequest New transaction ACK message, should be ACK on 2xx 878 1 27:18.536 Sip_handleNewRequest Could not find call for ACK message!

So it seems the intercom is having trouble responding with an ACK, possibly because the IP address of the SBC is getting mangled.

The intercom is running old firmware, and I've emailed the manufacturer to try to get an update, however I am wondering if there is something I've missed in 3CX settings.

 

[leejor]

I'm wondering why, in the Intercom log, it would show it is sending the ACK to 127.0.0.1 .

821 1 27:18.403 send_sip_message Send SIP Message ACK 127.0.0.1:5060
822 1 27:18.405 SipConnection::sendData Sending SIP message from port 5060 to 127.0.0.1:5060 write(648)

Never having worked with that particular device, I have no idea if that log is normal, or, it should show it sending to the local IP of the SBC (which would make sense).

What first comes to mind is that there may be a feild , in the Intercom that is missing the SBCs IP address. I have seen devices that will not work correctly unless the server address is entered in up to 3 different fields.

 

[lukekenny]

Interesting. I did some more logging. It seems the packet sent by 3CX just as the call initiates contains 127.0.0.1, and the intercom is trying to send the ACK there in response.

In previous packets, the IP of 3CX is set correctly:

From the intercom's log, just before it tries to send the ACK to 127.0.0.1:

1232 1 046-16:20:34.013 SipConnection::onSdpReceived Sdp received v=0
o=3cxPS 11330455982833664 28788623964897281 IN IP4 127.0.0.1
s=3cxPS Audio call
c=IN IP4 192.168.1.190
b=AS:84
t=0 0
a=X-nat:0
m=audio 20000 RTP/AVP 9 101
c=IN IP4 192.168.1.190
b=TIAS:64000
b=AS:84
a=sendrecv
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

I can see the first instance of 127.0.0.1 in the 3CX log, when it receives the INVITE from the intercom:

02/15/2021 4:35:34 PM - [CM500002]: Call(C:64): Info on incoming INVITE from Extn:401:
Invite-IN Recv Req INVITE from 127.0.0.1:5080 tid=1140070999 [email protected]:
INVITE sip:127.0.0.1:5060;lr;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK-524287-2---1140070999;rport=5080
Via: SIP/2.0/UDP [::ffff:1.152.108.106]:63178;branch=z9hG4bK-524287-1---tunneltid;rport;tnlid=sbc.dba070f9
Via: SIP/2.0/UDP 192.168.1.73:5060;branch=z9hG4bK1140070999;rport=5060
Max-Forwards: 68
Record-Route: <sip:[email protected]:5080;user=proxy;uri=sbc.dba070f9>
Record-Route: <sip:[email protected]:5060;user=proxy;tnlid=sbc.dba070f9>
Contact: <sip:[email protected]:5060>
To: <sip:[email protected]:5060>
From: "Intercom 1"<sip:[email protected]:5060>;tag=843522679
Call-ID: [email protected]
CSeq: 35566 INVITE
Expires: 120
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO
Content-Type: application/sdp
Proxy-Authorization: Digest username="nRsbq2o2cF",realm="3CXPhoneSystem",nonce="414d5359602a082566:db6b6526292c8a0cf38a194a3dc8f671",uri="sip:192.168.1.73",response="4f417c46f77539480441951984dc7b09",algorithm=MD5
Supported: replaces
User-Agent: Zenitel IPSTATION v2.0
X-zenitel-gid: 1468998851
Content-Length: 285

v=0
o=ZenitelIPSTATIONv2.0 20000001 20002 IN IP4 192.168.1.73
s=-
c=IN IP4 127.0.0.1
t=0 0
m=audio 14342 RTP/AVP 9 18 8 0 101
a=sendrecv
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

So it looks like it has something to do with the 3CX Bridge component. I've checked the SBC in SIP Trunks, and the external and internal IP addresses seem to be populated correctly.

 

[leejor]

Have a look at the second to last post in this thread, I'm wondering if it is related to your issue.

https://www.3cx.com/community/threads/yealink-phone-behind-sbc-cant-call-back.75344/page-2

Second to last post in this thread has the same conclusion, for manual settings behind an SBC.

https://www.3cx.com/community/threads/registering-phones-on-sbc-session-border-controller.63708/

 

[lukekenny]

Thank you for this. I have tried setting the SIP server in the intercom to both the internal IP of the SBC, and the domain name of the 3CX instance, and in both cases have Outbound Proxy set to the internal IP of the SBC.

It doesn't seem to change the behaviour, in both cases inbound calls to the intercom are fine, registration is fine, but outbound calls from the intercom drop after 32 seconds with the ACK error message.

Interestingly, and conversely to the post you mentioned, when I look at the Yealink T58a's provisioned behind the SBC, they have bother the SIP server and Outbound proxy as the IP of the SBC. These work with no issues, but as they are a supported model I can provision them behind the SBC using 3CX, so you would think they would.

I am honing in on this being more a device issue as opposed to a 3CX issue. I set up a second SBC connected to this 3CX instance in my lab, and while I don't have another of these devices to test with, I set up a Gigaset phone with the same settings and it works fine.

 

[JohnS_3CX]

This is one of the issues you may face when using unsupported devices, and it can be a pain to figure out.

The device sends the ACK to 127.0.0.1 so it never reaches the PBX, and the 32 second timer is reached thus ending the call. Ideally you should have the PBX FQDN as the registrar, and the SBC IP as the Proxy to avoid this issue.

Consider using a 3CX Supported doorphone, Fanvil and Grandstream make some nice models like the i30 or the GDS series https://www.3cx.com/sip-phones/

 

[lukekenny]

Thanks John. I hear you, and I have positioned Grandstream door phones which have been... OK. Unfortunately they have their own issues, for example the Grandstream GDS3710 requires a more recent firmware than the 3CX supported firmware, if you don't want it to crash every 16-28 days.

This particular unit was purchased independently by the client, and in all other respects it is a quality, well built unit with a really nice speaker and mic, very suitable for the application in mind. My job is to do my best to make it work, and it does, with the exception of this issue.

I have also gone back to the manufacturer who apparently are in Norway, so they might have a suggestion too.

It still puzzles me that the bridge that SBC talks to has the address of 127.0.0.1. That just doesn't make sense to me in any way. Is there a configuration parameter, either in 3CX or in the SBC conf file I could modify that would allow the bridge to present a different IP?

 

[JohnS_3CX]

I have not seen the setup of the device or a capture so I cannot objectively comment.

I think it is best if you get help from the vendor directly since this is not currently a supported device, or if possible replace it with a supported one which already works.