26 Feb
2010
26 Feb
'10
3:08 p.m.
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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
26 Feb
26 Feb
4:04 p.m.
New subject: [Kamailio-Users] Exotic case (but real) in which RtpProxy doesn't work
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
--
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/
4:09 p.m.
New subject: [Kamailio-Users] Exotic case (but real) in which RtpProxy doesn't work
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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
7:39 p.m.
New subject: [Kamailio-Users] Exotic case (but real) in which RtpProxy doesn't work
On 02/26/2010 03:09 PM, Iñaki Baz Castillo wrote:
El Viernes, 26 de Febrero de 2010, Daniel-Constantin
Mierla escribió:
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
--
Daniel-Constantin Mierla
Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010
* http://www.asipto.com/index.php/sip-router-masterclass/
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?
8:07 p.m.
New subject: [Kamailio-Users] Exotic case (but real) in which RtpProxy doesn't work
El Viernes, 26 de Febrero de 2010, Daniel-Constantin Mierla escribió:
On 02/26/2010 03:09 PM, Iñaki Baz Castillo wrote:
Interesting, I'll try it and will comment the result.
Thanks.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
El Viernes, 26 de Febrero de 2010,
Daniel-Constantin Mierla escribió:
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. 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? 
24 Apr
24 Apr
11:49 a.m.
New subject: [Kamailio-Users] Exotic case (but real) in which RtpProxy doesn't work
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(a)aliax.net>
El Viernes, 26 de Febrero de 2010, Daniel-Constantin
Mierla escribió:
Interesting, I'll try it and will comment the result.
Thanks.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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.
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. Also, have you played with
force rtp proxy flags to trust public addresses?
But that wouldn't solve the problem, am I wrong?
12:56 p.m.
New subject: [Kamailio-Users] Exotic case (but real) in which RtpProxy doesn't work
2010/4/24 Andreas Heise <aheise.lists(a)googlemail.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
28 Apr
28 Apr
8:53 p.m.
New subject: [Kamailio-Users] Exotic case (but real) in which RtpProxy doesn't work
2010/4/24 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
2010/4/24 Andreas Heise
<aheise.lists(a)googlemail.com>om>:
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).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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).
5325
days inactive
5386
days old
7 comments
3 participants
participants (3)
-
Andreas Heise -
Daniel-Constantin Mierla -
Iñaki Baz Castillo