The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Session Initiation Protocol (SIP) profiles change SIP incoming or outgoing messages so that interoperability between incompatible devices can be ensured.
SIP profiles can be configured with rules to add, remove, copy, or modify the SIP, Session Description Protocol (SDP), and peer headers that enter or leave CUBE.
You can use the following tool to test your SIP profile on an incoming message. http://cantor.cisco.com/sip-profiles.html
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
SIP Copylist:
Information About SIP Profile
Protocol translation and repair is a key Cisco Unified Border Element (CUBE) function. CUBE can be deployed between two devices that support the same VoIP protocol (For example. SIP), but do not interwork because of differences in how the protocol is implemented or interpreted. CUBE can customize the SIP messaging on either side to what the devices in that segment of the network expects to see by normalizing the SIP messaging on the network border, or between two non-interoperable devices within the network.
Service providers may have policies for which SIP messaging fields should be present (or what constitutes valid values for the header fields) before a SIP call enters their network. Similarly, enterprises and small businesses may have policies for the information that can enter or exit their networks for policy or security reasons from a service provider SIP trunk.
In order to customize SIP messaging in both directions, you can place and configure a CUBE with a SIP profile at the boundary of these networks.
In addition to network policy compliance, the CUBE SIP profiles can be used to resolve incompatibilities between SIP devices inside the enterprise network. These are the situations in which incompatibilities can arise:
The SIP profiles feature on CUBE provides a solution to these incompatibilities and customization issues.
SIP profiles can also be used to change a header name from the long form to the compact form. For example, From to f. This can be used as a way to reduce the length of a SIP message. By default, the device never sends the compact form of the SIP messages although it receives either the long or the short form.
Given below are a few important notes for SIP Profiles:
Inbound SIP Profile:
A SIP copylist is used to pass contents of headers in an incoming dial peer to an outgoing dial peer. This feature is used to pass unsupported, parameters of a mandatory headers from one leg to another. When a SIP message is received, a check is done for the header, and if it is available, it is copied into a list and passed on to the outbound dial peer leg.
Using a SIP profile with a copy and a modify rule configured:
Content from headers are copied into copy variables in the copy rule and pasted into other headers in the modify rule. If a header in a mandatory message is not supported by CUBE, configure passing of that header using a copylist and apply the rule to the incoming message.
To configure SIP Profiles, you must first configure the SIP Profile globally, and apply it at either to all dial peers (globally) or to a single dial peer (dial-peer level). Once a SIP profile is configured, it can be applied as an inbound or outbound profile.
1.
enable
2.
configure
terminal
3.
voice
class
sip-profiles
profile-id
4.
Add, remove,
modify, or copy SIP headers or responses:
5.
end
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
|
Enables privileged EXEC mode. |
Step 2 |
configure
terminal
|
Enters global configuration mode. |
Step 3 |
voice
class
sip-profiles
profile-id
Example: Device(config)# voice class sip-profiles 10 |
Creates a SIP Profiles and enters voice class configuration mode. |
Step 4 | Add, remove, modify, or copy SIP headers or responses: | According
to your choice, this step does one of the following:
Refer to Example: Adding a SIP, SDP, or Peer Header, Example: Modifying a SIP, SDP, or Peer Header, and Example: Remove a SIP, SDP, or Peer Header for more details. |
Step 5 |
end
|
Exits to privileged EXEC mode |
Now apply the SIP Profile as an inbound or outbound SIP profile.
1.
enable
2.
configure
terminal
3.
voice
class
sip-profiles
profile-id
4.
Add, remove,
modify, or copy SIP response headers:
5.
end
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable
|
Enables privileged EXEC mode. |
Step 2 |
configure
terminal
|
Enters global configuration mode. |
Step 3 |
voice
class
sip-profiles
profile-id
Example: Device(config)# voice class sip-profiles 10 |
Creates a SIP Profiles and enters voice class configuration mode. |
Step 4 | Add, remove,
modify, or copy SIP response headers:
| According to
your choice, this step does one of the following:
Refer to Example: Adding a SIP, SDP, or Peer Header, Example: Modifying a SIP, SDP, or Peer Header, and Example: Remove a SIP, SDP, or Peer Header for more details. |
Step 5 |
end
|
Exits to privileged EXEC mode |
Now apply the SIP Profile as an inbound or outbound SIP profile.
1.
enable
2.
configure
terminal
3.
Apply the SIP
profile to a dial peer:
4.
end
You can configure a SIP profile as an inbound profile applied globally or to a single inbound dial peer. Inbound SIP profiles feature must be enabled before applying it to dial peers.
1.
enable
2.
configure
terminal
3.
voice service voip
4.
sip
5.
sip-profiles
inbound
6.
Apply the
SIP profile to a dial peer:
7.
end
1.
show dial-peer voice
id |
include
profile
1.
debug ccsip all
Copying SIP headers from one message (request or response) to another is possible in one of the following ways:
To copy content from an incoming header that a device receives to an outgoing header, configure a SIP copylist for that header and apply it to an incoming dial peer. A SIP profile is configured to copy this incoming header to a user-defined variable and apply it to an outgoing header.
1.
enable
2.
configure
terminal
3.
voice
class
sip-copylist
tag
4.
Do one of
the following:
5.
exit
6.
dial-peer voice
inbound-dial-peer-tag
voip
7.
voice
class
sip-copylist
tag
8.
exit
9.
voice
class
sip-profiles
profile-id
10.
{request |
response}
message
peer-header sip
header-to-copy
copy
header-value-to-match
copy-variable
11.
{request |
response}
message {sip-header |
sdp-header}
header-to-modify
modify
header-value-to-match
header-value-to-replace
12.
exit
13.
dial-peer voice
inbound-dial-peer-tag
voip
14.
voice
class
sip-copylist
tag
15.
exit
Apply the SIP profile to an outbound dial peer.
1.
enable
2.
configure
terminal
3.
voice
class
sip-profiles
profile-id
4.
{request |
response}
message {sip-header |
sdp-header}
header-to-copy
copy
header-value-to-match
copy-variable
5.
{request |
response}
message {sip-header |
sdp-header}
header-to-modify
modify
header-value-to-match
header-value-to-replace
6.
end
Apply the SIP Profile to an outbound dial peer.
The SIP status line is a SIP response header, and it can be modified like any other SIP headers of a message. it can either be modified with a user-defined value, or the status line from an incoming response can be copied to an outgoing SIP response. The SIP header keyword used for the response status line is SIP-StatusLine.
You can copying the SIP response status-lines from one leg to another with the following steps
To copy content from the status line of an incoming SIP response that a device receives to an outgoing response, configure a SIP copylist for SIP status line and apply it to an incoming dial peer. A SIP profile must be configured to copy the status line of an incoming SIP response to a user-defined variable and apply it to an outgoing SIP response.
1.
enable
2.
configure
terminal
3.
voice
class
sip-copylist
tag
4.
sip-header
SIP-StatusLine
5.
exit
6.
dial-peer voice
inbound-dial-peer-id
voip
7.
voice-class sip copy-list
list-id
8.
exit
9.
voice
class
sip-profiles
tag
10.
response
response-code
peer-header
sip
SIP-StatusLine
copy
match-pattern
copy-variable
11.
response
response-code
sip-header
SIP-StatusLine
modify
match-pattern
copy-variable
12.
exit
Apply the SIP profile to the outbound dial peer to copy the SIP response to the outbound leg.
1.
enable
2.
configure
terminal
3.
voice
class
sip-profiles
tag
4.
response
response-code [method
method-type]
sip-header
SIP-StatusLine
modify
match-pattern
replacement-pattern
5.
exit
Associate the SIP profile with an outbound dial peer.
Configuration Examples for SIP Profiles
Device(config)# voice class sip-profiles 10 Device(config-class)# request INVITE sdp-header Video-Bandwidth-Info add "b=AS:4000" Device(config-class)# end
Device(config)# voice class sip-profiles 20 Device(config-class)# response 480 sip-header Retry-After add “Retry-After: 60” Device(config-class)# end
Device(config)# voice class sip-profiles 40 Device(config-class)# response 200 sip-header User-Agent add "User-Agent: SIP-GW-UA" Device(config-class)# end
! Applying SIP profiles globally Device(config)# voice service voip Device (config-voi-serv) sip-profiles 20 Device (config-voi-serv) end ! Applying SIP profiles to one dial peer only Device (config) dial-peer voice 10 voip Device (config-dial-peer) voice-class sip profiles 30 Device (config-dial-peer) voice-class sip profiles 40 Device (config-dial-peer) voice-class sip profiles 10 Device (config-dial-peer) end
Device(config)# voice class sip-profiles 30 Device(config-class)# request INVITE sip-header SIP-Req-URI modify "; SIP/2.0" ";user=phone SIP/2.0" Device(config-class)# request RE-INVITE sip-header SIP-Req-URI modify "; SIP/2.0" ";user=phone SIP/2.0" Device(config-class)# end
For example, modify 2222000020@10.13.24.7 to gateway@10.13.24.7
Device(config)# voice class sip-profiles 20 Device(config-class)# request INVITE sip-header From modify "(<.*:)(.*@)" "\1gateway@"
Device(config)# voice class sip-profiles 10 Device(config-class)# request INVITE sdp-header Session-Owner modify "CiscoSystems-SIP-GW-UserAgent“ "-"
For example, modify sip:2222000020@9.13.24.6:5060” to “tel:2222000020
Device(config)# voice class sip-profiles 40 Device(config-class)# request INVITE sip-header SIP-Req-URI modify "sip:(.*)@[^ ]+" "tel:\1" Device(config-class)# request INVITE sip-header From modify "<sip:(.*)@.*>" "<tel:\1>" Device(config-class)# request INVITE sip-header To modify "<sip:(.*)@.*>" "<tel:\1>"
Inbound ptime:
a=ptime:20
Outbound ptime:
a=ptime:30
Device(config)# voice class sip-profiles 103 Device(config-class)# request ANY sdp-header Audio-Attribute modify "a=ptime:20" "a=ptime:30"
Some service providers or customer equipment reply to delay offer invites and or re-invites that contain a=inactive with a=inactive, a=recvonly, or a=sendonly. This can create an issue when trying to transfer or retrieve a call from hold. The result is normally one-way audio after hold or resume or transfer or moh is not heard. To resolve this issue changing the audio attribute to Sendrecv prevents the provider from replaying back with a=inactive, a=recvonly, or a=sendonly.
Case 1:
Inbound Audio-Attribute a=inactive Outbound Audio-Attribute a=sendrecv
Case 2:
Inbound Audio-Attribute a=recvonly Outbound Audio-Attribute a=sendrecv
Case 3
Inbound Audio-Attribute a=sendonly Outbound Audio-Attribute a=sendrecv
Device(config)# voice class sip-profiles 104 Device(config-class)# request any sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv" Device(config-class)# request any sdp-header Audio-Attribute modify "a=recvonly" "a=sendrecv" Device(config-class)# request any sdp-header Audio-Attribute modify "a=sendonly" "a=sendrecv" Device(config-class)# response any sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv" Device(config-class)# response any sdp-header Audio-Attribute modify "a=recvonly" "a=sendrecv" Device(config-class)# response any sdp-header Audio-Attribute modify "a=sendonly" "a=sendrecv"
! Applying SIP Profiles globally Device(config)# voice service voip Device (config-voi-serv) sip-profiles 20 Device (config-voi-serv) sip-profiles 10 Device (config-voi-serv) sip-profiles 40 Device (config-voi-serv) sip-profiles 103 Device (config-voi-serv) sip-profiles 104 Device (config-voi-serv) exit ! Applying SIP Profiles to one dial peer only Device (config) dial-peer voice 90 voip Device (config-dial-peer) voice-class sip profiles 30
Device(config)# voice class sip-profiles 20 Device(config-class)# request ANY sip-header Cisco-Guid remove Device(config-class)# response ANY sip-header Cisco-Guid remove Device(config-class)# end
Device(config)# voice class sip-profiles 20 Device(config-class)# response 100 sip-header Server remove Device(config-class)# response 180 sip-header Server remove Device(config-class)# end
Most service providers require a ten digit diversion header. Prior to Call manager 8.6, Call manager would only send the extension in the diversion header. A SIP profile can be used to make the diversion header ten digits.
Call manager version 8.6 and above has the field “Redirecting Party Transformation CSS” which lets you expand the diversion header on the call manager.
The SIP profile will look for a diversion header containing "<sip:5..." , where ... stands for the three-digit extension and then concatenates 9789365 with these three digits.
Original Diversion Header:
Diversion:<sip:5100@161.44.77.193>;privacy=off;reason=unconditional;counter=1;screen=no
Modified Diversion Header:
Diversion: <sip:9789365100@10.86.176.19>;privacy=off;reason=unconditional;counter=1;screen=no
Device(config)# voice class sip-profiles 101 Device(config-class)# request Invite sip-header Diversion modify "<sip:5(...)@" "<sip:9789365\1@" Device(config-class)# end
Most service providers require a redirected call to have a diversion header that contains a full 10 digit number that is associated with a SIP trunk group. Sometimes, a SIP trunk may cover several different area codes, states, and geographic locations. In this scenario, the service provider may require a specific number to be placed in the diversion header depending on the calling party number.
In the below example, if the From field has an area code of 978 "<sip:978", the SIP profile leaves the From field as is and adds a diversion header.
Device(config)# voice class sip-profiles 102 Device(config-class)# request INVITE sip-header From modify "From:(.*)<sip:978(.*)@(.*)" "From:\1<sip:978\2@\3\x0ADiversion: <sip:9789365000@10.86.176.19:5060;privacy=off;reason=unconditional;counter=1;screen=no"
The below diversion header is added. There was no diversion header before this was added:
Diversion: <sip:9789365000@10.86.176.19:5060;transport=udp>"
Given below is a scenario in an organization, where the provider has sent only a global reference number in the SIP-Req-URI header of the INVITE message, and has placed the actual phone destination number only in the To: SIP header. The CUCM typically routes on the SIP-Req-URI.
Given below is the original SIP message, where the INVITE has a non-routable value of 43565432A5. The actual phone destination number is 25555552 and is present in the To: SIP header.
Given below is the SIP message that is required. Note that 43565432A5 has changed to 25555552 in the SIP INVITE.
Because CUBE is a back-to-back user agent, the incoming dial peer is matched to the outgoing dial peer. The SIP Profile configured below copies the value from the incoming dial peer
Device# voice class sip-profiles 1 !Copy the To header from the incoming dial peer into variable u01 Device(config-class)# request INVITE peer-header sip TO copy “sip:(.*)@” u01 !Modify the outgoing SIP Invite with this variable. Device(config-class)# request INVITE sip-header SIP-Req-URI modify “.*@(.*)” “INVITE sip:\u01@\1″
Apply the SIP profile to the incoming dial peer.
Device(config)# dial-peer voice 99 voip Device(config-dial-peer)# outgoing to CUCM Device(config-dial-peer)# destination-pattern 02555555. Device(config-dial-peer)# session protocol sipv2 Device(config-dial-peer)# session target ipv4:10.1.2.3 !Applying SIP profile to the dial peer Device(config-dial-peer)# voice-class sip profiles 1 Device(config-dial-peer)# voice-class code 1 Device(config-dial-peer)# dtmf-relay rtp-nte Device(config-dial-peer)# no vad
Additionally, if you would like to copy the To: Header from the inbound dial peer to the outbound dial peer, use a copy list.
!Create a copy List Device(config)# voice class sip-copylist 1 Device(config-class)# sip-header TO Device(config-class)# exit !Apply the copy list to incoming dial peer. Device(config)# dial-peer voice 1 voip Device(config-dial-peer)# description incoming SIP Trunk Device(config-dial-peer)# session protocol sipv2 Device(config-dial-peer)# session target sip-server Device(config-dial-peer)# incoming uri to TRUNK Device(config-dial-peer)# voice-class code 1 Device(config-dial-peer)# voice-class sip copy-list 1 Device(config)# voice class uri TRUNK sip Device(config-class)# user-id 2555555. Device(config-class)# end
CUBE does not pass “x-cisco-tip”. However, certain TelePresence equipments require “TIP”.
The SIP profile below will look for "x-cisco-tip" in the inbound contact header then pass it in the outbound contact header.
Inbound Contact Header
Contact: <sip:89016442998@161.44.77.193;transport=udp>;x-cisco-tip
Outbound Contact Header
Contact: <sip:89016442998@10.86.176.19:5060>;x-cisco-tip
Create a copylist to pass the Contact Header from the incoming message to the outgoing message. The “x-cisco-tip” is not copied in this step as it is unsupported by CUBE.
!Create a copyList Device(config)# voice class sip-copylist 1 Device(config-class)# sip-header Contact Device(config-class)# exit !Apply the copylist to incoming dial peer. Device(config)# dial-peer voice 1 voip Device(config-dial-peer)# description incoming SIP Trunk Device(config-dial-peer)# incoming called-number Device(config-dial-peer)# voice-class sip copy-list 1
Create a SIP profile that copies “x-cisco-tip” into a variable, and use that variable to modify the outgoing Contact header. Apply the SIP profile to an outbound dial peer.
Device# voice class sip-profiles 3001 !Copy the Contact header from the incoming dial peer into variable u01 Device(config-class)# request INVITE peer-header sip Contact copy "(;x-cisco-tip)" u01 !Modify the outgoing SIP Invite with this variable. Device(config-class)# request INVITE sip-header Contact modify "$" "\u01"″ !Apply the SIP Profile to the outgoing dial peer. Device(config)# dial-peer voice 5000 voip Device(config-dial-peer)# description outbound SIP Device(config-dial-peer)# destination-pattern 5...$ Device(config-dial-peer)# voice-class sip profiles 3001
The SIP profile configured is below:
voice class sip-profiles 1 request INVITE sdp-header Audio-Bandwidth-Info add "b=AS:1600“ request ANY sip-header Cisco-Guid remove request INVITE sdp-header Session-Owner modify "CiscoSystems-SIP-GW-UserAgent" "-“
The SIP INVITE message before the SIP profile has been applied is show below:
INVITE sip:2222000020@9.13.40.250:5060 SIP/2.0 Via: SIP/2.0/UDP 9.13.40.249:5060;branch=z9hG4bK1A203F From: "sipp " <sip:1111000010@9.13.40.249>;tag=F11AE0-1D8D To: <sip:2222000020@9.13.40.250> Date: Mon, 29 Oct 2007 19:02:04 GMT Call-ID: 4561B116-858811DC-804DEF2E-4CF2D71B@9.13.40.249 Cisco-Guid: 1163870326-2240287196-2152197934-1290983195 Content-Length: 290 v=0 o=CiscoSystemsSIP-GW-UserAgent 6906 8069 IN IP4 9.13.40.249 s=SIP Call c=IN IP4 9.13.40.249 t=0 0 m=audio 17070 RTP/AVP 0 c=IN IP4 9.13.40.249 a=rtpmap:0 PCMU/8000 a=ptime:20
INVITE sip:2222000020@9.13.40.250:5060 SIP/2.0 Via: SIP/2.0/UDP 9.13.40.249:5060;branch=z9hG4bK1A203F From: "sipp " <sip:1111000010@9.13.40.249>;tag=F11AE0-1D8D To: <sip:2222000020@9.13.40.250> Date: Mon, 29 Oct 2007 19:02:04 GMT Call-ID: 4561B116-858811DC-804DEF2E-4CF2D71B@9.13.40.249 Content-Length: 279 v=0 o=- 6906 8069 IN IP4 9.13.40.249 s=SIP Call c=IN IP4 9.13.40.249 t=0 0 m=audio 17070 RTP/AVP 0 c=IN IP4 9.13.40.249 a=rtpmap:0 PCMU/8000 a=ptime:20 b=AS:1600
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.