Hi Federico,

if the session section has a "c" definition the global "c" will not be used. The global "c" is to be used only for sessions without a local "c" definition.

If you have them both global and inside the session section, the only that should be used is the one from the session - that;s the reason RTPproxy changes only that one; because it sees there is no session without "c" which mean the global "c" will not be used.

I would say the GW is buggy...

regards, bogdan

Federico Giannici wrote:

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.

Gerd Feiner wrote:

Federico Giannici schrieb:

...

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.

your problem is most likely not caused by openser but a misconfigured gateway. do you have ip-routing enabled or just set an ip defautl-gateway? if so, try enablind ip routing (ip routing) and set an appropriate default route (ip route 0.0.0.0 0.0.0.0 x.x.x.x).

The gateway is not managed by me, but by one of the greatest VoIP operators here in Italy.

Anyway, I solved the problem making my proxy to modify all "c" lines...

Bye.