Transcoding is part of the Connections Systems, and is especially important when dealing with legacy PBX systems that do not natively support WebRTC’s modern codecs and protocols. This article explains how transcoding works within SIPERB Connections, and when you might need to use it.
What is Transcoding?
Transcoding refers to the process of converting media streams from DTLS-SRTP to RTP (and vice-versa) to ensure compatibility between your PBX and our browser softphone. The most important difference between these two media streams is that DSLT-SRTP is an encrypted stream, while regular RPT is not.
Note: At Siperb we take an unusual approach, that may require to you make changes to your endpoint. You will be in control of this choice so please read this article to make an informed choice.
Why Transcoding is Needed
When you make a call out via Siperb Connections, the INVITE sip message is sent as-is, from the browser directly to your own systems (via a matching connection). The invite will containICE candidates and the media stream will be in DTLS-SRTP. It is simply not possible to change this.
INVITE sip:*65@d9129b7ece3051c2b805da89d.siperb.com SIP/2.0
Via: SIP/2.0/WSS 192.0.2.140;branch=z9hG4bK5820781
To: <sip:*65@d9129b7ece3051c2b805da89d.siperb.com>
From: "201 - Conrad de Wet" <sip:u9129b7ece3051c2b805da89d8b0828d7@d9129b7ece3051c2b805da89d.siperb.com>;tag=lunfu4lfbm
CSeq: 1 INVITE
Call-ID: 557i8o6tgcptfcunjbmn
Max-Forwards: 70
Contact: <sip:cee30b596439b0d0262de58eb@192.0.2.140;pn-provider=webpush;pn-prid=https://www.siperb.com/push/send/53790dad71e89161c66442f584f9e2f7;transport=wss;ob>
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: outbound
User-Agent: SIPERB 0.1
Content-Type: application/sdp
Content-Length: 1681
v=0
o=- 2488377338296270272 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=extmap-allow-mixed
a=msid-semantic: WMS 365f756e-15cb-46f5-ba18-a23113c1699c
m=audio 55275 UDP/TLS/RTP/SAVPF 111 63 9 0 8 13 110 126
c=IN IP4 41.71.39.122
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:4261449935 1 udp 2122260223 192.168.88.92 55275 typ host generation 0 network-id 1 network-cost 10
a=candidate:11158619 1 tcp 1518280447 192.168.88.92 9 typ host tcptype active generation 0 network-id 1 network-cost 10
a=candidate:1070516101 1 udp 1686052607 41.71.39.122 55275 typ srflx raddr 192.168.88.92 rport 55275 generation 0 network-id 1 network-cost 10
a=ice-ufrag:I4nE
a=ice-pwd:chdTPxQGJQgIgDYuJrANhic+
a=ice-options:trickle
a=fingerprint:sha-256 C7:3C:3D:7B:FC:4D:27:46:96:72:06:63:2B:95:92:29:19:3F:C1:F9:07:30:12:04:69:61:8B:37:09:88:09:8D
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:365f756e-15cb-46f5-ba18-a23113c1699c 064a3a10-7fb8-4f64-91dd-bdf68aa417c0
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:126 telephone-event/8000
a=ssrc:2351279764 cname:iL6YZWVuM+blAuTA
a=ssrc:2351279764 msid:365f756e-15cb-46f5-ba18-a23113c1699c 064a3a10-7fb8-4f64-91dd-bdf68aa417c0This means that on the endpoint settings of your Asterisk or SIP-based PBX, you will need to enable the appropriate configuration settings:
[webrtc_client]
type=endpoint
aors=webrtc_client
auth=webrtc_client
dtls_auto_generate_cert=yes
webrtc=yes
; Setting webrtc=yes is a shortcut for setting the following options:
; use_avpf=yes
; media_encryption=dtls
; dtls_verify=fingerprint
; dtls_setup=actpass
; ice_support=yes
; media_use_received_transport=yes
; rtcp_mux=yes
; (and some other settings)
context=default
disallow=all
allow=opus,ulawThe important part to be clear is that you don’t need to specify the transport transport=wss_transport (this is a common mistake). In fact the transport can still be UDP. This is because our Proxy Registration (Connections) is done in UDP.
Note: Its a common misunderstanding to think that transport and media have to take the same path. In fact there are largely unrelated.
In a typical call using the above, the Siperb Proxy will maintain a Register with your endpoint using UDP signalling. The INVITE will arrive via UDP from our Proxy (to the IP and port established during register). The INVITE will contain the IP and port of the location to send the DTLS-SRTP media. Your server response will in turn also advertise its IP and port (normally your Asterisk server).
If your Server is not configure to receive a call in this format, it normally responds with a failure message:
Not AcceptableIf you receive the message above in response to making a call via a connection, then you need to either adjust your endpoint settings to include webrtc=yes or, you need to enable transcoding on the connection settings in Siperb.
What does enabling Transcoding do?
In the Connections settings page you will have the option to enable Transcoding (if you are on a paid account). By doing this, we will take care of all the necessary changes need to send the INVITE to you in an appropriate format.
INVITE update: We will update the INVITE SIP message to remove the ICE candidates, and set the media stream to RTP.
Update codec: The browser normally uses opus codec, so this process will remove the encryption fingerprints, and set the codec to G711.
Set the Media Server: Because your server does not transcode the media, this means that we will do that on one of our media transcoding servers. We use RTP Engine for this. This means that the media stream is sent to and from our transcoding server. The Transcoding server is on a separate publicly accessible network, meaning that you can whitelist its IP address to ensure packets are able to flow to and from the server.
The Cost and Latency of Transcoding
While transcoding is a powerful tool for ensuring compatibility, it comes with two primary trade-offs:
- Increased Cost: Transcoding requires additional processing power and resources, which we charge for.
- Higher Latency: The process of converting media from one codec to another adds an extra step in the communication path, potentially increasing the latency of the call.
While we endeavour to create as many transcoding locations around the world, it may take time to roll these out. Until this time the extra hop and added latency may not be optional. It is well worth understanding the above system and switch off transcoding.
If your IP-PBX does not have the option to enable webrtc on the endpoint there will be no option that to enable transcoding. There may be other options, like installing your own transcoding server, either with us, or within your own network, that may reduce the latency. Speak to us directly about these options.
Conclusion
The fastest path between our Browser Softphone, and your SIP-based PBX will be a direct peer-to-peer path – but for this, you are required to configure your server to accept calls as webrtc=yes with the signaling done in UDP.
By understanding when and how to use transcoding within SIPERB, you can enhance the compatibility of your systems without sacrificing the quality of your communications. Whether integrating legacy hardware or adopting new WebRTC capabilities, SIPERB’s transcoding solutions provide the flexibility and functionality necessary to maintain effective communication across your enterprise.