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.
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
