SDP Information Change during Call Setup - one way audio

Our config: we have asterisk performing PBX functionality and native bridging between Polycom 601 phones (on one SIP leg) and our trunking gateway with OpenSER as the proxy (on the other leg). OpenSER is stateless and does not participate in the media session. So:

Polycom Phone --> asterisk --> OpenSER --> Gateway (Audiocodes) --> PSTN --> Phone

Our challenge: we just upgraded two of our servers to 1.4.10.1 (we have two other’s still running on 1.2.9.10) and are having trouble with one-way audio (the Polycom can hear downstream media but the upstream path cannot hear the Polycom). We have sniffed the SIP traffic on every leg of the call (both logs and ports on the NICs):

Polycom to Asterisk… Asterisk to Polycom (media session one)
Asterisk to Gateway… Gateway to Asterisk (media session two)

And found that our SDP information from the Gateway in the SIP OK response message is being changed between what is being received on our NIC card (see below TShark and Ethereal SIP OK response) and what Asterisk is logging (you are looking at the same OK message just from different points within the server). The gateway’s IP information (correct) in the o= and c= information is being changed to the proxy’s IP information.

Question: what would be changing that information or why would it be changing? We cannot find any place, in the .conf files, where we specify a value or parameter that would cause this. We also noticed the we not longer see the native-bridge message in the log upon completing the RTP session.

SIP messages (inbound SIP OK from the Proxy to Asterisk):

Audiocodes = aaa.aaa.142.182
Proxy = ppp.ppp.142.234
pbx(Asterisk) = ***.***.142.206

<=- tethereal listening on the proxy (proxy to PBX) -=>
SIP/2.0 200 OK
Via: SIP/2.0/UDP ***.***.142.206:5060;branch=z9hG4bK64084571;rport=5060
From: “Testing Company” sip:xxx3254101@ipt.homeboy.com;tag=as5c5aa073
To: sip:xxx2944063@proxy3.ipt.homeboy.com;tag=1c1360661842
Call-ID: 6c6c0d25057abf7074c7941650ed9736@ipt.homeboy.com
CSeq: 102 INVITE
Contact: sip:5011@aaa.aaa.142.182
Record-Route: sip:ppp.ppp.142.234;lr=on;ftag=as5c5aa073
Supported: em,timer,replaces,path
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Server: Audiocodes-Sip-Gateway-Mediant 2000/v.4.80A.025.004
Content-Type: application/sdp
Content-Length: 236

v=0
o=AudiocodesGW 1360738087 1360737757 IN IP4 aaa.aaa.142.182
s=Phone-Call
c=IN IP4 aaa.aaa.142.182
t=0 0
m=audio 6110 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:30
a=sendrecv
<=----------------------=>

<=- tshark on pbx (PBX to asterisk app) -=>
SIP/2.0 200 OK
Via: SIP/2.0/UDP ***.***.142.206:5060;branch=z9hG4bK64084571;rport=5060
From: “Testing Company” sip:xxx3254101@ipt.homeboy.com;tag=as5c5aa073
To: sip:xxx2944063@proxy3.ipt.homeboy.com;tag=1c1360661842
Call-ID: 6c6c0d25057abf7074c7941650ed9736@ipt.homeboy.com
CSeq: 102 INVITE
Contact: sip:5011@aaa.aaa.142.182
Record-Route: sip:ppp.ppp.142.234;lr=on;ftag=as5c5aa073
Supported: em,timer,replaces,path
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Server: Audiocodes-Sip-Gateway-Mediant 2000/v.4.80A.025.004
Content-Type: application/sdp
Content-Length: 236

v=0
o=AudiocodesGW 1360738087 1360737757 IN IP4 aaa.aaa.142.182
s=Phone-Call
c=IN IP4 aaa.aaa.142.182
t=0 0
m=audio 6110 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:30
a=sendrecv
<=----------------------=>

<=- Asterisk log -=>
SIP/2.0 200 OK
Via: SIP/2.0/UDP ppp.ppp.142.234:5060;branch=z9hG4bK64084571;rport=5060
From: “Testing Company” sip:xxx3254101@ipt.homeboy.com;tag=as5c5aa073
To: sip:xxx2944063@proxy3.ipt.homeboy.com;tag=1c1360661842
Call-ID: 6c6c0d25057abf7074c7941650ed9736@ipt.homeboy.com
CSeq: 102 INVITE
Contact: sip:5011@aaa.aaa.142.182
Record-Route: sip:ppp.ppp.142.234;lr=on;ftag=as5c5aa073
Supported: em,timer,replaces,path
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Server: Audiocodes-Sip-Gateway-Mediant 2000/v.4.80A.025.004
Content-Type: application/sdp
Content-Length: 236

v=0
o=AudiocodesGW 1360738087 1360737757 IN IP4 ppp.ppp.142.234
s=Phone-Call
c=IN IP4 ppp.ppp.142.234
t=0 0
m=audio 6110 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=ptime:30
a=sendrecv
<=----------------=>

For those who are using Gentoo with Asterisk: here is what we found…

Ip_conntrack was compiled into the kernel rather than as a module. We had have to remove it from the kernel. It was a NAT function of that module that was literally modifying the IP SDP information in the SIP message body.