Hi,
thanks for the quick response.
regarding to the 200 drop, it is less of an issue. i actually tried
t_drop_replies() on the reply_route.
it works only on failure_route.
but, didn't try another on_reply route and drop. i will try. thanks.
still, daniel is right, the main problem is the ACK.
as i wrote, i use uac_req_send() to try and send the asterisk a fake ACK.
i enter the following:
$uac_req(method)="ACK";
$uac_req(ruri)= "exten@asterisk:5080";
$uac_req(furi)="from(a)caller.com".com";
$uac_req(turi)="exten@asterisk:5080" + ";" + "saved_to_tag"
$uac_req(callid)=$dlg(callid);
uac_req_send();
the problem is that the actual ACK sent, is malformed in the TO header.
it is populated as <exten@asterisk:5080;to_tag>
instead of <exten@asterisk:5080>;to_tag
what do you think?
thanks,
uri
Hello,
On 18/02/16 20:35, Uri Shacked wrote:
Hi,
for some strange reason, ask my regulator.... i need to manipulate
certain calls.
the scenario goes like this:
1. caller sends invite to kamailio.
2. kamailio transfer the call to asterisk.
3. asterisk send progress and play "hello".
4. asterisk creates a new call (dial) to the same kamailio with
destination callee.
5. the callee answers the call.
here, i need to block the 200ok. so that the caller does not receive it.
i managed to block it with t_suspend().
but, there is no bidirectional media.
the 183 progress was sent with sendreceive.
it seems the asterisk is waiting for the ACK in order to open both
ways for media.
i tried to use uac_send_req() but it is being sent with no to tag. and
when i try manipulating the uac_req(turi) it does not help because it
takes all the string i entered and wraps it with <>.
any ideas?
But if asterisk is waiting for ACK, that is not going to happen if you
drop the 200ok.
Maybe Asterisk is waiting for PRACK following the 183, can you check the
Requires header in 183?
While 200ok can be dropped by having a reply_route with drop for 200ok,
it doesn't feel like it is solving what you are looking for.
Cheers,
Daniel