Hi Alex,
According to your scenario, there is a late negotiation (SDP is
advertised in 200OK and ACK). I see there is 'rtpproxy_offer' called for
a 200OK, but I can't see any 'rtpproxy_answer' for an ACK message.
Perhaps that's why the SDP in the ACK remains the same and I don't think
it is a correct behaviour.
Regards,
--
Răzvan Crainea
OpenSIPS Developer
On 21.09.2011 19:19, hart323 wrote:
Hi All!
I have the following type of problem.
1) Registrar send INVITE to the phone1 and phone2 (through Opensips)
2) Phone1 reply with OK/SDP1 , phone2 reply with OK/SDP2 (through Opensips)
3) Opensips modifies SDP info (IP to RTPPROXY IP and port to some random
port)
4) Registrar send ACK/SDP1 to phone2 and ACK/SDP2 to phone1 (through
Opensips)
5) Opensips only relay
The result is one direction voice.
Here is the following config:
if (is_method("INVITE") || (is_method("ACK")&& src_ip !=
"REGISTRAR_IP")) {
if (rtpproxy_offer("f")) {
t_on_reply("1");
} else {
t_on_reply("2");
}
}
if (is_method("ACK")&& src_ip == "REGISTRAR_IP") {
}
onreply_route[1] {
if(status =~ "180|200"&& search("Content-Type: application/sdp")) {
if (nat_uac_test("1")) {
fix_nated_contact();
}
rtpproxy_answer("f");
}
}
onreply_route[2] {
if(status =~ "180|200"&& search("Content-Type: application/sdp")) {
if (nat_uac_test("1")) {
fix_nated_contact();
}
rtpproxy_offer("f");
}
}
Here is the debug from rtpproxy when the sessions timeout:
INFO:process_rtp: session timeout
INFO:remove_session: RTP stats: 29 in from callee, 25 in from caller, 54
relayed, 0 dropped
INFO:remove_session: RTCP stats: 1 in from callee, 9 in from caller, 10
relayed, 0 dropped
INFO:remove_session: session on ports 39742/*45048 *is cleaned up
INFO:process_rtp: session timeout
INFO:remove_session: RTP stats: 867 in from callee, 239 in from caller, 1106
relayed, 0 dropped
INFO:remove_session: RTCP stats: 14 in from callee, 2 in from caller, 16
relayed, 0 dropped
INFO:remove_session: session on ports *42616*/38680 is cleaned up
In the packet dumps bolded values are the ports in modified SDP packet(
after rtpproxy_offer).
Why it is different order of these values? phone2 send to 42616 and goes out
from 38680 (working), but phone1 tries to send to 45048 and opensips drop
this.
Any help?! Plz!
Best regards,
Alex
--
View this message in context:
http://opensips-open-sip-server.1449251.n2.nabble.com/invites-from-registrar-through-opensips-and-rtpproxy-tp6816755p6816755.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
