Inconsistent infomation in SIP Invite

[ImpulseElliot]

Hi guys,

I have a few Azure 3CX instances all using the same provider that have begun receiving the below message on inbound calls.

07/26/2021 8:10:41 AM - NAT/ALG check:L:1911.1[Line:10001<<CALLEENUMBER] REQUEST 'INVITE' - some of SIP/SDP headers may contain inconsistent information or modified by intermediate hop
SIP proxy detected:
Via:SIP/2.0/UDP 58.96.1.2:5060;branch=z9hG4bK194e.ef303c91.0;cid=2
Via:SIP/2.0/UDP 220.233.0.65:5060;rport=5060;received=220.233.0.65;branch=z9hG4bK6dd34505
Media session IP ('c=' attribute) is not equal to the SIP packet source(IPort):
Media session IP: 220.233.0.65
Received from: 58.96.1.2

When calling into these instances the callee will receive ~5seconds of dead air before the call begins ringing or fails to connect. After working with the SIP Trunk provider (Generic/Unsupported provider Exetel in AUS) they have provided that the dead air callers are receiving is due to the SIP Invites from there end failing to be accepted by the 3CX instances and then once they are accepted it rings, or if they are rejected it terminates the call.
Both IP's in that message are from the provider

I believe i have fixed the issue on each instance by setting up Put Public IP in SIP VIA Header in each trunk and adding the Azure 3CX boxes public IP in this field. Calls seem to go through without issue now, however i still see the above error message now and then - i would love if someone was able to just shed a little more light on what could be done to remedy this?

I also have some on-premise instances using the same provider and version of 3CX which do not have this problem.

3CX instances are in Azure
All with static IP's set
All on Version 16.0.8.9
All firewall checks pass

 

[NickD_3CX]

One the reasons we highly recommend using 3CX-approved is because we test and sort most of these issues out for you.

To answer your question though, the message you see is just a warning stating that the Media (voice traffic) was received from a different IP from what the PBX was expecting.
This is not necessarily a problem, but certainly isn't ideal.

I'm glad though to hear that you got it working.
If you continue having problems, you might want to consider using a 3CX-approved provider which we should be able to help a bit more with, should you run into such issues.

 

[10m]

One the reasons we highly recommend using 3CX-approved is because we test and sort most of these issues out for you.

To answer your question though, the message you see is just a warning stating that the Media (voice traffic) was received from a different IP from what the PBX was expecting.
This is not necessarily a problem, but certainly isn't ideal.

I'm glad though to hear that you got it working.
If you continue having problems, you might want to consider using a 3CX-approved provider which we should be able to help a bit more with, should you run into such issues.

Hi @NickD_3CX

It is certainly not ideal to use a non-3CX-approved provider, but in my country Nigeria, we do not have any 3CX-approved provider and sometimes we have to find a way to get the trunks to work properly even though they are non-approved.

I would, however, appreciate any help you could provide as I have a related issue with a non-3CX-approved provider. It regards the SIP messages sent from the provider to the 3CX PBX. The problem is that the PBX does not receive a properly constructed BYE message from the SIP provider and so 3CX does not terminate the call even after the BYE message has been received. I checked the activity log and this is what I saw.

26/07/2021 20:19:45 - Malformed SIP request received:
BadSip Recv Req BYE from {SIP provider IP}:5060 tid=304b.fe4db2c.0 Call-ID=CNX2584_AH42fAdrbm1WeXIFD3UwCAwIYgIdRV1NfQonFhYAIHh25fYH5hOgFOKF0.J3IQB2FCcFYYe2cEZiQYfAs7c1AJej4aUwlFITlmAh1ze0xQOG4J:
BYE sip:{2341XXXXXXX}@{3CX Public IP address}:5060 SIP/2.0
Via: SIP/2.0/UDP {SIP provider IP}:5060;branch=z9hG4bK304b.fe4db2c.0
Max-Forwards: 65
To: <sip:{2341XXXXXXX}@{SIP provider IP}>;tag=67e0ea6f
From: "{080XXXXXXX}"<sip:{080XXXXXXX}@{SIP provider IP}>;tag=s83342d1i1r686973805
Call-ID: CNX2584_AH42fAdrbm1WeXIFD3UwCAwIYgIdRV1NfQonFhYAIHh25fYH5hOgFOKF0.J3IQB2FCcFYYe2cEZiQYfAs7c1AJej4aUwlFITlmAh1ze0xQOG4J
CSeq: 3 BYE
Allow: BYE, CANCEL, ACK, INVITE, INFO, OPTIONS
Supported: timer, replaces
Reason: SIP;cause=BYE ;text="Downstream BYE", Q.850;cause=16;text="Normal call clearing"
Content-Length: 0

Not having the call terminate when the BYE message is received is becoming a major inconvenience. Any assistance would be appreciated.

 

[NickD_3CX]

After taking a bit of a closer look, I believe the issue is in this line:

Reason: SIP;cause=BYE ;text="Downstream BYE", Q.850;cause=16;text="Normal call clearing"

Specifically, "cause=BYE" is invalid and our SIP Core expects a SIP Status code, e.g. '200' as a value, not 'BYE'.
This is also explained in RFC3326.