Re: [SR-Users] rtpproxy_manage() issues in rtpproxy-ng
If it helps, here are my rtpproxy-ng modparams: modparam(rtpproxy-ng, rtpproxy_sock, 1 == udp:xxx.xxx.xxx.xxx:5050) modparam(rtpproxy-ng, rtpproxy_disable_tout, 120) modparam(rtpproxy-ng, rtpproxy_tout, 1) modparam(rtpproxy-ng, rtpproxy_retr, 2) -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rtpproxy_manage() issues in rtpproxy-ng
On 04/23/14 11:53, Alex Balashov wrote:
Hello,
I'm running the latest pull of Kamailio 4.1 (last commit
be187e135b0b9b28136817c3569ab5c0abcc5b3f) and am using rtpproxy-ng with
a recent mediaproxy-ng master (commit
cb6990e43864b077dd6a24acfbdf5ef76c1a427e).
For no apparent reason, Kamailio has stopped sending 'offer' commands to
it when I use rtpproxy_manage(). My use of it is in this setting:
if(isflagset(PROXY_MEDIA) !isflagset(PROXY_MEDIA_SET)
has_body(application/sdp)) {
set_rtp_proxy_set(1);
rtpproxy_manage(o);
add_rr_param(;proxy_media=yes);
setflag(PROXY_MEDIA_SET);
}
I put in a log message to confirm that this block is being run. It is.
But, there's no offer command going to the mediaproxy-ng on the other
box, as confirmed by packet captures and logs. However, the
mediaproxy-ng is getting lots of 'answer' and 'delete' commands that it
doesn't know what to do with, since the call was never initialised with
'offer'.
Can you please clarify: does it not send anything at all, or does it
send an answer instead of an offer?
cheers
signature.asc
Description: OpenPGP digital signature
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rtpproxy_manage() issues in rtpproxy-ng
On 04/23/2014 12:08 PM, Richard Fuchs wrote:
Can you please clarify: does it not send anything at all, or does it
send an answer instead of an offer?
Well, I suppose I can't say for sure, but it looks like it's not sending
anything at all. When I grep a particular Call-ID, the first thing I get is:
Apr 23 15:28:37 sd-rtp01 mediaproxy-ng[7910]: Got valid command from
xxx.xxx.xxx.xxx:43733: answer - { sdp: v=0#015#012o=- 1398266077
1398266077 IN IP4 xxx.xxx.xxx.xxx#015#012s=VOS2009#015#012c=IN IP4
yyy.yyy.yyy.yyy#015#012t=0 0#015#012m=audio 33576 RTP/AVP 18
101#015#012a=rtpmap:18 G729/8000#015#012a=fmtp:18
annexb=no#015#012a=rtpmap:101 telephone-event/8000#015#012a=fmtp:101
0-16#015#012, replace: [ origin ], call-id:
15109646-3607255707-160030@xxx, received-from: [
IP4, xxx.xxx.xxx.xxx ], from-tag: 3607255707-160035, to-tag:
Fa1Fe4ZSvBQSF, command: answer }
If my understanding of the control protocol is correct, this is actually
an answer, not a mislabeled offer, since the offer would contain some
other attributes.
But maybe not?
I expect an answer because I have an rtpproxy_manage() in an
onreply_route for 18x/2xx+SDP responses to this INVITE, of course.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rtpproxy_manage() issues in rtpproxy-ng
Maybe it's not a bug. I think I've got a theory about what may be
happening. Admittedly, it's not trivial to follow, but bear with me.
The invocation of rtpproxy_manage() is happening in a REQUEST_ROUTE that
is actually being triggered out of a FAILURE_ROUTE, because we are
pulling routing info from a redirect server. So, it looks like this
(obviously, greatly simplified):
# Main request route.
route {
...
t_on_failure(FAIL);
t_relay();
}
route[PROCESS_CALL] {
rtpproxy_manage(o);
}
failure_route[FAIL] {
if($T_rpl($rs) == 302) {
...
route(PROCESS_CALL);
}
}
Now, PROCESS_CALL is a request route and the things that are done
inside it are all safe to do inside a FAILURE_ROUTE, e.g. no stateless
replies. However, because it's being called from a FAILURE_ROUTE, I'll
bet what's happening is that the evaluative context tells
rtpproxy_manage() that it's dealing with a _reply_ (the 302 redirect),
not a _request_, so it should be sending an 'answer' on that basis.
Does that sound reasonable? I don't have an easy way of testing this
thesis right now since it's production.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rtpproxy_manage() issues in rtpproxy-ng
The reason I had not previously considered this possibility is because
the documentation says--or, at least to my lackadaisical
interpretation--that rtpproxy_manage() will only call rtpproxy_answer()
if it is operating on a 1xx/2xx reply with SDP, otherwise it'll send
rtpproxy_offer(), or send a delete command if it's a = 300 reply.
On 04/23/2014 12:51 PM, Alex Balashov wrote:
Maybe it's not a bug. I think I've got a theory about what may be
happening. Admittedly, it's not trivial to follow, but bear with me.
The invocation of rtpproxy_manage() is happening in a REQUEST_ROUTE that
is actually being triggered out of a FAILURE_ROUTE, because we are
pulling routing info from a redirect server. So, it looks like this
(obviously, greatly simplified):
# Main request route.
route {
...
t_on_failure(FAIL);
t_relay();
}
route[PROCESS_CALL] {
rtpproxy_manage(o);
}
failure_route[FAIL] {
if($T_rpl($rs) == 302) {
...
route(PROCESS_CALL);
}
}
Now, PROCESS_CALL is a request route and the things that are done
inside it are all safe to do inside a FAILURE_ROUTE, e.g. no stateless
replies. However, because it's being called from a FAILURE_ROUTE, I'll
bet what's happening is that the evaluative context tells
rtpproxy_manage() that it's dealing with a _reply_ (the 302 redirect),
not a _request_, so it should be sending an 'answer' on that basis.
Does that sound reasonable? I don't have an easy way of testing this
thesis right now since it's production.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rtpproxy_manage() issues in rtpproxy-ng
On 04/23/14 12:59, Alex Balashov wrote: The reason I had not previously considered this possibility is because the documentation says--or, at least to my lackadaisical interpretation--that rtpproxy_manage() will only call rtpproxy_answer() if it is operating on a 1xx/2xx reply with SDP, otherwise it'll send rtpproxy_offer(), or send a delete command if it's a = 300 reply. Actually the logic is a bit more complicated than that. You can look at rtpproxy_manage() in rtpproxy.c for the full details. Main selection criterion is whether the message is a request or a reply, second criterion is the SIP method (taken from the CSeq) and/or the response code in case of a reply. The route type is only marginally relevant. So it really depends on what kind of SIP message you're acting upon. You should actually see the same behaviour with rtpproxy module as well, as this part of the code hasn't been changed. cheerse signature.asc Description: OpenPGP digital signature ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rtpproxy_manage() issues in rtpproxy-ng
On 04/23/2014 01:22 PM, Richard Fuchs wrote: Main selection criterion is whether the message is a request or a reply, second criterion is the SIP method (taken from the CSeq) and/or the response code in case of a reply. The route type is only marginally relevant. Yeah, so the key question is: what is the message we are acting upon? It it is my theory that in a request route that is called from a failure_route that is triggered by a 302 reply, the message being operated on is actually the 302 reply, and not an initial INVITE. And that's why it doesn't produce the offer command as expected. The legacy rtpproxy module may well behave the same way. I hadn't tried to use rtpproxy_manage() in this scope before, which is why I was imagining it to have always worked. -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] rtpproxy_manage() issues in rtpproxy-ng
On 04/23/14 13:24, Alex Balashov wrote: On 04/23/2014 01:22 PM, Richard Fuchs wrote: Main selection criterion is whether the message is a request or a reply, second criterion is the SIP method (taken from the CSeq) and/or the response code in case of a reply. The route type is only marginally relevant. Yeah, so the key question is: what is the message we are acting upon? It it is my theory that in a request route that is called from a failure_route that is triggered by a 302 reply, the message being operated on is actually the 302 reply, and not an initial INVITE. And that's why it doesn't produce the offer command as expected. Correct, it would be sending a delete to the proxy. I'm not certain that instead sending an offer is indeed the expected behaviour. cheers signature.asc Description: OpenPGP digital signature ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
