These are possibly 'belt and braces' values but they have been working successfully for a considerable amount of time on a live server:
PEER Details:
username=<Your SIP Account ID> secret=<Your SIP Account Password> type=peer host=proxy.voip.co.uk insecure=very context=custom-get-did-from-sip
User Context:
custom-get-did-from-sip
Register String:
<Your SIP Account ID>:<Your SIP Account Password>@proxy.voip.co.uk/<Your SIP Account ID> Example: 012345:mypassword@proxy.voip.co.uk/012345
Note: In late November 2007, voip.co.uk started to migrate to their new server platform. Prior to this, the address 'registrar.voip.co.uk' could be used in the register string, but this is now deprecated.
In addition to asterisk not correctly processing SRV records (it only ever attempts the first one), asterisk 1.4.X also incorrectly populates the port from the SRV record in the authority of the request. An example of this is:
REGISTER 13 headers, 0 lines
Reliably Transmitting (no NAT) to 193.203.210.35:6060: REGISTER sip:proxy.voip.co.uk:6060 SIP/2.0
the 6060 in the R-URI “sip:proxy.voip.co.uk:6060” should not be there at all, asterisk is plucking out of the SRV record totally incorrectly.
So, there are 2 potential work arounds, both of which break redundancy and load balancing that SRV provides:
set srvlookup to off in your sip.conf:
srvlookup=no
Send all calls to proxy.voip.co.uk:5060, which (as per RFC 3263) disables the SRV lookup:
register => 123456:xxxx@proxy.voip.co.uk:5060/xxxx
additionally, ensure that all calls are sent to 5060 in your peer/dialplan configuration.
Sadly, Asterisk is broken when it comes to handling of both SRV and A records with multiple entries. VoIP.co.uk use these multiple records for redundancy in the face of network or hardware failure so you to continue making and receiving calls. Many ITSPs don't provide multiple records, and thus asterisk will work “out of the box”, yet there is no redundancy.
A quick overview of this issue with asterisk, should someone want to deal with digium to get it fixed:
Asterisk picks a single SRV record our of our pool:
# host -t srv _sip._udp.proxy.voip.co.uk _sip._udp.proxy.voip.co.uk has SRV record 0 0 6060 sbc1.b.synergy.voip.co.uk. _sip._udp.proxy.voip.co.uk has SRV record 0 0 6060 sbc2.b.synergy.voip.co.uk.
lets say for example's sake, asterisk chooses sbc1.b.synergy.voip.co.uk.
The REGISTER is sent by asterisk to sbc1.b, which is processed and works correctly.
A few minutes later, a call comes in from the PSTN. VoIP.co.uk look which SBC the UA was registered through, and sends the call to sbc1.b. sbc1.b forwards the call on to asterisk.
Asterisk receives the call, but has chosen sbc2.b.synergy.voip.co.uk as the record to use for the peer. Because of this, it fails to match it against the VoIP.co.uk peer, and treats the SIP call as if it has come from an unknown peer.
This is not a bug in VoIP.co.uk, but an issue with how asterisk handles registrations and peer matching. VoIP.co.uk provide multiple records for redundancy and scalability (which answers the question “but asterisk works for me with ITSP XXX, why does this problem exist with VoIP.co.uk?”).
If asterisk works with another ITSP out of the box, you should perhaps be asking why, as it indicates there is no redundancy and a single point of failure in their network.
There are 2 potential workarounds:
The first workaround may be suitable for some users, however there is a risk of SPIT using this option. To use this option, simple set your global context and the voip.co.uk peer one to the same value. Then, make sure that there is no way any resources could be used you don't want anyone on the internet to use, for example, being able to route calls back out to a SIP provider.
Remember that any SIP calls placed from ANYWHERE on the internet will now match the same context as calls coming from voip.co.uk, so ensure your config is checked.
What follows is an example configuration using the second option that works on asterisk 1.4, and perhaps 1.6. However, note that this uses single-01.proxy.voip.co.uk, a special host record configured by VoIP.co.uk which only has a single IP address in it's A record, and no SRV. Because of this, there is no load balancing or redundancy when using this hostname.
; When using the below configuration (or single-01.proxy.voip.co.uk), ; you only get the normal level of redundancy offered by any ITSP ; that asterisk works with normally. If you wish to use the ; redundant platform offered on proxy.voip.co.uk, please upgrade ; to a SIP UA that supports SRV, or contact digium for advice on ; how to use Asterisk with a ITSP that uses SRV for reundancy and ; scalability. [general] context = anonymous-sip nat=yes register => 123456:password@single-01.proxy.voip.co.uk:5060/MyIncomingExtension [voip.co.uk] type = peer secret = password fromuser = 123456 username = 123456 outboundproxy = single-01.proxy.voip.co.uk host = proxy.voip.co.uk fromdomain = proxy.voip.co.uk canreinvite = no insecure = no qualify = yes
For inbound call routing, you need to amend some configuration files to be able to match the incoming call CLI in the SIP From header.
PEER Details:
secret=<Your SIP Account Password> username=<Your SIP Account ID> type=peer host=proxy.voip.co.uk insecure=very context=custom-get-did-from-sip
User Context:
context=custom-get-did-from-sip
Register String:
<Your SIP Account ID>:<Your SIP Account Password>@proxy.voip.co.uk/<Your SIP Account ID> Example: 012345:mypassword@proxy.voip.co.uk/012345
Then add in the following to the file extensions_custom.conf
extensions_custom.conf:
[custom-get-did-from-sip]
exten => _.,1,Noop(Fixing DID using information from SIP TO header)
exten => _.,n,Set(pseudodid=${SIP_HEADER(To)})
exten => _.,n,Set(pseudodid=${CUT(pseudodid,@,1)})
exten => _.,n,Set(pseudodid=${CUT(pseudodid,:,2)})
exten => _.,n,Goto(from-trunk,${pseudodid},1)