VoIP - Technical Information: Difference between revisions

Latest revision as of 23:52, 18 December 2018

Multiple servers

We operate multiple servers. DNS uses SRV records as well as A and AAAA records to ensure devices register and send calls via the currently active servers. We can change which servers are active from time to time.

Some devices will stick to one server after an initial DNS look up, so we may reject a registration if we are taking that server out of action, but we aim to do that after DNS has already changed. Such devices will then re-check DNS and connect to the current servers.

When taking a server out of action, we wait for all calls to complete on that server.

FireBrick technical features

The FireBrick has specific SIP implementation constraints designed to ensure the most reliable and best quality call connections.

SIP/2.0 UDP control messages using IPv4 or IPv6 are supported up to approximately 1900 bytes (fragmented if necessary).

The FireBrick always acts as an audio media endpoint, i.e. it is always in the media path. This minimises call routing and firewalling issues. The FireBrick uses the same IP for media and control messages on each call.

The FireBrick always acts as a SIP protocol endpoint and not as a relaying proxy. This minimises incompatibility between end devices being a party to a call as they do not see each other's protocol messages.
Only RTP audio using a-law 20ms is supported. This is generally compatible with all carriers and devices and provides high quality audio.
Out of band DTMF is accepted using SIP INFO or RFC2833. DMTF can be sent using RFC2833 or generated a-law in-band audio.
SIP address: Incoming calls can be made from the internet to sip:number@aa.org.uk and delivered just like a normal incoming call. The CLI is not trusted for such calls, so are sent to your SIP handset with a ? on the front, and not passed on if the call is diverted. Read more
As the system uses phone numbers the domain part is not relevant for registration and incoming SIP calls, but we recommend using the full E.164 number as the username part and aa.org.uk as the hostname, e.g. sip:+443333400200@aa.org.uk. We also accept calls to tel: URIs.

Note

Please bear in mind that some aspects of the service are not officially supported, so they may work or may not, and if they do not, then we may not be able to make them work for you. At the end of the day the VoIP service has no minimum term and if you are not happy you can terminate the service. Also, please remember that whilst we aim to ensure the service works all of the time, there is an agreed limit of liability if the service does not work (the amount we charged for the period it was not working).

@@ Line 2: / Line 2: @@
 ==Multiple servers==
-We operate multiple servers. These are configured using DNS and SRV records as well as A and AAAA records to ensure devices register and send calls via the currently active servers. We can change which servers are active from time to time.
+We operate multiple servers. DNS uses SRV records as well as A and AAAA records to ensure devices register and send calls via the currently active servers. We can change which servers are active from time to time.
 Some devices will stick to one server after an initial DNS look up, so we may reject a registration if we are taking that server out of action, but we aim to do that after DNS has already changed. Such devices will then re-check DNS and connect to the current servers.
@@ Line 13: / Line 13: @@
 *SIP/2.0 UDP control messages using IPv4 or IPv6 are supported up to approximately 1900 bytes (fragmented if necessary).
 The FireBrick always acts as an audio media endpoint, i.e. it is always in the media path. This minimises call routing and firewalling issues. The FireBrick uses the same IP for media and control messages on each call.
-*The FireBrick always acts as a SIP protocol endpoint and not as a relaying proxy. This minimises incompatibility between end devices being a party to a call as they do not see each others protocol messages.
+*The FireBrick always acts as a SIP protocol endpoint and not as a relaying proxy. This minimises incompatibility between end devices being a party to a call as they do not see each other's protocol messages.
 *Only RTP audio using a-law 20ms is supported. This is generally compatible with all carriers and devices and provides high quality audio.
 *Out of band DTMF is accepted using SIP INFO or RFC2833. DMTF can be sent using RFC2833 or generated a-law in-band audio.
-*SIP address: Incoming calls can be made from the internet to sip:number@aa.org.uk and delivered just like a normal incoming call. The CLI is not trusted for such calls, so are sent to your SIP handset with a ? on the front, and not passed on if the call is diverted.
+*SIP address: Incoming calls can be made from the internet to sip:number@aa.org.uk and delivered just like a normal incoming call. The CLI is not trusted for such calls, so are sent to your SIP handset with a ? on the front, and not passed on if the call is diverted. [[VoIP - Calling With a SIP URI|Read more]]
 *As the system uses phone numbers the domain part is not relevant for registration and incoming SIP calls, but we recommend using the full E.164 number as the username part and aa.org.uk as the hostname, e.g. sip:+443333400200@aa.org.uk. We also accept calls to tel: URIs.