Block DTMF

[Alberto]

Hi,

I have another separate issue. I don't know if it's rtpengine or opensips, but it recently stopped working after an rtpengine update.

I recently went from rtpengine 11.5 to 12.5, opensips (3.4.8) hasn't changed.

I have this call scenario:

A -> (opensips/rtpengine) -> B

I want to stop B from sending DTMF, but still to be able to receive them.

So in opensips.conf I call:
rtpengine_block_dtmf("from-tag=$tt");

However, in the rtpegine logs I see this instead:

[control] Received command 'block DTMF' from 127.0.0.1:50511
[core] Blocking DTMF (entire call)
[control] Replying to 'block DTMF' from 127.0.0.1:50511 (elapsed time 0.000010 sec)

which blocks dtmf for the entire calls.

Is this normal?

[Richard Fuchs]

On 17/01/2025 11.18, Alberto wrote:
> I have another separate issue. I don't know if it's rtpengine or
> opensips, but it recently stopped working after an rtpengine update.
>
> I recently went from rtpengine 11.5 to 12.5, opensips (3.4.8) hasn't
> changed.

This is a side effect of a somewhat recent (?) change in how flags are
parsed. Just giving a `from-tag` now is not enough to trigger
directional operation, because depending on the control module, the
from-tag may always be present. So the flag `directional` must now be
given in addition to that.

Cheers

[Alberto]

Hi,

I do pass the directional flag, but it doesn't seem to work.

Here's a piece of my config:

branch_route[invite_branch_route] {
  if (has_body("application/sdp")) {
    xlog("L_NOTICE", "[ln $cfg_line] [$ci | $si | $rm] Start rtp streams\n");
    rtpengine_manage("directional RTP/AVP trust-address replace-origin replace-session-connection codec-strip-all codec-except-telephone-event codec-except-CN codec-except-PCMA");
  }
}

onreply_route[invite_onreply_route] {
  $acc_extra(callee_domain) = $si;

  if (has_body("application/sdp")) {
    xlog("L_NOTICE", "[ln $cfg_line] [$ci | $si | $rm | $rs] Update rtp streams\n");
    rtpengine_manage();

    xlog("L_NOTICE", "[ln $cfg_line] [$ci | $si | $rm | $rs] Block DTMF from $tt\n");
    rtpengine_block_dtmf("directional from-tag=$tt");
  }
}

I wasn't sure where to put the directional flag, so I tried first in rtpengine_manage, then in rtpengine_block_dtmf, then in both. Result is the same, DTMF are always blocked for the entire call.

Logs from opensips:
Jan 21 23:22:26 local-opensips opensips[2027]: Jan 21 23:22:26 [2027] NOTICE:[ln 361] [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc | 10.0.0.69 | INVITE] t_relay
Jan 21 23:22:26 local-opensips opensips[2027]: Jan 21 23:22:26 [2027] NOTICE:[ln 371] [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc | 10.0.0.69 | INVITE] Start rtp streams
Jan 21 23:22:26 local-opensips opensips[2029]: Jan 21 23:22:26 [2029] NOTICE:[ln 380] [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc | 10.0.0.46 | INVITE | 200] Update rtp streams
Jan 21 23:22:26 local-opensips opensips[2029]: Jan 21 23:22:26 [2029] NOTICE:[ln 383] [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc | 10.0.0.46 | INVITE | 200] Block DTMF from a369dd65-3212-4728-a22d-4bcdd0857b39
Jan 21 23:22:26 local-opensips opensips[2029]: Jan 21 23:22:26 [2029] NOTICE:[ln 271] [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc | 10.0.0.69 | ACK] topology_hiding_match OK
Jan 21 23:22:26 local-opensips opensips[2029]: Jan 21 23:22:26 [2029] NOTICE:[ln 300] [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc | 10.0.0.69 | ACK] t_relay
Jan 21 23:22:33 local-opensips opensips[2027]: Jan 21 23:22:33 [2027] NOTICE:[ln 271] [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc | 10.0.0.69 | BYE] topology_hiding_match OK
Jan 21 23:22:33 local-opensips opensips[2027]: Jan 21 23:22:33 [2027] NOTICE:[ln 296] [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc | 10.0.0.69 | BYE] Close rtp streams if any
Jan 21 23:22:33 local-opensips opensips[2027]: Jan 21 23:22:33 [2027] NOTICE:[ln 300] [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc | 10.0.0.69 | BYE] t_relay

Logs from rtpengine:
Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Received command 'offer' from 127.0.0.1:52434
Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [core] replace-session-connection flag encountered, but not supported anymore.
Jan 21 23:22:26 local-opensips rtpengine[1254]: NOTICE: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [core] Creating new call
Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Replying to 'offer' from 127.0.0.1:52434 (elapsed time 0.000364 sec)
Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Received command 'answer' from 127.0.0.1:38934
Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Replying to 'answer' from 127.0.0.1:38934 (elapsed time 0.000505 sec)
Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Received command 'block DTMF' from 127.0.0.1:38934
Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [core] Blocking DTMF (entire call)
Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Replying to 'block DTMF' from 127.0.0.1:38934 (elapsed time 0.000037 sec)
Jan 21 23:22:30 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc/63c659c2-ff03-4673-a4f9-96a145ec6d45/1 port 28640]: [core] Confirmed peer address as 10.0.0.69:19446
Jan 21 23:22:30 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc/63c659c2-ff03-4673-a4f9-96a145ec6d45/1 port 28640]: [core] Kernelizing media stream: 10.0.0.69:19446 -> 10.0.0.18:28640 | 10.0.0.18:31230 -> 10.0.0.46:19502
Jan 21 23:22:31 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc/63c659c2-ff03-4673-a4f9-96a145ec6d45/1 port 28641]: [core] Confirmed peer address as 10.0.0.69:19447
Jan 21 23:22:31 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc/63c659c2-ff03-4673-a4f9-96a145ec6d45/1 port 28641]: [core] Kernelizing media stream: 10.0.0.69:19447 -> 10.0.0.18:28641 | 10.0.0.18:31231 -> 10.0.0.46:19503
Jan 21 23:22:31 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc/a369dd65-3212-4728-a22d-4bcdd0857b39/1 port 31231]: [core] Confirmed peer address as 10.0.0.46:19503
Jan 21 23:22:31 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc/a369dd65-3212-4728-a22d-4bcdd0857b39/1 port 31231]: [core] Kernelizing media stream: 10.0.0.46:19503 -> 10.0.0.18:31231 | 10.0.0.18:28641 -> 10.0.0.69:19447
Jan 21 23:22:33 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Received command 'query' from 127.0.0.1:52434
Jan 21 23:22:33 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Replying to 'query' from 127.0.0.1:52434 (elapsed time 0.000230 sec)
Jan 21 23:22:33 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Received command 'delete' from 127.0.0.1:52434
Jan 21 23:22:33 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [core] Scheduling deletion of call branch '63c659c2-ff03-4673-a4f9-96a145ec6d45' (via-branch '') in 30 seconds
Jan 21 23:22:33 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [core] Scheduling deletion of call branch 'a369dd65-3212-4728-a22d-4bcdd0857b39' (via-branch '') in 30 seconds
Jan 21 23:22:33 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [core] Scheduling deletion of entire call in 30 seconds
Jan 21 23:22:33 local-opensips rtpengine[1254]: INFO: [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Replying to 'delete' from 127.0.0.1:52434 (elapsed time 0.000232 sec)

Thanks

[Richard Fuchs]

On 31/01/2025 12.15, Alberto wrote:
> Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO:
> [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [control] Received command
> 'block DTMF' from 127.0.0.1:38934
> Jan 21 23:22:26 local-opensips rtpengine[1254]: INFO:
> [ef0c76ea-adbc-4a09-bf2d-9df7f6f872bc]: [core] Blocking DTMF (entire call)

Enable debug logging to see what's actually coming through here.

Cheers

[Pete Kelly]

I think this is a bug in Opensips. When I trace the offer command being sent to rtpengine there is no mention of the string “directional” sent in the flags.

Sent from Gmail Mobile

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/b288ed7c-319b-4268-b178-8b1d27fed07c%40sipwise.com.

[Pete Kelly]

I've managed to patch opensips so that the directional flag is now sent, and confirmed it's found and set in call_interface.c

case CSH_LOOKUP("directional"):
                        ilog(LOG_INFO, "directional flag found");
                        out->directional = 1;
                        break;

However when media_block_match1 is then called later as part of dtmf block NG request, the directional flag isn't found in the flags that are passed in.

[Pete Kelly]

Further update - if I hardcode flags->directional=1 in that function, then directional blocking by from_tag is identified - so the issue seems to be that the directional flag from the offer isn’t picked up and passed into the flags dictionary for subsequent NG requests.

To view this discussion visit https://groups.google.com/d/msgid/rtpengine/49b1df80-fade-471d-a7c3-f85bb1138d30n%40googlegroups.com.

[Richard Fuchs]

On 31/01/2025 14.50, Pete Kelly wrote:
> I think this is a bug in Opensips. When I trace the offer command
> being sent to rtpengine there is no mention of the string
> “directional” sent in the flags.

It's not the "offer" command that needs the "directional" flag. It's the
"block DTMF" command that needs it.

Cheers

[Pete Kelly]

Hmm

When I trialled it, the block dtmf command throws an error that the directional flag is not recognised. I could only get it to be accepted (including checking/logging out from the code) within the main offer command.

Sent from Gmail Mobile

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/rtpengine/e6dae498-9cb4-4007-813c-cffebd7a6ba8%40sipwise.com.

[Pete Kelly]

Hi

Just to elaborate on this, if I send the directional flag with block-dtmf, the following is generated:

WARNING: [479.acc78293]: [core] Unknown dictionary key encountered: 'directional'

INFO: [479.acc78293]: [core] Blocking DTMF (entire call)

This is the NG

U 2025/02/06 15:13:56.758802 10.3.0.16:45426 -> 10.3.0.16:2223 #5
1_11oiixg8_x6k d7:call-id12:479.acc782937:command10:block DTMF11:directionali1e8:from-tag10:2716490252e

U 2025/02/06 15:13:56.758951 10.3.0.16:2223 -> 10.3.0.16:45426 #6
1_11oiixg8_x6k d6:result2:oke

[Richard Fuchs]

On 06/02/2025 11.16, Pete Kelly wrote:
> Hi
>
> Just to elaborate on this, if I send the directional flag with
> block-dtmf, the following is generated:
>
> WARNING: [479.acc78293]: [core] Unknown dictionary key encountered:
> 'directional'
> INFO: [479.acc78293]: [core] Blocking DTMF (entire call)
>
> This is the NG
>
> U 2025/02/06 15:13:56.758802 10.3.0.16:45426 -> 10.3.0.16:2223 #5
> 1_11oiixg8_x6k d7:call-id12:479.acc782937:command10:block
> DTMF11:directionali1e8:from-tag10:2716490252e

Yeah, that's wrong. It's turning it into a list, ` directional=[1] `

It's supposed to go into the `flags` list. Maybe try using it as `
flags=directional ` to maybe trick it into putting it into the right place.

Cheers

[Pete Kelly]

Amazing, that did the trick thanks :)

Next problem is the dumf-security isn't working. If I leave it unset, then blocking works fine. If I set it to 'zero' then the DTMF is relayed as-is. 

Reading the source it looks like this may be because transcoding is not enabled?

I am passing inject-dumf in the offer and answer:

```

11:record-call2:no5:label12:offeredparty5:flagsl11:inject-DTMF11:directional13:port-latchinge7:replacel6:origine7:call-id11:faa.5521b0213:received-froml3:IP49:10.3.0.13e8:from-tag9:2751437467:command5:offere

```

so I would have assumed that should force transcoding?

Pete

[Richard Fuchs]

Combine it with the delay-buffer setting. Set it to 1 ms at least to enable it. Set it to 0 to disable it when you don't need it any more.

Cheers

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/rtpengine/bb791461-0d14-4aa0-a63b-6fbfc5d6c36cn%40googlegroups.com.