Hi, I've a problem with an Alcatel PBX in the way it performs transference:
- Alcatel (behind NAT) sends INVITE to 111 and Kamailio forces RtpProxy. Let's assume the selected UDP port for RtpProxy is 1000.
- Alcatel sends INVITE to 222 and Kamailio forces RtpProxy. Let's assume the selected UDP port for RtpProxy is 2000.
Then Alcatel performs the transference as follows:
- It sends a re-INVITE for 111 to Kamailio by setting the SDP to the IP or RtpProxy and port 2000.
- It also sends a re-INVITE for 222 to Kamailio by setting the SDP to the IP or RtpProxy and port 1000.
This is, Alcatel wants that the provider (me) sends the RTP to itself, while mantaining the original SIP dialogs established (so it's ok at signalling level, but at RTP level it cannot work as RtpProxy shoud send RTP to itself).
I'm thinking on how to solve it but find no solution. Any suggestion? Thanks.
Hello,
On 02/26/2010 02:08 PM, Iñaki Baz Castillo wrote:
Hi, I've a problem with an Alcatel PBX in the way it performs transference:
- Alcatel (behind NAT) sends INVITE to 111 and Kamailio forces RtpProxy. Let's
assume the selected UDP port for RtpProxy is 1000.
- Alcatel sends INVITE to 222 and Kamailio forces RtpProxy. Let's assume the
selected UDP port for RtpProxy is 2000.
Then Alcatel performs the transference as follows:
- It sends a re-INVITE for 111 to Kamailio by setting the SDP to the IP or
RtpProxy and port 2000.
- It also sends a re-INVITE for 222 to Kamailio by setting the SDP to the IP
or RtpProxy and port 1000.
This is, Alcatel wants that the provider (me) sends the RTP to itself, while mantaining the original SIP dialogs established (so it's ok at signalling level, but at RTP level it cannot work as RtpProxy shoud send RTP to itself).
I'm thinking on how to solve it but find no solution. Any suggestion?
Do you re-engage rtpproxy for re-INVITEs? Also, have you played with force rtp proxy flags to trust public addresses?
Cheers, Daniel
El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribió:
Do you re-engage rtpproxy for re-INVITEs?
Yes, the client is behind NAT so I must use RtpProxy for initial INVITE. Then, if I don't re-engage rtpproxy for re-INVITE RtpProxy would receive RTP in already working ports but from a different source, so RtpProxy would reject/ignore such RTP traffic.
Also, have you played with force rtp proxy flags to trust public addresses?
But that wouldn't solve the problem, am I wrong?
Thanks.
On 02/26/2010 03:09 PM, Iñaki Baz Castillo wrote:
El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribió:
Do you re-engage rtpproxy for re-INVITEs?
Yes, the client is behind NAT so I must use RtpProxy for initial INVITE. Then, if I don't re-engage rtpproxy for re-INVITE RtpProxy would receive RTP in already working ports but from a different source, so RtpProxy would reject/ignore such RTP traffic.
Also, have you played with force rtp proxy flags to trust public addresses?
But that wouldn't solve the problem, am I wrong?
there is a deadlock when chaining two rtpproxy. In learning mode rtpproxy waits for the other side to send first packet to know the ip and port. iirc it is r flag to avoid this.
Cheers, Daniel
El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribió:
On 02/26/2010 03:09 PM, Iñaki Baz Castillo wrote:
El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribió:
Do you re-engage rtpproxy for re-INVITEs?
Yes, the client is behind NAT so I must use RtpProxy for initial INVITE. Then, if I don't re-engage rtpproxy for re-INVITE RtpProxy would receive RTP in already working ports but from a different source, so RtpProxy would reject/ignore such RTP traffic.
Also, have you played with force rtp proxy flags to trust public addresses?
But that wouldn't solve the problem, am I wrong?
there is a deadlock when chaining two rtpproxy. In learning mode rtpproxy waits for the other side to send first packet to know the ip and port. iirc it is r flag to avoid this.
Interesting, I'll try it and will comment the result.
Thanks.
Hello Iñaki,
did you fixed your issue? I'll also connect an OmniPCX pbx which maintain the session after forward / transfer and would be interested in a working config example for the SR/RTPproxy part. OmniPCX SIP config is clear as it's my daily business ;-)
thanks in advance, Andreas
2010/2/26 Iñaki Baz Castillo ibc@aliax.net
El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribió:
On 02/26/2010 03:09 PM, Iñaki Baz Castillo wrote:
El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribió:
Do you re-engage rtpproxy for re-INVITEs?
Yes, the client is behind NAT so I must use RtpProxy for initial
INVITE.
Then, if I don't re-engage rtpproxy for re-INVITE RtpProxy would
receive
RTP in already working ports but from a different source, so RtpProxy would reject/ignore such RTP traffic.
Also, have you played with force rtp proxy flags to trust public addresses?
But that wouldn't solve the problem, am I wrong?
there is a deadlock when chaining two rtpproxy. In learning mode rtpproxy waits for the other side to send first packet to know the ip and port. iirc it is r flag to avoid this.
Interesting, I'll try it and will comment the result.
Thanks.
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2010/4/24 Andreas Heise aheise.lists@googlemail.com:
Hello Iñaki,
did you fixed your issue? I'll also connect an OmniPCX pbx which maintain the session after forward / transfer and would be interested in a working config example for the SR/RTPproxy part. OmniPCX SIP config is clear as it's my daily business ;-)
I will check a new configuration on monday, I will comment the result (if I forget to do it during the next week please remember me). Thanks.
2010/4/24 Iñaki Baz Castillo ibc@aliax.net:
2010/4/24 Andreas Heise aheise.lists@googlemail.com:
Hello Iñaki,
did you fixed your issue? I'll also connect an OmniPCX pbx which maintain the session after forward / transfer and would be interested in a working config example for the SR/RTPproxy part. OmniPCX SIP config is clear as it's my daily business ;-)
I will check a new configuration on monday, I will comment the result (if I forget to do it during the next week please remember me).
Ok, tested with force_rtp_proxy("r") and it doesn't work at all. But I suspect the problem also comes from the PSTN gateway which cannot handle a re-INVITE with a different address in the SDP. I won't waste more time with this subject however (neither I can do more tests as the testing machine is gone).
-
Andreas Heise -
Daniel-Constantin Mierla -
Iñaki Baz Castillo