I solved it by myself: looked at the source code and found that the "c" option force nathelper to change both "c=" lines.
So the question is: why it is not active by default? Are there any contraindications?
Bye.
Federico Giannici wrote:
I'm trying to install rtpproxy. It usually works, but there are some cases that don't work.
For example, when a Cisco PSTN gateway is called, RTP traffic is proxied in one direction only. I think the problem is in the handling of the reply received from the gateway: it have two "c" lines but only one is modified.
Here it is the body of the original reply:
v=0. o=CiscoSystemsSIP-GW-UserAgent 2199 2489 IN IP4 83.211.2.216. s=SIP Call. c=IN IP4 83.211.2.217. t=0 0. m=audio 18850 RTP/AVP 8 13 101. c=IN IP4 83.211.2.217. a=rtpmap:8 PCMA/8000. a=rtpmap:13 CN/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-11. a=direction:passive.
And here it is the body modified by rtpproxy:
v=0. o=CiscoSystemsSIP-GW-UserAgent 2199 2489 IN IP4 83.211.2.216. s=SIP Call. c=IN IP4 83.211.2.217. t=0 0. m=audio 35086 RTP/AVP 8 13 101. c=IN IP4 195.120.250.49. a=rtpmap:8 PCMA/8000. a=rtpmap:13 CN/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-11. a=direction:passive. a=nortpproxy:yes.
Only the secondo "c" line contain the IP of our rtpproxy. I don't know RTP enough to understand if the problem is in rtpproxy or in the gateway.
Thanks for any info.