SIP trunks can mean many things, but generally a few important components make up any system that includes SIP trunks. We will have a look from both Service Provide (SP) and enterprise perspective.
Options for handling emergency calling include
■ Continuing to route emergency calls through your TDM PSTN gateways
■ Having a small number of TDM trunks dedicated to this function at the physical location of the service provider
■ Adopting a SIP-based emergency calling solution
Cisco Unified Communications deployments offer a rich set of supplementary services. With the use of SIP trunks, how these services operate might change, and you need to evaluate how they can be maintained when a SIP trunk brings external calls into your enterprise.
Following are different areas of supplementary services to evaluate:
■ Voice calls:
Telephony features such as call hold/resume, call transfer, call waiting, three-way conferencing, distinctive alerting, calling line identification (CLID), calling name, and call toggle can be provided by CUCM Express and CUCM for IP phones and by a voice gateway for analog phones. IP Centrex or Class 5 type features (for example, call forwarding, call screening, call park, call return, and so on) can be provided by central SIP servers resident in the service provider’s network.
Cisco Unified Voice Gateways send the access codes in the SIP INVITE message over the SIP trunk to the service provider to trigger these features.
■ Voice mail:
Message Waiting Indicator (MWI) is a visual light on IP phones; it is indicated by a stutter dial tone on analog phones. MWI for enterprise provided voice mail systems is not impacted by SIP trunking, but if a service provider hosted solution is chosen, MWI indications are provided via SIP indications (as per RFC-3842) from the service provider system and are relayed to the enterprise endpoints. Be sure to test these scenarios for SIP trunking if this is your deployment model.
Dual-tone multi-frequency (DTMF) interworking is often needed for voice mail as well. Even if all the communicating systems use SIP, there are various ways of relaying DTMF in SIP.
With SIP trunking entering your network, this is no longer the case. Codec choices are now end-to-end on the IP segments and enterprise endpoint negotiated codecs with external endpoints and application controlled by other networks. Codecs offered by external endpoint might be against the bandwidth (call admission control) policies of your enterprise network, or your older endpoints might be incapable of supporting some of the newer codec choices, resulting in failed calls or inappropriate bandwidth use on your network.
Sometimes SIP trunking is a cost-effective choice only when G.729 is the codec chosen (for bandwidth delivery reasons), especially for high volume contact centers operations.
For all these reasons, it might be necessary to do transcoding at the border of your enterprise network to change the codec to the appropriate one before these calls enter your network. Local Digital Signal Processing (DSP) can provide transcoding for a call that uses a high-bandwidth codec such as G.711 on one side and a low-bandwidth codec such as G.729 or Internet Low-Bitrate Codec (iLBC) on the other side.
You may not have to do this for some sip trunk provider, ask if nay header part needs to be modified first.
voice service voip sip sip-profiles 1 voice class sip-profiles 1 request INVITE sip-header From modify “(<.*:)(.*@)” “\[email protected]” request INVITE sip-header To modify “<(.*)>” “<\1;phone-context=gateway>”
Original SIP INVITE
INVITE sip:22220000205060 SIP/2.0
Via: SIP/2.0/UDP 126.96.36.199:5060;branch=z9hG4bK1AD9E2
Remote-Party-ID: “sipp “ <sip:[email protected]>;party=calling;screen=no;privacy=off
From: “sipp “<sip:firstname.lastname@example.org>;tag=23C3F840-99A
To: <sip:[email protected]>
Normalized SIP INVITE
INVITE sip:22220000205070 SIP/2.0
Via: SIP/2.0/UDP 188.8.131.52:5060;branch=z9hG4bK1191BFD
Remote-Party-ID: “sipp “ <sip:[email protected]>;party=calling;screen=no;privacy=off
From: “sipp “<sip:email@example.com>;tag=1EDB2D94-11DD
To: <sip:[email protected];phone-context=gateway>
Remove sip-header Cisco-Guid
voice class sip-profiles 100 request ANY sip-header Cisco-Guid remove response ANY sip-header Cisco-Guid remove
Registration and Authentication ( credential and Authentication)
You can use SIP mechanisms to validate the originator of a SIP call and therefore provide a mechanism to reject SIP INVITEs that come from rogue endpoints. These mechanisms include:
■ Registration: Some service provider SIP trunk offerings include a registration sequence enabling the enterprise edge to register explicitly with the provider’s SIP softswitch. Some SIP applications are capable of this; if not you can have your CUBE do the registration on behalf of the endpoints behind it in the enterprise network. you configure this with command
credential under sip-ua.
This affects the inbound call, without this, the incoming call will get a user busy notice.
x(config)#sip-ua x(config-sip-ua)#registrar ipv4:172.16.193.97 expires 3600 x(config-sip-ua)#credentials username 1001 password cisco realm cisco.com
■ Digest Authentication (RFC-2617): A SIP softswitch can challenge the INVITEs, and the originator must respond with credentials that are then authenticated by the SIP softswitch. This is configured by command
This is used for outbound call.
sip-ua authentication username xxx password yyy
Unlike a SIP registration sequence that happens once, the Digest Authentication happens on every SIP INVITE. The CUBE can respond to Digest Authentication challenges with configured credentials.
- End to end
- Peer to peer
For more about this: check here http://frankfu.click/cisco/cisco-voip/sip-trunk-registration.html
Delayed Offer (DO) or early offer (EO)
SIP delayed offer (DO) and early offer (EO). SIP DO means no session description protocol (SDP) information specifying the session attributes such as codec choice is included in the initial INVITE for the call setup. SIP EO means an SDP is included in the initial call setup INVITE.
SIP trunk service providers offer an explicit UNI specification of which message types, formats, and fields are valid on their service offering. For the enterprise to comply with this UNI, it is often easier to place a border element at the edge of the network to normalize all the variants from different enterprise applications and endpoints than to try to configure each individual application or endpoint to comply with the UNI. It is especially so if the enterprise connects to multiple different SIP trunk providers, perhaps for least-cost routing or for redundancy purposes.
With sip connection , we can do port forward for udp/tcp 5060, but for the RTP audio connection, those UDP ports are not able to be configured in one command, which need one for each port.
One solution is ICE-lite:
sip-ua connection-reuse ...
The “connection-reuse” ensures that the uses the same source & destination port (UDP 5060) for all SIP requests. By default the source port is usually ephemeral (meaning random) inline with RFC3261.
“voice-class sip outbound-proxy” is meant to change the actual L3 destination for the SIP messages – instead of sending the SIP message to the SIP proxy server (defined in sip-server CLI). The reason this is useful is if the ITSP wants all SIP messages to go to their domain (say sip.itsp.com which may not be resolvable) but be fronted by an SBC (session border controller) as the “outbound-proxy”. It is also used for NAT traversal. Again this has nothing to do with “re registration”.
use MTP solution:
The “mtp” solution is better because of complications with opening up firewall ports. The media packets flowing over a WAN may be obstructed by a firewall. This means that you need to open ports on the firewall, but which ones? With CME relaying the audio, firewalls can be easily configured to pass the RTP packets. CME router uses a specific UDP port(2000!) for media packets. So, by just allowing packets to and from port 2000, ALL RTP traffic can be passed.
ephone 1 mac 1111.2222.3333 type 7965 mtp button 1:1
All is not wonderful with mtp. There are situations where mtp may not be desirable
- MTP is not gentle on CPU utilization
- Multicast MOH generally cannot be forwarded over a WAN- The Multicast MOH feature checks to see if MTP is enabled for a phone and if it is, does not send MOH to that phoneL.
Source IP address trusted list
All of these configurations require that you are already running 15.1(2)T in order for you to make the configuration change.
- Explicitly enable those source IP addresses from which you would like to add to the trusted list for legitimate VoIP calls. Up to 100 entries can be defined. This below configuration accepts calls from those host 203.0.113.100/32, as well as from the network 192.0.2.0/24. Call setups from all other hosts are rejected. This is the recommended method from a voice security perspective.
voice service voip ip address trusted list ipv4 203.0.113.100 255.255.255.255 ipv4 192.0.2.0 255.255.255.0
- Configure the router to accept incoming call setups from all source IP addresses.
voice service voip ip address trusted list ipv4 0.0.0.0 0.0.0.0
- Disable the toll-fraud prevention application completely.
voice service voip no ip address trusted authenticate
Call forwarding and transfering
Call forwarding allows you to send all your incoming calls to another landline or cell phone number. Call forwarding overrides the ability to answer the phone forwarded from the original line. This service requires a subscription through your phone service provider and may incur an additional monthly fee.
Call forwarding in SIP trunk
When a call comes in on a SIP trunk and gets forwarded (CFNA / CFB / CFA), then the default behavior is for the CME to send the 302 “Moved Temporarily” SIP message to the Service Provider (SP) proxy. The user portion of the Contact Header in the 302 message might need to be translated to reflect a DID that the SP proxy can route to. Or else, the calling user will get an busy tune.
One of following method should be used:
1) The host portion of the Contact Header in the 302 message should be modified to reflect the Address of Record (AOR) :
!--- Voicemail Configuration --- dial-peer voice 10 voip description **CUE Voicemail** translation-profile outgoing PSTN_CallForwarding destination-pattern 600 b2bua !--- Used by CME to send its IP address to SP proxy instead of CUE session protocol sipv2 session target ipv4:172.22.1.155 dtmf-relay sip-notify !--- This can also be RFC2833 going to CUE codec g711ulaw !--- CUE only supports G711ulaw as the codec no vad !--- With VAD enabled, messages left on CUE could be blank or poor quality
host-registrar CLI under sip-ua and the b2bua CLI under the VoIP dial peer going to the CUE.
2 ) Some SIP proxies might not support this. If so, then you need to add this:
Router(config)#voice service voip
Router(conf-voi-serv)#no supplementary-service sip moved-temporarily
When a call comes in on an SIP trunk to an SCCP Phone or CUE AutoAttendant (AA) and is transferred, the CME by default will send a SIP REFER message to the SP proxy. Most SP Proxy Servers do not support the REFER method.
This needs to be configured in order to force the CME to hairpin the call by command
no supplementary-service sip refer
voice service voip supplementary-service h450.12 allow-connections h323 to h323 no supplementary-service sip refer telephony-service transfer-system full-consult transfer-pattern .T
- The configuration shown in the preceding example turns on the H.450.2 (transfer-system full-consult) and H.450.12 services.
- allows VoIP-to-VoIP hairpin call routing (allow-connections) for calls that don’t support H.450, and permits transfers to all possible destinations (transfer-pattern).
- The transfer permission is set to .T to provide full wildcard matching for any number of digits. (The T stands for terminating the transfer destination digit entry with a timeout.)
The following example shows a configuration for more restrictive transfer permissions.
telephony-service transfer-system full-consult transfer-pattern 1... transfer-pattern 2... blind
Music on Hold
No Music to PSTN using SIP Cube toward ITSP? Use the below SIP Profile statement to allow Music on hold to stream toward the PSTN.
Create (or append if you are already using sip-profiles) a sip-profile voice class and add statements.
voice class sip-profiles 1 request REINVITE sdp-header Audio-Attribute modify “inactive” “sendrecv” request ACK sdp-header Audio-Attribute modify “sendonly” “sendrecv” response 200 sdp-header Audio-Attribute modify “sendonly” “sendrecv”
Apply the sip-profiles globally or on the Dial-Peer.
Voice service voip sip sip-profiles 1
** DIAL-PEER **
Voice-class sip profiles 1
Toll Fraud: https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/112083-tollfraud-ios.html#topic1
NAT config for CUCM: https://support.siptrunk.com/hc/en-us/articles/207210343-CISCO-CALL-MANAGER-FULL-CONFIG-BEHIND-LAN
SIP profile: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-sip-param-mod.html
Understand SIP trace with ITSP: https://community.cisco.com/t5/collaboration-voice-and-video/understanding-sip-traces/ta-p/3137704
SIP Registration Proxy: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_sipsip/configuration/xe-3s/asr1000/cube-sipsip-xe-3s-asr1000-book/voi-sip-reg-proxy.html
- ‘Early offer’ only ?
- Authentication digest
- RTP ports range from the SP
- physical location awareness: SIP-based emergency calling solution
- porting activity
- SIP header format expected from SP, an example would be great.