Please test the latest trunk version. I removed the rtpproxy
functionality from nathelper s version.
You can safely use now nathelper from s with rtpproxy from generic.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 9:36 AM, Emil Kroymann wrote:
> Am Thu, 10 Feb 2011 09:23:51 -0500
> schrieb Ovid
The k version of nathelper was split in two:
- rtpproxy (dealing with the rtpproxy protocol);
- nathelper (dealing with NAT).
The same will be applied to s version.
In trunk, the rtpproxy module was moved to modules (it is a generic one now).
In 3.1.x, the rtpproxy module is in modules_k.
Rega
Am Thu, 10 Feb 2011 09:23:51 -0500
schrieb Ovidiu Sas :
> It seems that the s version of nathelper is the one that you are using
> (I just checked the code and the bug is present there).
> The rtpproxy functionality from the s version of nathelper module will
> be removed soon (see the rtpproxy mo
It seems that the s version of nathelper is the one that you are using
(I just checked the code and the bug is present there).
The rtpproxy functionality from the s version of nathelper module will
be removed soon (see the rtpproxy module). For now, please use the
nathelper and rtpproxy modules fr
But this is how the code it is!
Can you provide more details about which version of the code are you using?
And which modules?
Are you using the kamailio modules or the ser version of nathelper.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 8:58 AM, Emil Kroymann wrote:
> I already added the log s
I already added the log statements for late offer and answer and checked
that the messages where present in the ser logs. Also, I checked the
communication between sip-router and rtpproxy with ngrep. For the
200 OK, sip-router sends the 'U' command to rtpproxy and for the ACK
sip-router sends the '
Add some logs (print the message that you are processing and the rtp
command that you are issuing).
That should help you in troubleshooting your scenario.
Regards,
Ovidiu Sas
On Thu, Feb 10, 2011 at 4:55 AM, Emil Kroymann wrote:
> Hi,
>
> yeah, the script does call rtp_offer for 200 OK and rtp_a
Hi,
yeah, the script does call rtp_offer for 200 OK and rtp_answer for ACK.
So, no problem there.
Emil
Am Thu, 10 Feb 2011 09:46:04 +0100
schrieb Carsten Bock :
> Hi,
>
> just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK, the
> SDP-Offer is in the 200 OK, so you need to call "rtp_o
Hi,
just a hint: If you use rtpoffer/answer for SDP in 200ojk/ACK, the
SDP-Offer is in the 200 OK, so you need to call "rtp_offer" for the
200 OK instead of the usual "rtp_answer" for the 200 OK. The ACK/SDP
contains then the rtp_answer.
Works like a charm for me
Carsten
2011/2/10 Emil Kroym
When I checked the code of the nathelper module that we are using,
it didn't seem to be the case, that to and from tags are switched
for the ACK request. Maybe, something has been changed after the
point we checked out sip-router. When was this code last changed?
Am Wed, 9 Feb 2011 12:51:29 -0500
The code seems to be correct. The to and from tags are switched for:
- reply with offer (200ok with first SDP)
- request with answer (ACK with second SDP)
Are you sure that you are properly invoking offer/answer rtpproxy functions?
Regards,
Ovidiu Sas
On Wed, Feb 9, 2011 at 11:48 AM, Emil Kr
I will check that and I will get back to you.
Regards,
Ovidiu Sas
On Wed, Feb 9, 2011 at 11:48 AM, Emil Kroymann wrote:
> Hi,
>
> We recently had a problem with the nathelper module and rtpproxy in a
> scenario where the SDP offer is sent only in the 200 OK. We use
> sip-router 3.1 and rtp-prox
Hi,
We recently had a problem with the nathelper module and rtpproxy in a
scenario where the SDP offer is sent only in the 200 OK. We use
sip-router 3.1 and rtp-proxy from git master. The sip-router
configuration uses the rtpproxy_offer() and rtpproxy_answer() functions
in appropriate places. The
13 matches
Mail list logo
