One way Voice with Linux SIP conntrack

One way voice problem is seen on device running behind NAT, if call is initiated from device to Soft phone which is not running on SIP Server m/c.
( Softphone and SIP server, running on diffrent m/c)
Following is Setup

                                                                                              |-------- Softphone
    VoIP device behind NAT-------- Host (running SIP conntrack)-----------
                                                                                              |
                                                                                              ---------SIP Server 

When invite message is sent set_expected_rtp_rtcp function defined in nf_conntrack_sip.c makes expected connection tracking entry using nf_ct_expect_init function

nf_ct_expect_init function fills source mask value as 0xFFFFFFFF. Since Source mask is 0xFFFFFFFF, that means connection tracking module expects, exact SRC IP address but if VoIP phone is not running on same m/c as SIP server, IP address of VoIP Phone is not really know while sending the INVITE message. ( INVITE message goes to SIP server).

Because of which following are expected connections

<UDP PROTO NUM> <SIP SERVER IP ADDRESS:0 -> <Public IP address of phone behind NAT>:<RTP Port number of Phone behind NAT>

<UDP PROTO NUM> <SIP SERVER IP ADDRESS:0 -> <Public IP address of phone behind NAT>:<RTCP Port number of Phone behind NAT>

But the incoming packets will as following

<UDP PROTO NUM> <External VoIP Phone IP:<RTP Port number> > <IP address of phone behind NAT>:<RTP Port number of Phone behind NAT>

<UDP PROTO NUM> <External VoIP Phone IP:<RTCP Port number> -> <IP address of phone behind NAT>:<RTCP Port number of Phone behind NAT>

So there will never a hit with expected connection and we see 1 way voice problem,

To resolve this problem in expected connection entry, we should ignore Source IP address, one way is to make MASK value as 0x0.
In nf_ct_expect_init function.

Following is code diff

[root@sw-dev netfilter]# diff nf_conntrack_expect.c nf_conntrack_expect.c.fix
265c265,266
<               memset(&exp->mask.src.u3, 0xFF, len);
---
>               //memset(&exp->mask.src.u3, 0xFF, len);
>               memset(&exp->mask.src.u3, 0x00, len);

Obviously above fix opens up security hole.