Recently I run into an issue, where a Teams user forwarded incoming calls to his external mobile number.

If the call comes from internal all works fine as expected by the way.

In case the call comes from the external PSTN, the call is routed correctly to the users mobile number and it is ringing. If the call is taken, both parties can’t hear any audio/voice.


You will find in the web posts, that call forwarding from external to external cannot work by default without message manipulation.

So with call forwarding, by default the original caller id will be sent along with the outbound call to your SIP Trunk Provider, because this original calling number doesn’t belong to your SIP Trunks number range, the call will be rejected is is not allowed for outbound calls.

In my case this is not the reason as at the DTAG SIP Trunk CLIP no screening is enabled.

CLIP no screening allows you to send calling line identification information with outgoing calls which will not be verified (screened) by your network provider.

CLIP (calling line identification presentation)

https://wiki.innovaphone.com/index.php?title=Howto:How_does_CLIP_no_screening_work


Table Of Contents
  1. What exactly happens?
  2. Why is DTAG initiated here an inbound connection and therefore RTP Traffic is blocked by the firewall?
  3. No-OP Packets (short for no operation)
  4. Links



What exactly happens?

As I doesn’t see any suspect in the syslogs from the SBC, as mentioned above the outound call is allowed with CLIP no screening, I supposed this issue is related to the firewall, as the SBC is homed in the perimeter network with NAT 1:1.

And in fact I saw inbound UDP RTP traffic, coming and initiated the connection from the DTAG SBC, which is not allowed on the firewall. For the DTAG SIP Trunk, you have to initiate just an outbound connection from your SBC to DTAG.


Therefore you doesn’t need to publish the SBC for the DTAG SIP Trunk on your firewall and only need to grant outbound access. For Teams Direct Routing in contrast, you have to publish the SBC because Teams need to initiate inbound traffic to your SBC. But therefore you can filter the traffic to allow only IPs from Teams.

For DTAG there is not defined which IPs exactly will be used as I know. As workaround you can of course determine the subnets for the blocked IPs in the Screenshot above, with the whois command, but allowing the whole subnets to connect to your SBC, I wouldn’t recommend and will reduce your security.

Apart from that the workaround isn’t necessary, we will see further below!


DTAG supports Registration Mode and Static Mode for the SIP Trunk to connect your SIP-PBXs. I will use the Registration Mode.

1TR118Technical Specification of the SIP – Trunking Interface between a SIP-PBX with DDI and the NGN Platform of Telekom Deutschland
https://www.telekom.de/hilfe/downloads/1tr118.pdf


So external phone calls with Teams Direct Routing, using the DTAG SIP Trunk, works simplified as follows. Your SBC establishes an outbound connection with NAT 1:1 to the DTAG SIP Proxy by using the SIP REGISTER message, this established outbound connection can then be used by DTAG to send inbound RTP traffic to our SBC which is called NAT binding firewall pinhole.

More about UDP hole punching you will find in my following post.

UDP hole punching, ICE, STUN & TURN


In order this can work, the SBC needs to support Symmetric RTP. That means the user agents (UA) will uses the same socket/port for sending and receiving the RTP stream.

User agent (UA) -> endpoint device that supports SIP


DTAG supports automatic NAT-Detetection in case the PBX, SBC in our case, supports Symmetric RTP. Also the SBC needs to establish for inbound and outbound calls first the RTP-Stream to the DTAG Proxy.


After 3 inbound RTP Packets, coming from our SBC, DTAG determined the RTP-Stream and initiated on his part a connection to our IP and outbound UDP Port over the still established connection from our site.

https://public.telekom.de/produkte/internet-und-telefonie/ip-anschluesse/deutschlandlan-sip-trunk/technische-unterlagen
(5.6 STUN Page 14)





Why is DTAG initiated here an inbound connection and therefore RTP Traffic is blocked by the firewall?

In case of external to external call forwarding, first the external call is routed to the Teams user agent (UA), from there the Teams UA initiated a new INVITE to the mobile number (external number) of the Teams user.

At this point, the existing RTP-Stream (external call to the Teams user) and initiated outbound connection from our SBC to the DTAG proxy, is dropped, because no RTP media is transmitted between the existing call and the new INVITE to the Teams users external mobile number.

Therefore DTAG need to initiate a new inbound connection, which is not allowed and will be dropped from our firewall.


Solution

To avoid that the existing RTP-Stream is dropped, we have to enable on the AudioCodes Mediant VE SBC the parameter Generate No-OP Packets under SETUP – SIGNALING & MEDIA – CODERS & PROFILES – IP Profiles and there the DTAG IP Profile in the SBC Media section as follows.



This parameter will force the SBC to send an RTP payload to the DTAG proxy to be sure to keep the NAT binding firewall pinhole open when no other RTP media traffic is being transmitted to DTAG.

A No-Op Payload Format for RTP
https://tools.ietf.org/html/draft-wing-avt-rtp-noop-03

This memo defines a new RTP payload format called no-op. This payload behaves like a normal RTP payload, except the RTP packet is not used to play out media.

This new payload format is useful for:
keepalives to keep NAT bindings and/or firewall pinholes open when RTP media traffic is not otherwise being transmitted.

Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP)
https://tools.ietf.org/html/rfc7604


From now on call forwarding from external to external works fine!



No-OP Packets (short for no operation)

You can also set an NoOpEnable parameter at https://<IP AC SBC>/AdminPage as follows, but this doesn’t resolved my call forwarding no audio problem.

So I am not sure what exactly the difference to the Generate No-Op Packets parameter in the IP Profiles (SBC Media) settings is.

Regarding https://www.audiocodes.com/media/13258/mediant-800-msbr-users-manual-ver-72.pdf on page 134, I suppose this parameter is used for fax transmission, further below more about that.

Here you can also change the time intervall for RTP or T.38 No-Op packets in case of no RTP/T.38 media is transmitted.

The parameter is NoOpInterval and the valid range is 20 to 65.000 msec. Default is 10.000 msec.

As mentioned I am not exactly sure about the difference to the Generate No-Op Packets parameter in the IP Profiles (SBC Media) settings.

Regarding the User Manual below, the IP Profiles settings are only for SBC calls which resolved my call forwarding problem.

The following User Manual from AudioCodes about the Mediant 800 MSBR has documented the following:

https://www.audiocodes.com/media/13258/mediant-800-msbr-users-manual-ver-72.pdf on page 134


No-Op Packets

The device can send No-Op packets to verify Real-Time Transport Protocol (RTP) and T.38 connectivity, and to keep NAT bindings and Firewall pinholes open. The No-Op packets can be sent in RTP and T.38 formats:

  • RTP No-Op: The RTP No-Op support complies with IETF Internet-Draft draft-wing-avt-rtpnoop-03 (“A No-Op Payload Format for RTP”). The IETF document defines a No-Op payload format for RTP. The draft defines the RTP payload type as dynamic. You can configure the payload type as described in the following procedure (default is 120).
  • T.38 No-Op: T.38 No-Op packets are sent only while a T.38 session is activated. Sent packets are a duplication of the previously sent frame (including duplication of the sequence number).

To configure the No-Op packet feature:

  • Enable the feature, using the NoOpEnable parameter. You can also enable the feature per IP Profile (for SBC calls only), using the Generate No-Op Packets parameter.
  • Configure the interval between each No-Op packet sent by the device during the silence period (i.e., no RTP or T.38 traffic), using the NoOpInterval parameter.
  • For RTP No-Op packets, configure the payload type of the No-Op packets, using the RTPNoOpPayloadType parameter

The receipt of No-Op packets is always supported.



Links

1TR118Technical Specification of the SIP – Trunking Interface between a SIP-PBX with DDI and the NGN Platform of Telekom Deutschland

https://www.telekom.de/hilfe/downloads/1tr118.pdf

Grundlegende Informationen zu STUN und NAT bei SIP-Anschlüssen der Deutschen Telekom (DeutschlandLAN)
http://faq.bintec-elmeg.com/index.php?title=Grundlegende_Informationen_zu_STUN_und_NAT_bei_SIP-Anschl%C3%BCssen_der_Deutschen_Telekom_(DeutschlandLAN)