134
1 IMG SIP Specifications Click here to view a PDF file of all topics related to SIP The IMG supports SIP (Session Initiation Protocol), based on RFC 3261 backward compatible with entities running RFC 2543 SDP (Session Description Protocol) based on RFC 2327 and RFC 3551 Outbound Registration (IMG can register with other entities). The IMG does not support inbound registration, since it is not applicable for Media Gateways. The IMG acts as a User Agent (UA) and can interoperate with SIP proxies. The IMG can act as a UAC (User Agent Client) or a UAS (User Agent Server) Transcoding via SIP The ingress leg and the egress leg of the call can have different codecs. Transcoding can occur between G.711 U-law, G.711 A-law, G.723, and G.729. Interworking SIP to SS7 based on RFC 3398. SIP to ISDN Redirect Server Support SIP Diversion Header SIP Re-origination SIP Proxy SIP INFO Method for DTMF Diagram The following diagram shows an example of the IMG in a SIP network.

Sip

Embed Size (px)

DESCRIPTION

Sip

Citation preview

Page 1: Sip

1

IMG SIP Specifications

Click here to view a PDF file of all topics related to SIP

The IMG supports

SIP (Session Initiation Protocol), based on RFC 3261

backward compatible with entities running RFC 2543

SDP (Session Description Protocol) based on RFC 2327 and RFC 3551

Outbound Registration (IMG can register with other entities). The IMG does not support inbound registration, since it is not applicable for Media Gateways.

The IMG acts as a User Agent (UA) and can interoperate with SIP proxies. The IMG can act as a UAC (User Agent Client) or a UAS (User Agent Server)

Transcoding via SIP

The ingress leg and the egress leg of the call can have different codecs. Transcoding can occur between G.711 U-law, G.711 A-law, G.723, and G.729.

Interworking

SIP to SS7 based on RFC 3398.

SIP to ISDN

Redirect Server Support

SIP Diversion Header

SIP Re-origination

SIP Proxy

SIP INFO Method for DTMF

Diagram

The following diagram shows an example of the IMG in a SIP network.

Page 2: Sip

SIP

2

Related Topics

SIP Features

Page 3: Sip

3

SIP Features The IMG supports the following SIP features:

SIP Profiles

A SIP Profile allows you to easily assign a number of SIP features to a Physical IMG. You create a SIP Profile and then assign profiles to a gateway in the External Gateway pane. You can also assign a SIP Profile to a SIP Signaling object, which will indicate to another IMG should treat a call going to or coming from the IMG.

The following features can be configured/enabled in a SIP Profile.

SIP Redirect Support (3xxx Redirect and Diversion Header)

SIP Re-Origination Attempts

SIP Proxy Handling

SIP Trunk Group Selection

SIP Info Method for DTMF

Loop Detection

Specific SIP Header Support

These features are described below.

See SIP Profile pane reference.

SIP-T

The IMG supports SIP-T for interworking between SIP and SS7 ISUP for call setup, call tear down, and conversion of message formats for SIP Bridging, that is, a call that originates in the PSTN, goes into a SIP network, and terminates in the PSTN again. See An Overview of SIP-T for more information.

DNS (Domain Name Server) lookup.

The IMG can route SIP traffic to a remote entity based on the IP Address or the Host Name. The IMG supports having multiple DNS servers for Redundancy and reliability purposes. See Configuring DNS for SIP.

SIP Privacy

See SIP Privacy.

SIP Re-origination

The feature allows you to re-originate a call on another gateway to limit the amount of unnecessary bandwidth utilization on your network. By using less re-origination

Page 4: Sip

SIP

4

attempts, less SIP messages go out to the network, which in effect reduces the bandwidth used.

Another benefit is the savings in time that the physical resources are allocated for a call that will never complete. By reducing the re-origination attempts, the call attempt will be torn-down sooner and the physical resources associated with the call will be released sooner.

You enable this feature in the SIP Profile.

SIP INFO Method for DTMF

This feature allows the use of the SIP INFO method to send a DTMF digit to another gateway. The voice stream is established after a successful SIP 200 OK-ACK message sequence.

You enable this feature with the DTMF Support w/SIP Info field in the SIP Profile pane.

See SIP INFO Method for DTMF for more details.

Symmetric NAT Traversal

Symmetric NAT Traversal for SIP signaling provides the following:

Ability to specify the connection role of the IMG when acting as a UAC or UAS.

Enable interoperability in networks where NAT devices are unaware of SIP or SDP signaling. SIP endpoints may both be outside NAT or one inside and the other outside.

See Symmetric NAT Traversal.

SIP Trunk Group Selection

Page 5: Sip

SIP Features

5

Use these features if you have a Centralized Routing Model and do not require the IMG to perform routing decisions. These features are enabled or disabled in the SIP Profile, which can be assigned on a SIP Gateway or SIP Signaling basis.

Incoming Originating Trunk Group (OTG) Selection

When the OTG field is included in the “From” header the IMG will use this trunk group as the incoming trunk group to determine which route table to use. The OTG will also be able to be added to the “From” header in an outbound SIP INVITE (the OTG will have the A side trunk group name).

The IMG extracts the OTG from the SIP "From" header and passes it in the initial Setup. If an OTG is found, the IMG will use that channel group instead of the one that came from the lookup table in the SIP process.

Incoming Destination Trunk Group (DTG) Selection

When the DTG is received in the request-URI the IMG will skip the mid-call router and use the DTG that was received as the outbound channel group.

When the IMG is about to perform routing for the outbound side, it will look for the DTG from the same location as the Calling Party Number. If the DTG is valid, the call will then use the channel group that corresponds to that DTG instead of performing a routing lookup

Outgoing Destination Trunk Group (DTG) Selection

On an outgoing invite, the OTG that was received from the incoming call will take precedence over the internal IMG incoming channel group name if it was a SIP call (for any other inbound protocol, the OTG would be the incoming Trunk Group Name). This OTG is then appended in the “From” header of the outbound invite.

SIP Diversion Header

The IMG supports the INVITE Diversion Header (Diversion and CC-Diversion) to support PSTN Redirecting Services (also known as Call Forwarding). The INVITE Diversion header carries information about the redirection. The Diversion header prevents this pertinent SS7 redirection information from being lost in the SS7 to SIP conversion. When SS7 redirection information is received on the incoming side, it is relayed in the Diversion header on the outgoing SIP side

You enable this feature in the SIP Profile.

See SIP Diversion Scenarios.

Non-Standard Tags in From Header

You can allow non-standard tags in the From header in the SIP Profile pane.

isup-oli support

cic support

SIP Proxy Handling

See SIP Proxy Handling.

Page 6: Sip

SIP

6

SIP Redirect Server Support

See SIP Redirect Server Support.

SIP Carrier Identification Code

See SIP Carrier Identification Code.

ISUP-OLI

See SIP ISUP OLI.

Pass through ‘+’ sign in the user part of URI

The IMG supports the passing of the ‘+’ sign from the incoming SIP side to the outgoing SIP side, or the removal of the "+" if you do not want to pass it through. This process is only applied to INVITE.

Configuration

You enable this feature in the SIP Profile with the Append (+) for Headers and Remove (+) for Headers fields.

You can apply this feature to the following headers in the INVITE:

R_URI

FROM

TO

P_ASSERTED

P_PREFERRED

REMOTE_PARTY_ID

NOTE: The Contact header is not put into the bit mask, but ‘+’ is supported in the Contact header if it is included in the incoming Contact.

NOTE: The ‘+’ is not supported for routing or translation; only a simple pass through.

SIP Based Load Balancing

See SIP-Based Load Balancing.

G.729 AnnexB Selection

The media attribute "Annexb=no" can be sent by the IMG in the SIP SDP, when enforcing the use of the G.729a payload type.

Page 7: Sip

SIP Features

7

The annexb setting is available in the GUI Bearer Profile configuration for G.729 and G.729E payloads. The default selection yes, or Not Used, ensures that the existing IMG behavior is maintained for backwards compatibility.

Note that the media attribute "Annexb=yes" is not sent by the IMG in a SIP SDP, as this value is implied when unspecified in the SDP.

This feature is configured using the Vocoder Entry pane.

SIP Update

Overview

The UPDATE method allows a UAC to update parameters of a session, such as the SDP and session timers. , and has no impact on the state of a dialog. In that sense, it is like a re-INVITE, except that it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.

The UPDATE method allows a greater control over a SIP session including, but not limited to, the following parameters:

SDP (for example, to set the media on hold during early media)

Session timers (for example, to adjust call duration in a prepaid application)

The IMG supports the following for SIP UPDATE:

an UPDATE request that is received before or after the initial INVITE transaction is completed and when a dialog exists (early or confirmed), in accordance with RFC 3261.

the validation of an SDP contained in an UPDATE follows the existing restrictions of the offer/answer model (RFC 3264).

The IMG will reject an UPDATE request that is meant as a FAX re-INVITE. Although it is possible, the RFC does not recommend the use of the UPDATE method in this fashion

RFC

3311 SIP UPDATE Method

Configuration

The SIP UPDATE method is to be accepted by the IMG without user intervention, and therefore cannot be disabled. There is no configuration involved.

Related Topics

SIP Update Call Flows

SIP Gateway Busy Out

See SIP Gateway Busy Out.

Page 8: Sip

SIP

8

SIP CODEC Negotiation Priority

This feature allows you to configure whether the IMG or the remote gateway takes priority when selecting a codec.

Example:

If the IMG has a CODEC list of:

g711u

g729

g711a

and a remote gateway offers:

g729

g711u

If the Codec Negotiation Priority is set to Local, the IMG will answer with g711u.

If the Codec Negotiation Priority is set to Remote, the IMG will answer with g729.

Benefits

The feature gives you the flexibility to choose CODEC priority on either IMG or the far end gateway.

Configuration

You configure CODEC Negotiation Priority to either Local or Remote in the SIP Profile pane.

SIP PRACK

See SIP PRACK

Page 9: Sip

9

SIP Fax/Modem Initially, the IMG establishes a normal voice call using an audio codec. The IMG negotiates T.38 support once the voice path is established.

Case where the IMG is terminating a fax call:

Once a fax data mode has been detected at the IP bearer level, SIP will send a RE-INVITE message to the distant end. The IMG supplies a T.38 port and parameters in a SIP RE-INVITE SDP and waits for the remote SIP gateway to accept with an OK including a corresponding SDP.

Case where the IMG is originating a fax call:

Once a fax data mode has been detected at the IP bearer level, SIP will accept a RE-INVITE message from the distant end. The IMG will reply with a Fax port in a SIP 200 OK SDP and will wait for the remote SIP gateway to accept with an ACK.

T.38 or fax bypass modes are supported. The IMG allows G.711 A-Law or G.711 u-Law only for fax/modem bypass codecs.

RTP redundancy levels will apply to fax bypass packets (RTP G.711 packets), but not to T.38 packets.

Fax Redundancy level setting applies only to T.38 fax relay packets (not to RTP voice or fax bypass packets).

Fallback to Fax Bypass

The Fax Fallback feature is a backup mechanism to transmit a fax using Fax Bypass mode when T.38 cannot be negotiated successfully. This feature allows you to configure T.38 Fax Relay as the preferred type, and also allow Bypass Fax when T.38 is not supported by the remote end. The added negotiation will therefore reduce the call setup failure rate by increasing the content of the media offer.

In the event neither a T.38 fax nor a Bypass fax can be established in a fax fallback scenario, the IMG allows the voice call to proceed as if no negotiation had happened.

Page 10: Sip
Page 11: Sip

11

Supported SIP Messages

RE-INVITE Message

The INVITE method is used to establish media sessions between User Agents. The RE-INVITE message permits the IMG to change parameters of an existing or pending call.

The SIP software supports the following:

RE-INVITE messages that change the port to which media should be sent.

RE-INVITE messages that change the connection address or media type.

Media stream on hold (connection address is zero).

Initial INVITE messages on hold.

RE-INVITE messages for FAX (T.38 and Bypass).

SIP SUBSCRIBE/NOTIFY

The IMG accepts user agent subscription requests (SIP SUBSCRIBE method) and the ability to respond to those user agents with the appropriate DTMF digit events via the SIP NOTIFY method. Only DTMF-events are currently supported.

SIP UPDATE

The UPDATE method allows a UAC to update parameters of a session, such as the SDP and session timers.

The UPDATE method allows a greater control over a SIP session including, but not limited to, the following parameters:

SDP (for example, to set the media on hold during early media)

Session timers (for example, to adjust call duration in a prepaid application)

Early Media

Early media is the ability of two SIP User Agents to communicate before a SIP call is actually established. Typically, this scenario occurs when the called party is a PSTN gateway. Before the call is set up, the gateway might provide in-band tones or announcements that inform the caller of the call progress.

Early media can involve the transfer of media from caller to callee. Within the PSTN, forward channels can be established to convey DTMF signaling to select a final destination to call. This feature can be used to access Interactive Voice Response (IVR) systems “behind” 800 numbers.

Implementation

connects the media path prior to the 200 OK message.

supports pre-answer DTMF and announcements.

Page 12: Sip

SIP

12

converts the SS7 Call Progress (CPG) message to a 183 response message with SDP.

When the called party wishes to send early media to the caller, the called party sends a 183 response to the caller. That response contains the SDP. When the caller receives the 183 response, it suppresses any local alerting of the user (for example, audible ring tones or pop-up window) and plays out media that it receives.

If the call is ultimately rejected, that called party generates a non-2xx final response. When the caller receives this response, the caller stops playing out or sending media. If the call is accepted, the called party generates a 2xx response and sends that to the caller. Media transmission continue as before.

Authentication and Outbound Registration

Cantata has implemented SIP Authentication which includes protective measures to prevent an active attacker from modifying and replaying SIP requests and responses.

SIP authentication enables the Cantata platform to provide its own credentials (login/password based scheme) to other gateways. It ensures that only valid users can make calls through the Cantata platform.

The cryptographic measures are used to ensure the authenticity of the SIP message and authenticate the originator of the message as being the IMG. SIP extends the HTTP WWW Authenticate and Authorization header field and their Proxy- counterparts to include cryptographically strong signatures.

Session Timers

SIP Session Timers are an extension of SIP RFC 2543 which allows a periodic refreshing of SIP sessions using the RE-INVITE message. The refreshing allows both user agents and proxies to determine if the SIP session is still active.

Page 13: Sip

13

SIP Redirect Server Support

This feature allows the IMG to respond to the 3XX class of SIP messages returned from a redirect server. 3xx responses provide information about a user's new location, or alternative services that may be able to satisfy the call. This feature is based on RFC 3261 section 8.1.3.4 and RFC 2543.

In a SIP network it is very common to have a re-direct server which determines where to route the call. The redirect server may reply to the IMG with a 300 response with a list of contacts to try. The IMG will try each one of those contacts one at a time, until the call is completed, to a maximum of 10 attempts. The IMG will only accept redirects to another endpoint in the SIP network. The endpoint does not have to be one of the configured SIP external gateways.

This feature is enabled by default in the SIP Profile.

Notes

The maximum number of redirects is 10.

The same IP Profile is used for all attempts.

Once a contact has responded with a 180 Ringing or 183, the IMG will not make any more redirect attempts

Not Supported

Simultaneous redirects

Redirection to another Channel Group

3xx Responses for Registration Requests

380 Responses (they will be mapped to 410 Gone error code and released)

305 Response (they will be mapped to 410 Gone error code and released)

Location changes are not saved internally

The IMG cannot be redirected back to the PSTN

3XX Response Mapping

If this feature is not enabled, the IMG will map the 3xx responses to 4xx responses, as shown below:

Redirection (3xx) Response

Maps to 4xx (client error) response

300 Multiple choices 410 Gone

301 Moved Permanently 410 Gone

302 Moved Temporarily 480 Temporarily Unavailable

305 Use Proxy 410 Gone

Page 14: Sip

SIP

14

380 Alternative Service 410 Gone

any other 3xx response 410 Gone

Page 15: Sip

15

Example Call Flow: SIP Redirect

Page 16: Sip
Page 17: Sip

17

SIP 3XX Redirect Responses 3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call.

300 Multiple Choices

The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location.

301 Moved Permanently

The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field (Section 20.10). The requester SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed.

302 Moved Temporarily

The requesting client SHOULD retry the request at the new address(es), given by the Contact header field (Section 20.10. The Request-URI of the new request uses the value of the Contact header field in the response.

305 Use Proxy

305 provides information for next hop to reach proxy server. The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs.

3xx is enable by default on the IMG and is configurable with the SIP SGP on a per gateway basis.

Page 18: Sip
Page 19: Sip

19

SIP Proxy Handling This feature allows the IMG to interact with SIP Proxy Servers and Session Border Controllers as intermediate routes between domains. The IMG can route SIP traffic to these SIP entities (SIP proxies) and with the knowledge of their final destination (remote SIP UA).

A SIP Proxy receives SIP requests from a client, even though it may not be the server resolved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can learn about one through auto-configuration protocols.

You can configure one SIP Outbound Proxy Server for each external SIP gateway using the SIP Proxy pane under a SIP Profile and then assign that profile to the External Gateway.

References

RFC 3261 Session Initiation Protocol

RFC 2543 Session Initiation Protocol

UA Supported

Outbound proxy handling (non-redundant)

Outbound registration to outbound proxy

Re-invite and 3xx Redirect to outbound proxy

Page 20: Sip
Page 21: Sip

21

EXAMPLE SIP Call: Using an Outbound Proxy

Example of Eyebeam UAC sending an SIP Request to an outbound proxy

Outbound proxy: 10.129.39.37:5060 [IMG has no equivalent config param]

Domain: 10.129.39.38:5060 [IMG equivalent is remote gateway]

Dialed number: [email protected] [IMG equivalent is remote gateway]

Client IP address: 10.129.39.115:5062 [IMG equivalent is SIP stack IP:port]

SENDING TO: 10.129.39.37:5060

INVITE sip:[email protected];transport=udp SIP/2.0

To: <sip:[email protected]>

From: 33871<sip:[email protected]>;tag=7224787d

Via: SIP/2.0/UDP 10.129.39.115:5062;branch=z9hG4bK-d87543-426271217-1--d87543-;rport

Call-ID: b93d6c09661e5564

CSeq: 1 INVITE

Contact: <sip:[email protected]:5062;transport=udp>

Max-Forwards: 70

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

Content-Type: application/sdp

User-Agent: eyeBeam release 3004w stamp 16863

Content-Length: 182

v=0

o=- 5790011 5790033 IN IP4 10.129.39.115

s=eyeBeam

c=IN IP4 10.129.39.115

t=0 0

m=audio 7244 RTP/AVP 18 101

a=fmtp:101 0-15

a=rtpmap:101 telephone-event/8000

a=sendrecv

Page 22: Sip
Page 23: Sip

23

SIP Diversion Header Scenarios

For information on the SIP Diversion Header feature, see SIP Diversion Header.

SIP Call Forwarding Scenario

IMG1010

|

--IAM--------------------------------->|

Called Party Number =+19195551004 |

Redirecting Number =+19195551002 |

Address Presentation =presentation restricted

Original Called Number =+19195551001 |

RedirectionInformation: |

Original redirecting reason = Unconditional (1111)

Redirecting Reason = User busy (0001)

Redirection counter = 5 |

|

|--INVITE +19195551004------>

| Diversion: <tel:+19195551002>

| ;reason=user-busy

| ;privacy="full"

| ;counter=4

| Diversion: <tel:+19195551001>

| ;reason=unconditional

| ;counter=1

|

|

SIP-SS7 Call Forwarding Scenario

IMG1010

|

|<--INVITE +19195551004------

| Diversion: <tel:+19195551002>

Page 24: Sip

SIP

24

| ;reason=user-busy

| ;privacy="full"

| ;counter=4

| Diversion: <tel:+19195551001>

| ;reason=unconditional

| ;counter=1

|

|

|

<--IAM---------------------------------|

Called Party Number =+19195551004 |

Redirecting Number =+19195551002 |

Address Presentation =presentation restricted

Original Called Number =+19195551001 |

RedirectionInformation: |

Original redirecting reason = Unconditional (1111)

Redirecting Reason = User busy (0001)

Redirection counter = 5 |

ISDN-SIP Call Forwarding Scenario

IMG1010

|

--Setup------------------------------->|

Called party number =+19195551004

Redirecting number information element:

Redirecting number =+19195551001

Reason for redirection = Unconditional (1111)

Origin of Number = passed network screening

Presentation Status = presentation allowed

Redirecting number information element:

Redirecting number =+19195551002

Reason for redirection = User busy (0001)

Origin of Number = passed network screening

Presentation Status = presentation prohibited

Page 25: Sip

SIP Diversion Scenarios

25

|

|--INVITE tel:+19195551004---->

| Diversion: <tel:+19195551002>

| ;reason=user-busy

| ;screen="yes"

| ;privacy="off"

| Diversion: <tel:+19195551001>

| ;reason=unconditional

| ;screen="yes"

| ;privacy="full"

|

|

SIP-ISDN Call Forwarding Scenario

IMG1010

|

<--Setup-------------------------------|

Called party number =+19195551004

Redirecting number information element:

Redirecting number =+19195551001

Reason for redirection = Unconditional (1111)

Origin of Number = passed network screening

Presentation Status = presentation allowed

Redirecting number information element:

Redirecting number =+19195551002

Reason for redirection = User busy (0001)

Origin of Number = passed network screening

Presentation Status = presentation prohibited

|

|<--INVITE tel:+19195551004----

| Diversion: <tel:+19195551002>

| ;reason=user-busy

| ;screen="yes"

| ;privacy="off

Page 26: Sip

SIP

26

| Diversion: <tel:+19195551001>

| ;reason=unconditional

| ;screen="yes"

| ;privacy="full"

|

Page 27: Sip

27

SIP SUBSCRIBE/NOTIFY Method for DTMF

Overview

The IMG accepts user agent subscription requests (SIP SUBSCRIBE method) and the ability to respond to those user agents with the appropriate DTMF digit events via the SIP NOTIFY method. Only telephone-events are currently supported.

RFC: 3265 Session Initiation Protocol (SIP)-Specific Event Notification

Benefits

You can develop user-specific applications that reside on your network entity and have the ability to subscribe for event services supported by the IMG. If the network entity wants the ability to detect an entered DTMF digit from the TDM-side of a call to the IP side of a call, the entity can subscribe to the IMG for these events and receive SIP NOTIFY events containing the digit event.

Limitations

Only patterns of 1-4 pound ("#") characters are supported

The ‘Pending’ state is not supported

The IMG cannot send a SIP SUBSCRIBE

Configuration

You enable and configure this feature with the SIP DTMF Support pane. In the Method field select Subscribe and then configure other fields as required.

Call Flows

Page 28: Sip

SIP

28

Page 29: Sip

SIP SUBSCRIBE/NOTIFY Method for DTMF

29

Page 30: Sip

SIP

30

Call Tracing

Each SIP request received or transmitted for the SIP SUBSCRIBE and NOTIFY methods will be displayed in the normal call tracing. For the NOTIFY method, the trace will also display the NOTIFY method’s payload. In the case of detected DTMF digits, the ‘###’ will be displayed in the call tracing.

Example Trace

The following is an example call trace showing SIP Subscribe Notify for DTMF. Related lines are in bold.

---> [10.129.55.74, 5060]

SUBSCRIBE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.129.55.74:5060

From: 7340 <sip:[email protected]:5060>;tag=1

Page 31: Sip

SIP SUBSCRIBE/NOTIFY Method for DTMF

31

To: 8519 <sip:[email protected]:5060>;tag=a94c095b773be1

dd6e8d668a785a9c84113d

Call-id: [email protected]

Cseq: 1 SUBSCRIBE

Contact: <sip:[email protected]:5060;transport=UDP>

Event: telephone-event;duration=300

Expires: 600

Content-Length: 0

18:17:08.733 SIP (W)

<--- [10.129.55.74, 5060 <- 10.129.55.80, 5060]

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.129.55.74:5060;received=10.129.55.74

Call-ID: [email protected]

From: 7340 <sip:[email protected]:5060>;tag=1

To: 8519 <sip:[email protected]:5060>;tag=a94c095b773be1

dd6e8d668a785a9c84113d

CSeq: 1 SUBSCRIBE

Server: Cantata-SIP/10.3.3.129 SIP-Gateway1 0

Expires: 600

Content-Length: 0

<--- [10.129.55.74, 5060 <- 10.129.55.80, 5060]

NOTIFY sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.129.55.80:5060;rport;branch=z9hG4bK- 5c5e-1163009828-19999-33

Call-ID: [email protected]

CSeq: 1 NOTIFY

Max-Forwards: 70

To: <sip:[email protected]>;tag=1

From: <sip:[email protected]>;tag=a94c095b773be1dd6e8d668a785a9c84113d

User-Agent: Cantata-SIP/10.3.3.129 SIP-Gateway1 0

Event: telephone-event;duration=300

Subscription-State: Active;expires=600

Content-Length: 0

18:17:08.753 SIP (W)

Page 32: Sip

SIP

32

---> [10.129.55.74, 5060]

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.129.55.80:5060;rport;branch=z9hG4bK- 5c5e-1163009828-19999-33

From: <sip:[email protected]>;tag=a94c095b773be1dd6e8d668a785a9c84113d

To: <sip:[email protected]>;tag=1;tag=1

Call-ID: [email protected]

CSeq: 1 NOTIFY

Contact: <sip:10.129.55.74:5060;transport=UDP>

Content-Length: 0

NOTIFY sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.129.55.80:5060;rport;branch=z9hG4bK-d37-1163009863-19998-33

Call-ID: [email protected]

CSeq: 2 NOTIFY

Max-Forwards: 70

To: <sip:[email protected]>;tag=1

From: <sip:[email protected]>;tag=a94c095b773be1dd6e8d668a785a9c84113d

User-Agent: Cantata-SIP/10.3.3.129 SIP-Gateway1 0

Event: telephone-event;duration=300

Subscription-State: Active;expires=125

Content-Type: application/dtmf-relay

Content-Length: 26

Signal= #

Duration= 160

18:17:43.893 SIP (W)

---> [10.129.55.74, 5060]

SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.129.55.80:5060;rport;branch=z9hG4bK-d37-1163009863-19998-33

From: <sip:[email protected]>;tag=a94c095b773be1dd6e8d668a785a9c84113d

To: <sip:[email protected]>;tag=1;tag=1

Call-ID: [email protected]

Page 33: Sip

SIP SUBSCRIBE/NOTIFY Method for DTMF

33

CSeq: 2 NOTIFY

Contact: <sip:10.129.55.74:5060;transport=UDP>

Content-Length: 0

Troubleshooting

If you are experiencing problems with this feature, ensure the following:

Subscribe is enabled in the SIP SGP

The correct SIP SGP is assigned to the External Remote Gateway

Page 34: Sip
Page 35: Sip

35

SIP INFO Method for DTMF

This feature allows the use of the INFO method to send a DTMF digit to another gateway.

You enable this feature using the SIP DTMF Support pane.

The only implementation currently supported is the sending of the pound (#) character in response to the configured number of pound (#) characters received (1-4).

NOTE: A more robust method to use for sending DTMF digits in SIP is SIP SUBSCRIBE/NOTIFY Method for DTMF.

# Character

After a match of the configured number of ‘#’ characters in the voice stream, the IMG will send a # character in the SIP INFO to the same endpoint to which the 200 OK ACK was sent. The voice stream is established after a successful SIP 200 OK-ACK message sequence. The SIP INFO will contain a SIP header of Signal (showing the # character) and the duration header (showing the length in milliseconds of the duration to play the # signal).

SIP INFO Header

The existing header of the SIP INFO method will be modified to carry the digit.

Signal parameter - used to carry the ‘#’ character in the SDP.

Duration parameter - used in the SDP to store the length of time in milliseconds to play the digit.

Content-Type header - will be changed to dtmf-relay when this feature is invoked.

The following shows a SIP INFO header with the changes:

INFO sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 150.129.38.217:5060;rport;branch=z9hG4bK-1170-1145483948-19998-190

Call-ID: [email protected]

CSeq: 2 INFO

Max-Forwards: 70

To: <sip:[email protected]>;tag=75001a07

From: <sip:[email protected]>;tag=95ffcd055e0f78f7d5d397020e89288de8b1

User-Agent: Excel-Open-SIP/10.3.1.56 MFG_5 0

Timestamp: 04192006215908

Page 36: Sip

SIP

36

Accept: application/sdp

Content-Length: 26

Content-Type: application/dtmf-relay

Signal= #

Duration= 120

Call Flow: # Character in SIP INFO

Page 37: Sip

37

SIP Busy Out The IMG can monitor the status of external SIP gateways by sending periodic SIP OPTIONS messages. If the gateway does not respond in a configured amount of time the IMG will mark the gateway as down and attempt to re-route the call to a different gateway.

RFC

RFC 3261 SIP: Session Initiation Protocol, Section 11.

Configuration

SIP Profile

External Gateway

Configuration

You enable the SIP Busy Out feature on a specific gateway in the External Gateway pane (OPTIONSKeepalive field).

You configure the Busy Out parameters in the SIP Options KeepAlive pane.

The parameters to be configured are:

Timer to define the interval between OPTIONS when the gateway is responsive.

Timer to define the interval between OPTIONS when the gateway is non responsive.

Number of responses received before marking the gateway as reachable.

EventView Alarm

A SIP gateway Alarm in EventView indicates the status of a particular SIP Gateway.

This alarm will contain the status (either “unreachable” or “reachable”) and the ip address of this particular Gateway.

Call Tracing

Call Tracing will capture the sending/reception of the OPTIONS method and indicate that re-routing has taken place because the gateway is down.

Example Call Trace

21:24:03.305 SIP (W)

<--- [10.129.43.154, 5060 <- 10.129.43.23, 5060]

OPTIONS sip:10.129.43.154:5060;ttl=0 SIP/2.0

Via: SIP/2.0/UDP 10.129.43.23:5060;rport;branch=z9hG4bK-

6df4-1156281802-19999-423

Call-ID: [email protected]

Page 38: Sip

SIP

38

CSeq: 1 OPTIONS

Max-Forwards: 70

To: <sip:10.129.43.154;ttl=0>

From: <sip:10.129.43.23>;tag=95ffcd055e0f78f7d5d397020e8

9288db5f2

User-Agent: Cantata-SIP/10.3.2.57 chiloe 0

Contact: <sip:10.129.43.23:5060>

Accept: application/sdp

Content-Length: 0

Implementation Details

When sending a 200 OK to an OPTIONS request the IMG will not include SDP information.

If an OPTIONS message is not answered the correspondent gateway will be marked as “down or unreachable”.

When a call is attempted to an “unreachable” gateway, the IMG will automatically trigger the re-attempt logic.

A gateway will only be marked as “reachable” when the number of sequential responses meet a configurable value.

The IMG will keep sending OPTIONS request at a configurable rate.

Page 39: Sip

39

SIP Carrier Identification Code (CIC)

Overview

This feature enables the IMG to receive and transmit the Carrier Identification Code (CIC) parameter between the SIP network and SS7. This preserves the remote user’s carrier identity over different networks and allows you the send mixed traffic over a trunk group.

The CIC parameter is a three- or four- digit code used in routing tables to identify the network that serves the remote user when a call is routed over many different networks. The CIC parameter is carried in SIP INVITE requests and maps to the Carrier Identification Parameter (CIP) or the Transit Network Selection (TNS) parameter in ISUP.

The ‘cic’ tag is included in the ‘sip’ R-URI.

Example:

INVITE sip:044;[email protected]:5060 SIP/2.0

Call Flows

SS7 to SIP

This call flow shows where the IMG receives a call setup request from the PSTN/SS7 with the carrier information code (cic). This cic parameter will appear in the SIP URI of the INVITE request.

Page 40: Sip

SIP

40

SIP to SS7 ANSI

This call flow shows where the IMG receives an INVITE with the SIP URI containing the ‘cic’ tag. The IMG will send a call setup request to the SS7 ANSI with the carrier information parameter.

SIP to SS7 ITU

This call flow shows where the IMG receives an INVITE with the SIP URI containing the ‘cic’ tag. The IMG will send a call setup request to the SS7 ITU with the Transit Network Selection.

Page 41: Sip

SIP Carrier Identification Code

41

SIP to SIP

Page 42: Sip

SIP

42

Troubleshooting

If you are experiencing problems with this feature, check the following:

Make sure CIC is selected in the R-URI Header Tags field of the SIP SGP.

Make sure the correct SGP is assigned to the External Gateway.

The incoming IAM must contain a value in the CIP or TNS for IMG to pass this value in the SIP INVITE.

The IMG forwards the cic parameter only if it appears in the format below:

INVITE sip:044;[email protected]:5060 SIP/2.0

Page 43: Sip

43

SIP ISUP OLI (ANSI Only) The ISUP OLI (also know as II digits) parameter includes information that is used for carriers to determine the origin of a call. This information gets lost over SIP networks if not inter-worked properly. This feature allows carrying ANSI ISUP OLI Parameter from traditional TDM network into SIP and vice versa.

This information is passed in the From: header of the INVITE message.

Example

From: “Anonymous”<sip:[email protected];isup-oli=00>;tag=95ffcd055e0f78f7d5d397020e89288d63d4

Common ISUP-OLI codes

00 = Ordinary POTS call - not payphone

01 = Party line

02 = ANI Failure

27 = Payphone with network provided coin control

70 = Payphone without network provided coin control

Call Flows

SS7 to SIP

The following call flow shows where the IMG receives a call setup request from the PSTN/SS7 with the OLIP. With the ISUP-OLI feature this ISUP-OLI parameter will appear in the From header of the INVITE request

Page 44: Sip

SIP

44

SIP to SS7

The following call flow shows where the IMG receives an INVITE with the From Header containing the ‘ISUP-OLI’ tag. With the ISUP-OLI feature, the IMG will send a call setup request to the PSTN/SS7 with the OLI parameter.

Page 45: Sip

SIP ISUP OLI

45

Page 46: Sip
Page 47: Sip

47

SIP Session Timer Call Flows

IMG is UAC and does the refresh

IMG requests session timer by including Session-Expires header on the INVITE. IMG receives 422 Session Interval Too Small response with Min-SE header. IMG sends out new INVITE with Min-SE and updated Session-Expires value. IMG receives 200 OK that set session timer to 1800 seconds and IMG as the refresher. IMG starts 900 seconds session refresh timer. After refresh timer expires, IMG sends out refresh request with Session-Expires value set to current value 1800 seconds and refresher to UAC. IMG receives 200 OK and resets the timer. Once again IMG sends out refresh request after session refresh timer expires, but now the remote gateway crashed so that IMG receives 408 Request Timeout. IMG sends out BYE and the call is terminated.

IMG is UAC and remote gateway does the refresh

IMG sends INVITE that has Supported header with option tag ‘timer’ and Session-Expires to request session timer. The remote gateway accepts it. The session interval is set to 1800 seconds and refresher is the remote gateway. IMG starts 1768 seconds session end timer. IMG receives session refresh request before the session end timer expires. IMG sends 200 OK back and set refresher to UAC so that the role of refresher doesn’t change. IMG restarts 1768 seconds session end timer. Now the remote gateway crashes and no refresh request sent. 1768 seconds later the session end timer expires, IMG sends out BYE and terminates the call.

Page 48: Sip

SIP

48

IMG is UAS and remote gateway does the refresh

IMG receives INVITE that has Supported header with option tag ‘timer’. IMG sends 200 OK and requests session timer by including Require header with tag ‘timer’ and Session-Expires header. The session interval is set to 1800 seconds and refresher is the remote gateway. IMG starts 1768 seconds session end timer. IMG receives session refresh request before the session end timer expires. IMG sends 200 OK back and set refresher to UAC so that the role of refresher doesn’t change. IMG restarts 1768 seconds session end timer. Now the remote gateway crashes and no refresh request sent. 1768 seconds later the session end timer expires, IMG sends out BYE and terminates the call.

IMG is UAS and does the refresh

IMG receives INVITE that has Supported header with option tag ‘timer’ and Session-Expires header with 90 seconds value. Since IMG’s minimum session timer is configured to 1800 seconds, IMG sends back 422 response with Min-SE header set to 1800. Then the remote gateway sends new INVITE with updated session timer and IMG accepts it. The session interval is set to 1800 seconds and refresher is IMG. IMG

Page 49: Sip

SIP Session Timer Call Flows

49

starts 900 seconds session refresh timer. After refresh timer expires, IMG sends out refresh request with Session-Expires value set to current value 1800 seconds, refresher is set to UAC so that ensure IMG will always perform refresh. IMG receives 200 OK and resets the timer. Once again IMG sends out refresh request after session refresh timer expires, but now the remote gateway crashed so that IMG receives 408 Request Timeout. IMG sends out BYE and the call is terminated.

IMG is UAC and Requests Session Timer

IMG requests session timer by including Session-Expires header on the INVITE. IMG receives 200 OK without Session-Expires header that indicates the remote gateway does no support session timer. Since IMG is configured to enforce session timer, IMG sets session interval to 1800 seconds and refresher to ‘UAC’. IMG starts 900 seconds session refresh timer. After refresh timer expires, IMG sends out refresh request with Session-Expires value set to current value 1800 seconds and refresher to UAC. IMG receives 200 OK and resets the timer. Once again IMG sends out refresh request after session refresh timer expires, but now the remote gateway crashed so that IMG receives 408 Request Timeout. IMG sends out BYE and the call is terminated.

Page 50: Sip

SIP

50

IMG is UAS and configured to enforce session timer on INVITE

IMG receives INVITE that the Supported header does not contain tag ‘timer’. IMG sends back 200 OK. Since IMG is configured to enforce session timer, IMG sets session interval to 1800 seconds and refresher is ‘UAS’ IMG starts 900 seconds session refresh timer. After refresh timer expires, IMG sends out refresh request with Session-Expires value set to current value 1800 seconds, refresher is set to UAC so that ensure IMG will always perform refresh. IMG receives 200 OK and resets the timer. Once again IMG sends out refresh request after session refresh timer expires, but now the remote gateway crashed so that IMG receives 408 Request Timeout. IMG sends out BYE and the call is terminated.

Page 51: Sip

51

SIP ENUM The IMG supports ENUM E2U+sip to resolve an ENUM telephone number into a SIP URI. With ENUM native SIP users, even at different VoIP service providers, can call each other directly without ever touching a PSTN service which can result in faster connection times and lower phone charges.

ENUM facilitates the interconnection of systems that rely on telephone numbers with those that use URIs to route transactions. E.164 is the ITU-T standard international numbering plan, under which all globally-reachable telephone numbers are organized.

RFC

RFC 3764 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record

Benefits

This feature is required when:

a user is calling from the PSTN through a PSTN-SIP gateway and the gateway is expected to map routing information from the PSTN directly on to SIP signaling.

a native SIP user intentionally initiates a call addressed to an E.164 number.

Although this task is also accomplished by SIP Proxy Servers, there is value in adding the ENUM behavior in the IMG gateway as a way to minimize the proxy’s activities and centralize the number translation functions in the UA.

Application servers may initiate SIP calls destined to end users and transiting through the IMG.

Configuration

1. Configure ENUM servers with the ENUM Server pane.

2. Configure a SIP Channel Group.

3. Configure a IP Network Element

4. Configure a Route Table.

Page 52: Sip

SIP

52

5. Add a Route Entry with the Outgoing Channel Group pointing to the ENUM Channel Group.

Call Tracing

Indication of Feature function: CLI will display a query being sent to the ENUM Server as well as the response from the ENUM Server.

Indication of Feature rejection:

CLI will display an error that the ENUM Query has failed to the following:

a) Entry does not exist.

b) Query timed out

Page 53: Sip

53

SIP Reason Header The Reason Header field for the Session Initiation Protocol (SIP) is included in BYE, CANCEL, 4XXs, 5XXs, and 6XXs messages to indicate why a SIP request or response was issued. Clients and servers are free to ignore this header field as it has no impact on protocol processing.

Benefits

This feature is useful for debugging purpose, particularly if there is a call failure in SIP to SS7 traffic.

Implementation

Cause Number 1 (404 message)

When a call is generated from SIP side and SS7 receives an IAM and releases the call with cause number 1, the IMG then would send a 404 message with cause indicating Unallocated (unassigned) number.

Call Flow

Call Trace

<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]

SIP/2.0 404 Not Found Call processing released

Via: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-672bb759901c9e2a-1--d87543-;rport;received=10.129.39.1 23

Contact: <sip:10.129.39.59:5060>

Call-ID: 2b61265d2e589e06ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.

From: "Boston"<sip:[email protected]>;tag=f818c458

To: "508"<sip:[email protected]>;tag=a94c095b773be1dd6e8d668a785a9c8449dc

CSeq: 1 INVITE

Server: Cantata-SIP/10.3.2.22 Boston 0

Reason: Q.850 ;cause=1 ;text="Unallocated (unassigned) number"

Content-Length: 0

Cause Number 17 (486 message)

The 486 message with cause 17 that indicates User Busy is sent out by IMG to SIP when SS7 side releases the call with cause 17.

Page 54: Sip

SIP

54

Call Flow

Call Trace

<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]

SIP/2.0 486 Busy Here Call processing released

Via: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-af44ae69a320e04a-1--d87543-;rport;received=10.129.39.1 23

Contact: <sip:10.129.39.59:5060>

Call-ID: 1c214262d2299f3cZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.

From: "Boston"<sip:[email protected]>;tag=244d4425

To: "508"<sip:[email protected]>;tag=a94c095b773be1dd6e8d

668a785a9c84c527

CSeq: 1 INVITE

Server: Cantata-SIP/10.3.2.22 Boston 0

Reason: Q.850 ;cause=17 ;text="User busy"

Content-Length: 0

Cause Number 16 (BYE message)

Cause number 16 is normal call clearing.

Call Flow

Call Trace

<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]

BYE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.129.39.59:5060;rport;branch=z9hG4bK-3a95-46623-19995-361

Call-ID: [email protected]

CSeq: 2 BYE

Max-Forwards: 70

To: <sip:[email protected]:5060>;tag=8262313b

From: <sip:[email protected]>;tag=95ffcd055e0f78f7d5d397020e89288d2b07

User-Agent: Cantata-SIP/10.3.2.22 Boston 0

Reason: Q.850 ;cause=16 ;text="Normal call clearing"

Content-Length: 0

Page 55: Sip

SIP Reason Header

55

Cause Number 3 (404 message)

If the user dials an incorrect number that is not in the route table the IMG will reject the call and send a 404 Not Found to the SIP side.

Call Flow

Call Trace

<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]

SIP/2.0 404 Not Found Call processing released

Via: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-47486a49a1277175-1--d87543-;rport;received=10.129.39.1

23

Contact: <sip:10.129.39.59:5060>

Call-ID: 3355d752f5739754ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.

From: "Boston"<sip:[email protected]>;tag=2816b75a

To: "999"<sip:[email protected]>;tag=a94c095b773be1dd6e8d668a785a9c84de15

CSeq: 1 INVITE

Server: Cantata-SIP/10.3.2.37 Boston 0

Reason: Q.850 ;cause=3 ;text="No route to destination"

Content-Length: 0

Cause Number 1 (404 message)

In case the user dials correct number but incoming translation table has wrong number, then IMG would reject the call and send a 404 Not Found to the SIP side.

Call Flow

Call Trace

<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]

SIP/2.0 404 Not Found Call processing released

Via: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-47486a49a1277175-1--d87543-;rport;received=10.129.39.1

23

Page 56: Sip

SIP

56

Contact: <sip:10.129.39.59:5060>

Call-ID: 3355d752f5739754ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.

From: "Boston"<sip:[email protected]>;tag=2816b75a

To: "999"<sip:[email protected]>;tag=a94c095b773be1dd6e8d668a785a9c84de15

CSeq: 1 INVITE

Server: Cantata-SIP/10.3.2.37 Boston 0

Reason: Q.850 ;cause=1 ;text="Unallocated (unassigned) number"

Content-Length: 0

SIP to SIP

In the case of SIP to SIP traffic, the Reason header field is usually not needed in responses because the status code and the reason phrase already provide sufficient information, according to RFC 3326. However, the Reason Header is included for BYE, 4XXs, 5XXs, and 6XXs. Please note that CANCEL message in the SIP to SIP traffic does not include the Reason header field.

Call Flow

Call Trace

<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]

BYE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP 10.129.39.59:5060;rport;branch=z9hG4bK-2701-1786-19997-394

Call-ID: [email protected]

CSeq: 2 BYE

Max-Forwards: 70

To: <sip:[email protected]:5060>;tag=d47d7510

From: <sip:[email protected]>;tag=95ffcd055e0f78f7d5d397020e89288d708e

User-Agent: Cantata-SIP/10.3.2.37 Boston 0

Reason: SIP ;cause=16 ;text="Normal call clearing"

Content-Length: 0

487 Message

In the case below, where SIP sends an INVITE message and then sends CANCEL, the IMG sends a 487 Request Terminated in response to the CANCEL message.

Call Flow

Page 57: Sip

SIP Reason Header

57

Call Trace

<--- [10.129.39.123, 5070 <- 10.129.39.59, 5060]

SIP/2.0 487 Request Terminated

Via: SIP/2.0/UDP 10.129.39.123:5070;branch=z9hG4bK-675e-1160585843-19988-10-129-39-123;received=10.129.39.123

Contact: <sip:10.129.39.59:5060>

Call-ID: [email protected]

From: sipp <sip:[email protected]:5070>;tag=1

To: sut <sip:[email protected]:5060>;tag=a94c095b773be1dd6e8d668a785a9c84e50d

CSeq: 1 INVITE

Server: Cantata-SIP/10.3.2.37 Boston 0

Reason: SIP ;cause=487 ;text="Request Terminated"

Content-Length: 0

Page 58: Sip
Page 59: Sip

59

SIP Call Hold

This feature allows the IMG to process a re-INVITE from a SIP endpoint that places a call on hold or releases a hold. This addition complements the support for SIP Hold ( via 0.0.0.0 ip address) by supporting RFC 3398 section 9, allowing for the proper Interworking of hold information between SIP and SS7.

RFC

RFC 3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping: section 9

Call Flows

Suspend then Resume from SS7 side

Upon receiving a SUS message from the remote SS7 side, the IMG sends a re-Invite to the remote SIP side with the Connection IP address set to 0.0.0.0 in order to request that gateway to place the call on hold.

Page 60: Sip

SIP

60

Suspend then Resume from SIP side

Upon receiving a re-Invite with the connection address equal to a valid IP address for a call that has been placed on hold, the IMG sends a CPG message with the notification indicator set to ‘remote hold released’ to the remote SS7 ANSI side.

Page 61: Sip

SIP Call Hold

61

Suspend then Resume from SS7 side when SIP-T is enabled

When SIP-T is enabled, the IMG will encapsulate the RES message received into an Info message instead of sending a Re-invite to the SIP side.

Page 62: Sip

SIP

62

Page 63: Sip

63

SIP-Based Load Balancing

This feature allows you to distribute SIP traffic between IMGs configured as “SIP Servers” using Virtual IP Addresses and a SIP load balancer.

The IMG allows you to configure a Virtual IP addresses (VIP) in addition to the existing Real IP address. The IP address set allows SIP calls to be terminated concurrently on any of the IP addresses, real or virtual. The deployment of multiple IMG products sharing Virtual IP addresses creates in effect a set of redundant SIP signaling paths.

Accounting for capacity and the balancing algorithm are configured on the Load Balancer, not the IMG.

Diagram - SIP-Based Load Balancing

Load balancers can create pools of IMG gateways, all sharing the same Virtual IP addresses. The diagram below shows the relationship between these network endpoints.

Load Balancers

Load balancers automatically detect when a server is unavailable using “heartbeats”, either through ICMP Ping or SIP OPTIONS. Load balancing takes place between the set of IMGs reachable through such heartbeats. This provides increased VoIP network availability by routing traffic through “healthy” signaling paths. It also reduces the number of re-transmitted SIP INVITEs and consequently increases the overall call completion rate.

This activity is commonly described using one of the following terms:

Server Load Balancing (SLB)

Describe Switchback Routing (DSR)

Direct Server Response (DSR)

The use of Virtual IP addresses on the IMG enables seamless integration of load balancers in a Cantata solution.

Page 64: Sip

SIP

64

Load balancers are not SIP-specific, however they are SIP-aware in order to route subsequent transactions for an existing call to the correct gateway/IMG. Load balancers have redundant features and can be geographically distributed.

NOTE: A SIP proxy could also be used to load balance SIP traffic, however it would use the actual IMG IP address and not the MAC address; therefore, the Virtual IP Address could not be used.

Related Topics

Configuring SIP-Based Load Balancing

SIP Virtual Address

Network Interface

Page 65: Sip

65

SIP-T

Why Enable SIP-T ?

You should implement SIP-T (SIP for Telephones) when a call is passing from the PSTN, through a SIP network, and back to the PSTN, so that no SS7 information is lost.

Overview

The IMG supports SIP-T for interworking between SIP and SS7 ISUP for call setup, call tear down, and conversion of message formats for SIP Bridging, that is, a call that originates in the PSTN, goes into a SIP network, and terminates in the PSTN again.

SIP-T provides ISUP transparency between the PSTN switches handling the call by encapsulating the incoming ISUP messages in the body of the SIP message. The ingress IMG places the incoming ISUP messages in the SIP body and the ISUP messages generated by the egress IMG are the ones present in the SIP body. For mid-call messaging, The INFO message is used to transport mid-call signaling messages that do not have a one-to-one mapping to SS7 ISUP messages like INR and INF.

SIP Bridging

Page 66: Sip
Page 67: Sip

67

SIP PRACK

Brief Description

Improves network reliability and supports additional call flows.

RFC

3262 - Reliability of Provisional Responses in the Session Initiation Protocol (SIP)

Overview

There are two types of responses defined by SIP that are provisional and final. Final responses convey the result of the request processing and are sent reliably.

There are certain scenarios in which the provisional SIP responses must be delivered reliably. For example, in a SIP/PSTN inter-working scenario, a loss of 180 or 183 messages cannot be afforded. To solve this problem, the SIP PRACK method guarantees reliable and ordered delivery of provisional responses in SIP.

Configuration

SIP Profile

IP Network Element

Diagram - SIP PRACK Handshake

UAC - UAS Behaviour

The following table shows the overall behavior of UAS and UAC with various SGP configuration combinations.

UAC UAS Call Processing

SGP: PRACK Disabled SGP: PRACK Disabled

Normal Call

Page 68: Sip

SIP

68

SGP: PRACK Disabled SGP: PRACK Supported

Normal Call

SGP: PRACK Disabled SGP: PRACK Require Call Rejected

SGP: PRACK Supported

SGP: PRACK Disabled

Normal Call

SGP: PRACK Supported

SGP: PRACK Supported

PRACK Call

SGP: PRACK Supported

SGP: PRACK Require PRACK Call

SGP: PRACK Require SGP: PRACK Disabled

Call Rejected

SGP: PRACK Require SGP: PRACK Supported

PRACK Call

SGP: PRACK Require SGP: PRACK Require PRACK Call

Call Tracing

Success

16:32:35.762 CALL(SIP) (00:0004:00) SENT 183 Session Progress Reliable (100rel) to 10.129.45.102:8000 UDP

16:32:35.782 CALL(SIP) (00:0004:00) RCVD PRACK from 10.129.45.102:8000 Cseq:2 with Via sent-by: 10.129.45.102 UDP

16:32:35.782 CALL(SIP) (00:0004:00) SENT 200 OK PRACK to 10.129.45.102:8000 UDP

Failure

21:16:47.845 CALL(SIP) (01:00004:00) SENT 421 Extension Required [PRACK support is required] to 10.129.45.104:5060 Cseq:1

21:18:09.286 CALL(SIP) (01:00005:00) SENT 420 Bad Extension [Unsupported SIP request arrived at L3UA-TUC] to 10.129.45.104:5060 Cseq:1

Troubleshooting

If you are experiencing problems with this feature, check the following:

Make sure PRACK is enabled in the SIP SGP

Make sure the correct SIP SGP is assigned to the External Gateway

The External Gateway must support PRACK.

Page 69: Sip

69

SIP PRACK Call Flows

Changes to Basic Call Flow with PRACK enabled

The call flow on the left highlights the changes when PRACK is enabled, as compared to the call flow on the right without PRACK enabled.

UAS Honors UAC’s Preference

This call flow shows the call flow when UAS and UAC are set to PRACK Supported option.

UAS Agrees to UAC’s Enforcement

This call flow shows when UAS and UAC are set to PRACK Require option.

Page 70: Sip

SIP

70

UAS Ignores UAC’s Preference

This call flow shows the call flow when UAS is PRACK Supported and UAC is PRACK Disable.

UAS Rejects UAC’s Enforcement

This call flow shows the call flow when UAS is PRACK Require and UAC is PRACK Disable.

UAS Insists UAC MUST Support 100rel

This call flow shows the call flow when UAS is PRACK Disable and UAC is PRACK Require.

Page 71: Sip

SIP PRACK Call Flows

71

UAC Insists on Reliable Delivery of Provisional Responses

This call flow shows when UAS is configured with PRACK Require option.

IMG Acts as UAC and UAS

Page 72: Sip

SIP

72

Page 73: Sip

73

An Overview of SIP Configuration

Related Topic

An Introduction to SIP

Prerequisites

Configure IP Bearer Profiles

Configure VoIP

Configure Facilities

Summary of Tasks

1. Configure an External SIP Gateway

2. Configure a SIP Profile (Optional)

3. Configure SIP Signaling

4. Configure SIP Routing

5. Configure DNS for SIP (Optional)

ClientView Panes for SIP Configuration

SIP Signaling

SIP Timers

External Gateway

Channel Group

DNS Server

Page 74: Sip

SIP

74

First Task

Configuring SIP Signaling

Page 75: Sip

75

Configuring SIP Signaling

Before you Begin

Configure SIP Profile (Optional)

A SIP Profile allows you to easily assign a number of SIP features to a Physical IMG. You create a SIP Profile and then assign profiles to a gateway in the External Gateway pane. You can also assign a SIP Profile to a SIP Signaling object, which will indicate to another IMG should treat a call going to or coming from the IMG.

1. Right-click Cantata IMG EMS and select New SIP Profile

2. Enable desired features and enter values in fields where required. See the SIP Profile pane reference for details.

You can assign the profile to an external gateway (in the Remote IMG SIP Profile field in the External Gateway pane), or to a SIP Signaling object (see next procedure)

Configure SIP Signaling

1. Right-click the Physical IMG and select New Signaling.

2. Right-click Signaling and select New SIP.

The SIP Signaling pane appears.

3. Complete the fields as described in the SIP Signaling pane reference.

You can assign a SIP Profile in the SIP Profile field.

If you are enabling SIP-T, see Configuring SIP-T.

Configuring SIP Timers (Optional)

1. Right-click SIP Signaling and select New SIP Timers.

Page 76: Sip

SIP

76

The SIP Timers pane appears.

2. Change default values for timers as required.

Next Task

Configuring SIP Routing

Page 77: Sip

77

Configuring SIP-Based Load Balancing This feature allows you to distribute SIP traffic between IMGs configured as “SIP Servers” using Virtual IP Addresses and a SIP load balancer.

The Load Balancer and all SIP Server nodes to contain the same IP address. The Load Balancer is the only node which is allowed to respond to ARPs for this Virtual IP Address. This prevents external network elements from obtaining the MAC address of the SIP Servers, and forces all external inbound traffic to/through the Load Balancer and then to the SIP Servers.

The Load Balancer is configured with the MAC address of it’s SIP Servers, and when it receives a SIP message it determines which SIP Server to send it to and then exchanges the Destination MAC address in the frame with the desired SIP Server’s MAC address. The frame is then placed on the Ethernet and arrives at the desired SIP Server.

Configuration

Pre-requisite

You must configure your Load Balancer’s routing tables with the MAC addresses of its SIP Servers (IMGs), corresponding to the virtual IP address.

Steps

To implement SIP Based Load Balancing, perform the following:

1. Create a Network Interface for CPU with Gratuitous ARP and ARP Responses set to Disable.

2. Under the SIP Signaling object, create a new SIP Virtual Address object.

Page 78: Sip

SIP

78

3. In the SIP Virtual Address pane, select the Network Interface you just created.

4. To configure another virtual IP Address for this IMG, repeat steps 2 and 3.

5. Repeat steps 1-4 for each IMG that requires a virtual SIP Address.

CDRs

Even if the VIP is used to initiate a call, the primary IP address is used in the CDR containing the local IP.

Page 79: Sip

79

Configuring SIP-T

Enable SIP-T

To enable SIP-T:

1. Right-click the Physical IMG and select New Signaling.

2. Right-click Signaling and select New SIP.

The SIP Signaling pane appears.

3. In the Enable SIP-T field, select Yes.

4. In the SIP-T Behavior field, select Optional or Mandatory.

When you enable SIP-T you can make it Optional (default) or Required. If you make it Required and the far end does not support SIP-T the call will be released.

Modify outgoing ISUP variant name in ISUP MIME body (Optional)

The ISUP variant names used by the IMG in the ISUP MIME body are listed below.

Cantata ISUP MIME Nomenclature

ANSI-92

ANSI-95

ANSI-97

CCITT-88

ETSI-V1

ETSI-V2

ETSI-V3

ITU-93

ITU-97

Page 80: Sip

SIP

80

If you need to modify the name sent in ISUP MIME messages to match the far end, you can create a new signaling variant and then assign it to a stack in the SIP-T Entity pane.

1. Create a custom SS7 variant using the desired base variant and enter the exact name required by the far end.

a. Right click Cantata IMG EMS and select New Signaling Variants.

b. Right click Signaling Variants and select New Signaling Variant.

The Signaling Variant pane appears.

c. In the Variant Name field, enter the name for the variant expected by the far end.

d. In the Variant Type field select SIP-T.

e. In the Base Variant field, select the base variant to use for this custom variant.

Automatically Populated Field: Variant ID = next available number in sequence.

See the Signaling Variant pane reference for more details.

2. Assign the variant to an SS7 Stack.

a. Right-click the SIP signaling entry and select New SIP T Entity. The SIP T Entity pane appears.

b. Select the SIP Stack and the custom variant as required.

See the SIP T Entity pane reference.

Page 81: Sip

81

Configuring SIP Privacy

Related Topics

SIP Privacy

SIP Signaling

To enable Privacy for the entire GC EMS, set the Privacy Support field in the SIP Signaling pane for the method supported by the proxy.

All calls will be handled according to this setting, regardless of other SIP Privacy settings on an External Gateway or ISDN/ISUP Group.

External Gateway

Set the Privacy Info field in the External Gateway field according to what is supported by the SIP Proxy to which the IMG is connected.

ISDN Group/ISUP Group

To enable Privacy for an ISDN Group or an ISUP Group, set the Discard Privacy Info field in the ISDN Group pane or the ISUP Group pane to Yes.

Diagram

Page 82: Sip

SIP

82

Page 83: Sip

83

Configuring SIP Routing

Creating a SIP Channel Group

1. Right-click Cantata IMG EMS and select New Routing Configuration.

2. Right-click Routing Configuration and select New Channel Groups.

3. Right-click Channel Groups and select New Channel Group.

The Channel Group pane appears.

4. In the Signaling Type field select SIP.

5. Select other fields as required. See the Channel Group pane GUI Reference for details.

Associating a SIP Gateway with the SIP Channel Group

1. Right-click the channel entry and select New IP Network Element.

The IP Network Element pane appears.

2. In the IP Network Element field, select the SIP Gateway associated with this channel group.

Configuring SIP Proxy Handling

Page 84: Sip

SIP

84

1. Create a SIP Profile and configure Proxy Handling fields as required.

2. Assign the SIP Profile to the gateway in the External Gateway pane.

Configuring a SIP Redirect Server

1. Create a SIP Profile and configure Proxy Handling fields as required.

2. Assign the SIP Profile to the gateway in the External Gateway pane.

Page 85: Sip

85

Configuring an External SIP Gateway Use this pane to configure External SIP Gateways from which the IMG may receive calls. To configure a group of gateways, use the Gateway Mask field to validate a range of IP addresses.

1. Right-click External Elements and select New External Gateways.

2. Right-click External Gateways and select New External Gateway.

The External Gateway pane appears.

3. In the Gateway Signaling Protocol field select SIP.

4. In the Gateway IP Address, enter the IP address of the gateway.

5. In the Gateway Transport Type field, leave the default (UDP) or select TCP. NOTE: Must match Default Transport Type in the SIP Signaling configuration.

6. Change the Gateway Remote Port if required. Default = 5060.

7. If Gateway Registration is required, change the Gateway Registration field to Yes. Default = No.

8. To validate a range of IP addresses for multiple gateways, use the Gateway Mask field.

9. Use the Trusted and Privacy fields to configure SIP Privacy. See SIP Privacy for more information.

See the External Gateway pane reference for details.

Page 86: Sip
Page 87: Sip

87

Customizing SIP-to-SS7 ISUP Cause Codes

To change Cause Code Mapping from the RFC 3398 default,

1. Create a Cause Code Table.

2. Add an entry to the Cause Code Table.

a. In the Criteria Values field, select the original Cause Code for which you want to change the mapping.

b. In the Outgoing Cause Code field, select the value to which you want the original value mapped.

c. Add other entries to the Cause Code Table as desired.

3. Assign the Cause Code Table to a Channel Group.

Page 88: Sip
Page 89: Sip

89

SIP Call Flows

Basic SIP Call Flow

Basic SS7 ISUP to SIP Call_Flow

Basic SIP to SS7 ISUP Call Flow

Basic SIP to ISDN Call Flow

Basic ISDN to SIP Call Flow

SIP Bridging using SIP-T

Basic SIP Call Flow

Basic SS7 ISUP to SIP Call Flow

Page 90: Sip

SIP

90

Basic SIP to SS7 ISUP Call Flow

Basic ISDN to SIP Call Flow

Page 91: Sip

SIP Call Flows

91

Basic SIP to ISDN Call Flow

Page 92: Sip

SIP

92

SIP Bridging using SIP-T

Page 93: Sip

93

Channel Group Pane

Description

This pane defines incoming and outgoing attributes for a channel. It identifies the tables to be used for routing and translating calls. It also identifies the IP bearer profiles for H.323 channel groups.

NOTE: Many of the parameters that you specify for a channel group are defined as routing-related tables. Therefore, you must define the applicable tables at the routing level before you can assign them to a channel group.

Related Topics

Creating a Channel Group

Creating_an_H_323_Channel_Group

Creating a SIP Channel Group

Creating_an_SS7_Channel_Group

Creating an ISDN Channel Group

Accessing this Pane

Cantata IMG EMS -> Routing Configuration -> Channel Groups-> Channel Group

Maximum Objects: 672 per EMS

Technical Notes

When configuring a Channel Group, the following happens:

Incoming and attributes to be used while routing calls to/from the channel group are configured.

Pane

Page 94: Sip

SIP

94

Field Descriptions

Name

This field identifies the name of the Channel group.

ID

A unique ID for this Channel Group.

Channel Group Function

This field identifies the direction of calls on this Channel Group.

Incoming/Outgoing Trunks: Two way traffic (only valid option for IP Channels)

Incoming Trunks: One way traffic, Incoming only (not valid option for IP Channels)

Outgoing Trunks: One way traffic, Outgoing only (not valid option for IP Channels)

Signaling Type

The signaling to be performed on this Channel Group.

SS7

Page 95: Sip

Channel Group

95

H323

ISDN

SIP

Incoming Translation Table

Identifies the Incoming translation table that the IMG uses for digit translation and error detection for incoming calls received on this Channel Group.

Route Table

Identifies the route table to be used for routing calls received on this Channel Group.

Incoming Treatment

Indicates the way in which the IMG releases a failed incoming call.

Play Treatment

Release w/Cause

Cause Code Mapping Table

Specifies an override treatment for a cause code, enabling you to customize the cause codes with alternate treatments.

None

Incoming IP Profile

Indicates the IP characteristics for incoming Voice over IP calls on this Channel Group, including voice encoding compression, payload size, echo suppression, and other parameters. This applies to H.323 and SIP channel groups only.

Outgoing Translation Table

Indicates the outgoing translation table that the IMG uses for digit translation for outgoing calls on this channel Group.

Hunting Options

This field specifies the hunting algorithm used for selecting a channel to route an outgoing call.

Alternate Even

Alternate Odd

LRU (Lease Recently Used)

Most Idle

Round Robin Clockwise

Page 96: Sip

SIP

96

Round Robin Counter Clockwise

Sequential Bottom Up

Sequential Top Down

Outgoing Treatment

Specifies the way in which the IMG releases a failed outgoing call.

Play Treatment

Release w/Cause

Ingress Side will Play Call Progress Tones

This field specifies if the incoming side will play call progress tones or not.

True

False

Outgoing IP Profile

Identifies the IP characteristics for outgoing Voice Over IP calls on this Channel Group, including voice encoding compression, payload size, echo suppression, and other parameters. This applies to H.323 and SIP channel groups only.

Treatment Table

Identifies the treatment table that the IMG uses if a call fails and the outgoing treatment is set to Release w/cause.

TreatmentTable ID: 1: Primary

TreatmentTable ID: 2: Secondary

Reattempt Cause Code

The IMG will automatically attempt to re-route calls in response to the following cause codes: 42,41,34. Use this field to select up to 4 additional Cause Codes for which the IMG will re-attempt a new call, per trunk group.

Receive Gain/Transmit Gain

Configures the Input and Output Gain on a per Channel Group basis for TDM and RTP channels. Transformations are allowed from -21 dB to +18 dB in 3 dB increments. When 0 dB is selected the transformation option is disabled

Clipping - In the case of TDM to TDM calls, the combined Receive and Transmit Gain will be clipped at +18 dB. For example, if channel group A had the Receive gain set to +12 dB and channel group B had its Transmit gain set to +10 dB, and the call was flowing from A to B, one would expect +22 dB of gain. However, the IMG will

Page 97: Sip

Channel Group

97

implement clipping, so the gain on this call would be +18 dB. It will work the same in the reverse direction as well.

Gain Control is not supported for pre-call announcements, treatments, or ringback.

________________________________________________________________________________________________

The following fields relate to Overlap Signaling. See Overlap Signaling for more information.

Overlap Enable

Enable

Enable overlap signaling on inbound Channel Groups when the outbound channel group does not support Overlap Signaling (SIP, H.323). The IMG will collect address digits until a Termination Condition is met and then continue call processing. See below for protocol-specific information. Overlap is only applied to the inbound channel, even on an Incoming/Outgoing Trunk.

Disable (default)

By default, the IMG passes digits to the outbound side as they are received.

Termination Digits

Digit to indicate end of overlap sending.

Default for SS7 Channel Group = #

Not used for ISDN

Minimum # of Digits

The minimum number of digits that the IMG will wait for (collect) in the incoming side before attempting an outseize on the outgoing side.

1-24 (default = 24)

NOTE: This field is different from the Max # CdPN digits (IAM) field in the ISUP Group pane, which applies to the outgoing ss7 calls.

Inter SAM Timeout

Time to wait for another SAM digit before continuing with call processing.

Default = 1500

Not used for ISDN

Total Overlap Timeout

Page 98: Sip

SIP

98

Amount of time to wait for either Minimum # of Digits or Inter SAM timeout to occur before continuing with call processing.

Default = 18000

________________________________________________________________________________________________

LNP Based Routing

Enable

Disable (default)

See Local Number Portability (LNP).

Informational Fields

Page 99: Sip

99

ENUM Server

Description

Use this pane to configure an ENUM Server. You assign an ENUM Server to a Channel Group in the IP Network Element pane.

Pre-requisite Configuration

ENUM Server Set

Related Topics

SIP ENUM

Accessing this Pane

Cantata IMG EMS-> External Network Elements-> ENUM Server Set-> ENUM Server

Maximum Objects: 3 per ENUM Server Set

Pane

Field Descriptions

ENUM Server Id

This field is automatically populated with the next number in sequence.

ENUM Server Name

A unique name you enter to identify the server.

ENUM Server IP Address

The IP Address of this ENUM Server.

Page 100: Sip
Page 101: Sip

101

External Gateway Pane

Description

Use this pane to specify external SIP or H.323 gateways from which the IMG may receive an incoming call. To configure a group of gateways, use the Gateway Mask field to validate a range of IP addresses.

Related Topics

Adding an External Gateway

Accessing this Pane

Cantata IMG EMS-> External Network Elements-> External Gateways-> External Gateway

Maximum External Gateway Objects: 1024 per EMS

Technical Notes

When configuring an External Gateway, the following happens:

The object information is stored in DataManager, which uses this info latter in the creation of PPL tables used to configure the GCL of the IMG.

Pane

Field Descriptions

Name

A unique name identifying the external gateway.

Page 102: Sip

SIP

102

Gateway Signaling Protocol

H.323 (default)

SIP

Gateway Address Type

Gateway IP Address (default)

Host Name (SIP only)

Gateway IP Address

If the Gateway Address Type is Gateway IP Address, this field specifies the IP Address of the External Gateway.

Gateway Mask

Use this field to configure the IMG to accept calls from multiple gateways with one entry.

The Gateway Mask in conjunction with the Gateway IP Address field determines the range of IP Addresses from which the IMG will accept calls.

If the Incoming IP Address ANDed with the Gateway Mask equals the Gateway IP Address ANDed with the Gateway Mask then the call will be processed.

Note that for outbound calls, only the specific IP address in the Gateway IP Address field is used.

Examples

1. Only the IP address specified in the Gateway IP Address field is accepted. This is the default.

Gateway IP Address: 10.11.12.1 (default)

Gateway Mask: 255.255.255.255

2. IP address ranging from 10.11.12.1 to 10.11.12.128 will be processed

Gateway IP Address: 10.11.12.1

Gateway Mask: 255.255.255.128

3. IP address ranging from 10.11.12.1 to 10.11.12.31 will be processed

Gateway IP Address: 10.11.12.1

Gateway Mask: 255.255.255.224

4. To accept calls from any gateway:

Page 103: Sip

External Gateway

103

Gateway IP Address: ANY

Gateway Mask: 0.0.0.0

Gateway Host Name (SIP Only)

If the Gateway Address Type is Host Name, this field specifies the Host Name of the External Gateway. To look up a gateway based on Host Name you must have a DNS Server configured.

Gateway Transport Type

This can vary for different gateways and does not need to match the default IMG Transport Type.

TCP (default)

UDP (SIP Only)

Gateway Remote Port

The port used for communication with the remote gateway.

_________________________________________________________________________________________________

Gateway Registration Required (SIP Only)

This field indicates if the IMG must register with the gateway. Applies to SIP Gateways only.

Registration Expiration Interval (sec) (SIP Only)

Use this field to control the registration refresh interval. Applies to SIP Gateways only.

10-7200

Default = 3600

_________________________________________________________________________________________________

SIP Profile

Select a SIP Profile that defines various SIP features for this gateway.

OPTIONS Keep Alive

Use his field to enable the SIP Busy Out feature on a gateway. You configure SIP Busy Out parameters with the SIP Options KeepAlive pane.

Enable

Disable (default)

Page 104: Sip

SIP

104

_______________________________________________________________________________________________

The following fields relate to SIP Privacy. See Configuring SIP Privacy.

Trusted

This field applies to SIP Signaling only.

Yes (default)

No

Privacy

This field applies to SIP Signaling only.

On

Off (default)

_______________________________________________________________________________________________

Display Table

This table shows all the currently configured External Gateways.

Page 105: Sip

105

SIP DTMF Support

Description

Use this pane to enable and configure SIP DTMF support to send a DTMF digit to another gateway.

There are two options available:

SIP INFO Method

SIP Subscribe/Notify

Related Topics

SIP INFO Method for DTMF

Accessing this Pane

Cantata IMG EMS -> Profiles -> SIP SGP -> SIP DTMF Support

Maximum Objects: 1 per SGP

Pane

Field Descriptions

Method

Disable (default)

Info

Subscribe

DTMF String

Enter the desired string.

Options

Page 106: Sip

SIP

106

#

##

###

####

Default = ###

DTMF Duration Time (ms)

This is the allowed amount of time for the entire DTMF string to be received. If the timer expires, it resets to zero and starts over.

Default = 500

Default Subscriber Duration (s) (Subscribe/Notify Method Only)

The amount of time that a subscriber session will be kept up. This value is also the maximum allowed duration.

Minimum Subscriber Duration (s) (Subscribe/Notify Method Only)

The minimum amount of time that a subscriber session must be established for.

Page 107: Sip

107

SIP Headers

Description

Accessing this Pane

Cantata IMG EMS -> Profiles -> SIP SGP -> SIP Headers

Preceding Pane

SIP Profile

Maximum Objects: 1 per SGP

Pane

Field Descriptions

Diversion Header Support

If you enable this feature, SS7 Redirection information will be sent in the SIP Diversion Header in the outgoing SIP INVITE. See SIP Diversion Header for more information.

Disable (default)

Diversion

CC-Diversion

Time Stamp Support

Enable:

Page 108: Sip

SIP

108

The IMG will insert the Timestamp Header in the format of: Timestamp: MMDDYYYYHHMMSS

This value is derived from the system time of the IMG. (After bootup the IMG uses Jan 1,1970 as its internal date or receives a proper value for the time through SNTP)

Disable

The IMG will not insert the Timestamp. However, actions based on the Timestamp are in accordance with sec 8.2.6.1 of RFC 3261

P Charge Info

P Asserted Info

Remote Party ID

Page 109: Sip

109

SIP Network Element

Description

Use this pane to enable a physical IMG to send out a SIP Registration for Authentication.

Pre-requisite

You must have configured an External Gateway where you have Outbound Registration enabled .

Related Topics

Accessing this Pane

Cantata IMG EMS -> Logical IMG -> Physical IMG -> Signaling -> SIP Signaling -> SIP Network Element

Maximum Objects: 15 per SIP Gateway

Pane

Field Descriptions

SIP Network Element

The external SIP Gateway.

SIP UserName (AOR) (Address of Record)

A SIP Identifier, or Address of Record (AOR) allows SIP users to communicate with each other without knowing network addresses. AORs are in the same format as an E-mail address: username@domainName.

Page 110: Sip

SIP

110

SIP Authentication UserName

The UserName the IMG will use for authentication with this gateway.

SIP Authentication Password

The Password the IMG will use for authentication with this gateway.

Informational Fields

SIP Network Element Connection Status

The status of this SIP Gateway.

Page 111: Sip

111

SIP Options KeepAlive

Description

Use this pane to configure parameters for the SIP Busy Out feature.

The IMG can monitor the status of external SIP gateways by sending periodic SIP OPTIONS messages. If the gateway does not respond in a configured amount of time the IMG will mark the gateway as down and attempt to re-route the call to a different gateway.

You enable the SIP Busy Out feature on a specific gateway in the External Gateway pane.

Preceding Configuration

SIP Profile

Related Topics

SIP Busy Out

External Gateway

Accessing this Pane

Cantata IMG EMS -> Profiles -> SIP SGP -> Options KeepAlive

Maximum Objects: 1 per SGP

Pane

Field Descriptions

Number of Responses

Page 112: Sip

SIP

112

The number of positive responses received before marking a gateway as "up" (in a reachable state).

1-10

default = 3

Up Timer

Timer to define the interval between OPTIONS messages when the gateway is responsive. If the gateway does not respond within the timer, the gateway will be marked as down and calls will not be routed to the gateway.

30-600 seconds

default = 120

Down Timer

Timer to define the interval between OPTIONS messages when the gateway is down (non responsive). If the gateway responds within the timer, and the number of times indicated in the , it will be marked as up and routing calls to the gateway will resume.

1-20 seconds

default = 30

Page 113: Sip

113

SIP Profile

Description

Use this pane to configure various SIP features in the IMG.

CHANGES TO THIS PANE:

The following features are no longer configured with this pane but with the pane noted.

SIP Proxy - SIP Proxy pane

SIP DTMF - SIP DTMF Support

SIP Headers - SIP Headers

WARNING: Making changes to a SIP Profile that is assigned to active calls may result in call failure or other adverse effects. Stop all traffic to gateways or channel groups that use a SIP Profile before you make changes.

Related Topics

SIP Features

Accessing this Pane

Cantata IMG EMS -> Profiles -> SIP Profile

Maximum Objects: 16 per EMS

Pane

Field Descriptions

SIP Profile ID

1-15

Page 114: Sip

SIP

114

SIP Profile Name

A unique name to identify the profile.

_____________________________________________________________________________________

These fields relate to the SIP PRACK feature.

PRACK Support

Disable (default)

Supported

Required

PRACK Timer (sec)

This timer is used to request an “extension” of the transaction at proxies in case if the INVITE transaction will take some time to generate a final response (RFC 3262 page 3). When this PRACK Refresh timer expires, the IMG will send out 1XX reliable response.

60 (s)

150 (s) (default)

_____________________________________________________________________________________

CODEC Priority

This feature allows you to configure whether the IMG or the remote gateway takes priority when selecting a codec.

Local

Remote

Example:

If the IMG has a CODEC list of:

g711u

g729

g711a

and a remote gateway offers:

g729

g711u

If the Codec Negotiation Priority is set to Local, the IMG will answer with g711u.

If the Codec Negotiation Priority is set to Remote, the IMG will answer with g729.

Page 115: Sip

SIP Profile

115

From Header Tags

This is a pop-up that allows you to select non-standard tags to include in the From header. Multiple selections are allowed.

ISUP-OLI Support

When this option is selected, the IMG will include the INFO digits received in the Originating Line Info parameter (OLI) in the IAM message from the SS7 ANSI side into the ISUP_OLI tag in the From Header on the SIP side, and vice versa.

NOTE: To de-select an option, use the Ctrl and Shift keys.

R-URI Header Tags

If selected, the tag will be added into the R-URI of the outgoing INVITE in the “sip_uri_enc” method.

RN

This tag is used to convey the location routing number. See LNP Routing for more information.

NPDI

This tag is used to indicate whether an LNP query has been performed. See LNP Routing for more information.

CIC

The CIC parameter is a three- or four- digit code used in routing tables to identify the network that serves the remote user when a call is routed over many different networks. See SIP Carrier Identification Code for more information.

3XX Redirect Support

When this feature is enabled, the IMG will send a new INVITE to the contact returned in a 3XX response from a redirect server.

When this feature is disabled, the IMG will release the call when it receives a 3XX response from a redirect server and map 3XX code to 4XX code. See SIP Redirection for more information.

Enable (default)

Disable

SIP Loop Detection

If a SIP request is received and falls in the loop detection path, you may want to ignore the loop. For example if the request has a different To header and also includes a diversion header.

Enable

Page 116: Sip

SIP

116

Disable

Disable with no Header Check

SIP Re-Origination Attempts

See SIP Re-origination for more information.

Retransmit All

1

2

3

4

5

_______________________________________________________________________________________________________________

These fields relate to the SIP Trunk Group Selection feature.

Apply the OTG to the outbound SIP Invite

On an outgoing invite, the OTG that was received from the incoming call will take precedence over the internal IMG incoming Channel group name if it was a SIP call (for any other inbound protocol, the OTG would be the incoming Trunk Group Name). This OTG is then appended in the “From” header of the outbound invite.

Enable

Disable (default)

Use the incoming OTG for incoming Channel Group Selection

When the OTG field is included in the “From” header the IMG will use this trunk group as the incoming trunk group to determine which incoming DPE table and route table to use. The OTG will also be able to be added to the “From” header in an outbound SIP invite, the OTG will have the A side trunk group name.

The IMG extracts the OTG from the SIP "From" header and passes in the Initial Setup. If an OTG is found, the IMG will use that channel group instead of the one that came from the lookup table in the SIP process.

Enable

Disable (default)

Use the DTG for outgoing channel group selection

When the DTG is received in the request-URI the IMG will skip the mid-call router and use the DTG that was received as the outbound channel group.

When the IMG is about to perform routing for the outbound side, it will look for the DTG from the same location as the Calling Party Number. If the DTG is valid, the call

Page 117: Sip

SIP Profile

117

will then use the channel group that corresponds to that DTG instead of performing a routing lookup

Enable

Disable (default)

__________________________________________________________________________________________

These fields apply to the Pass through ‘+’ sign in the user part of URI feature.

Append (+) for Headers

Use this field to prefix ‘+’ to the user if the incoming INVITE does not have ‘+’. Select one or more headers to apply the "+" to.

Remove (+) for Headers

Use this field to remove a "+" from an incoming INVITE if you do not want it included in the outgoing INVITE. This can also be used in the case that the incoming side is not SIP.

Page 118: Sip
Page 119: Sip

119

SIP Profile Timers

Description

Use this pane to configure SIP timers that apply to a specific SIP SGP.

Related Topics

SIP Profiles

Accessing this Pane

Cantata IMG EMS -> SIP Profile -> SIP Profile Timers

Preceding Pane

SIP Profile

Maximum Objects: 1 per SGP

Pane

Page 120: Sip
Page 121: Sip

121

SIP Proxy

Description

Use this pane to configure various SIP features in the IMG.

WARNING: Making changes to a SIP Profile that is assigned to active calls may result in call failure or other adverse effects. Stop all traffic to gateways or channel groups that use a SIP Profile before you make changes.

Related Topics

SIP Features

Preceding Pane

SIP Profile

Accessing this Pane

Cantata IMG EMS -> Profiles -> SIP Profile -> SIP Proxy

Maximum Objects: 1 per SGP

Pane

_____________________________________________________________________________________

These fields relate to the SIP Proxy Handling feature.

Outbound Proxy

Enable

Disable (default)

Page 122: Sip

SIP

122

Send Re-Invite to Proxy

Enable

Disable (default)

Send Outbound Register

Enable

Disable (default)

Proxy Transport

UDP (default)

TCP

Proxy Address Type

Host Name

IP Address

Proxy Name

If Address Type = Host Name , enter Proxy Name

Proxy IP Address

Proxy Port

Default = 5060

_____________________________________________________________________________________

Page 123: Sip

123

SIP Session Timer

Description

Use this pane to configure SIP Session Timer values.

Related Topics

SIP Session Timer

SIP Session Timer Call Flows

SIP UPDATE

Preceding Pane

SIP Profile

Accessing this Pane

Cantata IMG EMS -> Profiles -> SIP Profile -> SIP Session Timer

Maximum Objects: 1 per SGP

Pane

Field Descriptions

Session Timer

Enable (default)

Disable

Page 124: Sip

SIP

124

Enforce Feature

Enable

If enabled, the IMG will perform the session refresh request even if the remote gateway does not support session timer. The session timer cannot be turned off in mid dialog.

Disable (default)

Refresh Method

Re-Invite

The IMG will use re-INVITE even if the remote gateway supports UPDATE.

Update

The IMG will use UPDATE only if the remote gateway supports it, otherwise re-INVITE will be used instead.

Refresher

Only applicable for initial refresh response when IMG acts as UAS and the request does not specify refresher.

Local

The IMG will perform a refresh.

Remote

The IMG will wait for refresh request.

Minimum Session Expires

Establishes the lower bound session refresh interval. It can be raised but cannot be lowered. It is mandatory on 422 response and optional on INVITE and UPDATE request. It must not be less than 90 seconds.

Default = 900

Session Expire

Establishes the upper bound session refresh interval. It can be lowered but cannot be below the value specified in Min-SE. It is optional on INVITE or UPDATE request and 2xx response to INVITE or UPDATE. The recommended value is 30 minutes.

Default = 1800

Page 125: Sip

125

SIP Signaling

Description

Use this pane to configure SIP signaling.

Related Topics

An Introduction to SIP

Configuring SIP Signaling

Accessing this Pane

Cantata IMG EMS-> Logical IMG-> Physical IMG -> Signaling -> SIP

Maximum Objects: 1 per Physical IMG

Pane

Field Descriptions

SIP Signaling IP Address

The IP Address of the Network Interface used for SIP Signaling.

Local SIP Port

The port used for SIP signaling.

Page 126: Sip

SIP

126

SIP Compact Header

Enable

Disable

Default Transport Type

UDP (default)

TCP

Default SIP UserName (AOR)

Default UserName for Authentication

Default SIP Authentication UserName

Default SIP Authentication Password

Enable SIP-T

Yes

No

SIP-T Behavior

Optional

Required

Privacy Support

To enable Privacy for the entire GC EMS, set the Privacy Support field for the method supported by the proxy. All calls will be handled according to this setting, regardless of other SIP Privacy settings on an External Gateway or ISDN/ISUP Group. See Configuring SIP Privacy.

Off (default)

P-Asserted only

Remote-Party only

Both

Remote IMGs SIP Profile

Page 127: Sip

SIP Signaling

127

Select a SIP Profile to define how another IMG should treat a call going to or coming from this logical IMG.

Page 128: Sip
Page 129: Sip

129

SIP T Entity

Description

Use this pane to customize the name of an ISUP variant in an ISUP MIME body sent by the IMG when SIP-T is enabled.

NOTE: You must have SIP T Enabled in the SIP Signaling pane to access the SIP T Entity pane.

Related Topics

Configuring SIP-T

Accessing this Pane

Cantata IMG EMS -> Logical IMG -> Physical IMG -> Signaling -> SIP Signaling -> SIP T Entity

Maximum Objects: 4 per SIP Signaling object

Pane

Field Descriptions

SS7 Stack

Select the stack to which you are assigning the variant.

SIP Variant

Select the custom variant name to send in ISUP MIME body. You must have previously created this custom variant using the Variant Table pane.

Page 130: Sip
Page 131: Sip

131

SIP Timers

Description

Use this pane to configure SIP Timers.

Related Topics

Configuring SIP Timers

Accessing this Pane

Cantata IMG EMS -> Logical IMG -> Physical IMG -> Signaling -> SIP Signaling -> SIP Timers

Maximum Objects: 1 per SIP Signaling object

Pane

Field Descriptions

SIP T1 (10 ms)

The value for SIP Timer T1, in 10 ms increments.

SIP T2 (10 ms)

The value for SIP Timer T2, in 10 ms increments.

SIP T4 (10 ms)

The value for SIP Timer T4, in 10 ms increments.

SIP Timer D (10 ms)

The value for SIP Timer D, in 10 ms increments.

Page 132: Sip
Page 133: Sip

133

SIP Virtual Address

Description

Use this pane to configure a SIP Virtual IP Address for SIP Based Load Balancing.

Related Topics

SIP-Based Load Balancing

Configuring SIP Based Load Balancing

SIP Signaling

Network Interface

Accessing this Pane

Cantata IMG EMS -> Logical IMG -> Physical IMG -> Signaling -> SIP Signaling -> SIP Virtual Address

Maximum Objects: 2 per SIP Signaling object

Pane

Field Descriptions

SIP Virtual Address ID

1 or 2

SIP Virtual IP Address

This drop-down will be populated with any CPU Network Interface entries that have Gratuitous ARP and ARP Responses set to Disable. Select the desired entry.

When the Gratuitous ARP and ARP Responses is set to Disable, this Virtual IP Address will not be allowed to issue a Gratuitous ARP. In addition, whenever an external node attempts to send an ARP to this Virtual IP Address, the ARP Reply will be suppressed.

Any node that knows the MAC address associated with this Virtual IP Address (through static configuration as used in Load Balancers) will be able to send packets to it. The Virtual IP Address will be able to send packets to any desired node since

Page 134: Sip

SIP

134

ARP Requests from the Virtual IP Address for an unknown IP’s MAC address will be allowed.

For all outbound SIP requests, the real SIP Signaling IP Address is used to send SIP messages, even if the outbound transaction is within a dialog which had previously used the Virtual IP Address.

IP Virtual Port

Default = 5060.