SIP Trunk Qualification SBC1000/SBC2000 Telenor SIP Trunk Service

Copyright © 2012 Sonus Networks, Inc.

Line 1 2

Author Matt Hurst Matt Hurst

Date 27/08/2013 16/09/2013

Revision v.1.0 v 1.1

Changes Made Initial Draft Updates & Results

Table of Contents 1. 2. 3. 4. 5. 6. 7. 8.

INTRODUCTION ................................................................................................................. 4 TESTING ARCHITECTURE....................................................................................................... 5 ALLOW: PRACK HEADER ADDITION ....................................................................................... 6 183 SESSION PROGRESS WITHOUT SDP .................................................................................. 8 SINGLE CODEC SUPPORT FOR INBOUND TRAFFIC ONLY ............................................................... 11 P-PREFERRED-IDENTITY HEADER – IPT PARTNER TESTING .......................................................... 12 DISABLE UPDATE SUPPORT ................................................................................................. 15 TESTING RESULTS ............................................................................................................. 16

1. Introduction This document has been written as part of the Interop testing and certification of the Sonus SBC1000 and SBC2000 products against the Telenor SIP trunk service. Full testing and interoperability certification has been completed with the Sonus SBC devices, and this document details the relevant configuration elements within the Sonus SBC platforms that enable smooth and seamless integration to the Telenor SIP trunk service. This document also covers the additional Telenor IPT Partner integration as well, enabling the support for multiple customers hosted on a Sonus SBC, sharing a single Telenor SIP service. The IPT Partner tests ensure that the SBC performs the relevant integrity and identification of the mixed customer traffic, ensuring accurate identification of traffic for billing purposes within the Telenor network.

2. Testing Architecture The following architecture was used for the certification and interop testing of the Sonus SBC against the Telenor SIP Trunk service. The SBC used for testing was a Sonus SBC1000 S/W Version: R3.0.1 v254

All tests were performed from the Lync 2013 environment – the Linksys SIP device was used for test cases where a local call transfer was required from Lync to another user outside of Lync, but still on the CPE side of the SBC.

3. Allow: PRACK Header Addition The SBC fully supports PRACK messages during the SIP signalling sequence, and indicates this support through the use of the 100rel SIP Header value. This 100rel Header value is configured by way of the SIP Profile, where the 100rel can be set to either:   

Not Present – No 100rel Header Value sent Supported – 100rel sent in the Supported Header Required – 100rel sent in the Required Header

However, for the purposes of interfacing to the Telenor SIP service, it is also required to include the PRACK Header value under the SIP Allow: header element. This is for INVITE messages only, to indicate to the Telenor systems that the SBC is allowing PRACK to be used. It is therefore required to add-in the Allow: PRACK header to outgoing INVITE messages towards the Telenor service. Firstly, create a SIP Message Rule Table that applies to INVITE messages only:

(Note that it is important to apply this rule only to INVITE messages, as otherwise the header value will be added to all outgoing SIP message sequences, which is undesirable as it can cause undesired effects with other call sequences) Within the table, create a rule that adds in the Header value:

Now apply this message manipulation to the Telenor SIP Signalling Group, in the outbound direction.

This will ensure that all outgoing INVITE messages will also include the Allow: PRACK header within them, enabling the Telenor systems to act accordingly for PRACK support.

You will then see the inclusion of the Allow: PRACK header in outbound Invite messages:

4. 183 Session Progress without SDP The SBC resides between the Telenor SIP trunk service and Microsoft Lync 2013 environments, handling the message translation and interpretation between the systems to provide the optimum interoperability. One element of this interoperability is to do with the 183 Session Progress messages that are received from the Lync server during inbound call setup. This affects in-band ring-back. The Lync server sends a 183 message with full SDP:

By default, the SBC will support the 183 messages and any Early Media during the call setup, and will pass onto the Telenor SIP trunk the full 183 with SDP message. Due to this message sequence and the provision of SDP within the 183 message, the Early Media is invoked, and ring-back for the call setup is passed in-band from the SBC (generated internally) once this 183 message is passed towards Telenor. For the Telenor SIP trunk service, the desired behaviour is that the Telenor systems always generate any ringback, to avoid any unusual or out of country tones being received by the calling party. To enable this on the SBC we implement 2 configuration changes to stop Early Media towards the Telenor SIP trunk, and also to send the 183 Progress message without the SDP element.

Firstly, disable the Early Media on the Signalling Group towards Telenor:

Next, create a Message Translation to modify 183 Progress messages, deleting any SDP elements:

Then apply this Translation to the Call routes from Telenor SIP trunk towards the Lync server:

This will now ensure that any 183 Session Progress messages we receive from Lync during call setup, will have the Early Media and SDP removed from the message when the signalling is sent towards Telenor:

This will only affect calls through the SBC from Telenor, and going towards Lync. Now any in-band ring-back tones for calls from Telenor will be generated by the Telenor systems.

5. Single Codec support for Inbound Traffic only It is required that the SBC ‘must’ support at least one codec – that being G711 A law, however it is extremely desirable to offer more than one codec, the second main preference being G711 mu law. This is true for all outbound calls from the SBC, and is easily achievable using a Media List that contains multiple Codecs – all will be offered within the SDP as part of the SIP signalling sequences. However, for inbound calls, it is desirable from the Telenor side to restrict the codec offer back from the SBC to ONE codec only. This is to avoid some situations with one-way audio to certain SIP phones and systems that mis-negotiate between G711 A and mu law. (In these specific cases it has been seen that some devices negotiate with the SBC to one codec – e.g. G711 A law, and receive using this codec, but transmit usingG711 mu law – by offering just a single codec back to the devices from the SBC mitigates this situation.) In order to achieve this Codec offer behaviour on the SBC, restricting inbound calls to just a single codec, but allowing multiple codecs to Telenor for outbound calls, it is required to use the granular codec selection within the call routes to effect a single codec offer for the inbound calls. Firstly, ensure that your Signalling Groups on both sides of the SBC are using a Media List that includes at least the one codec that you want to restrict to. (In the test setup for example, both the Lync side and Telenor side were using a Media List that included both G711 A and mu law codecs.) Now create a Media List with just the single codec in that you require:

This can then be applied to all inbound call route entries from Telenor – ensure to also set the Media Transcoding to Disabled - this is important to ensure that not only the onward call route towards Lync is restricted to the single codec, but also the offer back towards Telenor for the inbound call leg.

This will now ensure that the calls inbound from Telenor will only offer the single codec specified on both legs of the call.

6. P-Preferred-Identity Header – IPT Partner Testing As part of the IPT Partner testing support, the P-Preferred-Identity header shall be used to insert a unique Customer ID in order to identify for billing purposes the source of the traffic behind the SBC. From the Telenor IPT Partner testing document:

Technical requirements 

Partner shall establish a separate number series using the solution. This can be used both for own use and for test purposes (see below). The number series can be obtained from Telenor in the same manner as if it belonged to a customer.



There is established a dedicated phone number for testing the call quality (MOS). Partner will put a redirect to this number from one of their own number in the solution, so that MOS can be measured and possible sources of error can be resolved. The directed number shall be stated to Telenor.



It is essential that Telenor can distinguish the different customers from each other. In IPT Partner is done by supplying one separate, unique customer ID. This ID is defined by Telenor after received an order, and will be used by Partner when signaling call set-up. This is done in SIP proxy / SBC between Partner server park and Nordic Connect CE router. Examples of the network element where this can be performed, is a Sonus SBC, a Session Director from Acme Packet or equivalent.

Note also that the media always have to traverse the main access / SIP trunk.

Syntax for Customer ID The unique customer ID number is used in the P-Preferred-Identity header in the INVITE messages, and inserted into the signaling path in the Partner SBC / SIP Proxy. The Customer ID is composed as follows: 199 2-digit serial number, and is supplied from Telenor when Partner is ordering a customer access. An example of a correct header will look like: P-Preferred Identity: FROM field should always contain display numbers in international format.

To implement this, the SBC will be configured on one side with 2 Customers (Customer A and Customer B) and on the other side, a single, shared SIP trunk service to Telenor. Each customer shall be provisioned their own Signalling Group within the SBC – this will identify and segregate the Customers traffic inbound to the SBC. Onto each of these Signalling groups, a SIP Header Manipulation table will be applied, to insert the Customer ID into the P-Preferred-Identity header field within the SIP messaging. This Header field will then be used for ALL of the customers traffic inbound to the SBC, thus reliably tagging ALL traffic from the customer before onward routing.

Firstly, create a SIP Message Rule Table that applies to all messages:

Within the table, create a new Header rule that ADDS in the P-Preferred-Identity header field, and populate it with the relevant Customer ID required.

Next, apply this Message Manipulation to the Customers Signalling Group for all inbound traffic:

Now you will see that all inbound Invite messages etc. from the Customers devices will have the P-PreferredIdentity header added before being processed or onward routed by the SBC to other devices, including the Telenor SIP trunk. This allows for accurate billing and call tracking at the Telenor side.

7. Disable Update Support In certain scenarios it is required to disable the UPDATE support from the SBC towards the Telenor SIP trunk service – this is primarily for the Early Update call scenario. In order to achieve this, disable the Update Options tag within the SIP Profile being used on the Telenor Signalling Group: Note that there are 3 options – Supported, Required and Not Present – this affects which header the Update tag appears under, or not at all.

In addition, it may also be required to remove the UPDATE parameter from within the Allow: header element of the SIP messages. To do this, create a SIP message manipulation that removes this parameter from within the string of parameters listed under the Allow: header.

8. Testing Results The following table shows the Tests performed and the results of each test sequence. Full trace logs are available for both the Telenor side, and the Sonus SBC side, providing full detail and SIP call analysis of each test. File names for the log files are per the ‘Step Name’ column below.

Subject

Test Name

Step Name

Design Description

CPE Test Library\Basic

General information

general

Note all relevant versions.

Registration

basic_registration

Compare registration values with Telenors spec. Only relevant if the CPE sends REGISTER against IPT.

Calls

basic_calls_pstnto cpe_hanguppstn

Call from P6(PSTN) to C1. Answer the call. Hang up the call from P6(PSTN)

basic_calls_pstnto cpe_hangupcpe

Call from P6(PSTN) to C1. Answer the call. Hang up from C1.

basic_calls_cpeto pstn_hangupcpe

Call from C1 to P6(PSTN). Answer the call. Hang up the call from C1

basic_calls_cpeto pstn_hanguppstn

Call from C1 to P6(PSTN). Answer the call. Hang up from P6(PSTN).

Verify call setup, displayed CLID and connection. And if the call disconnect correctly. Verify call setup, displayed CLID and connection. And if the call disconnect correctly.

basic_cancel_cpe

Call from P6(PSTN) to C1. Wait until ringing on C1 and then hang up from P6(PSTN). Call from C1 to P6(PSTN). Wait until ringing on P6(PSTN) and then hang up from C1.

Verify that C1 stops ringing and both parties are disconnected correctly Verify that P6(PSTN) stops ringing and both parties are disconnected correctly

basic_busy_cpe

Force C1 to become busy. Call from P6(PSTN) to C1

Verify that P6(PSTN) receives busy signal

CPE Test Library\Basic

CPE Test Library\Basic

CPE Test Library\Basic

CPE Test Library\Basic

Cancel

Busy

basic_cancel_pstn

Expected Versjon Softswitch, OSP, ACME:, CPE type:, CPE versjon: Verify correct CPE registration(digest, numberformat, regtimer, retryafter and more). Note regtimer, UserAgent, From, To and Contact and header. OBS! Not used testing SIP trunk systems.

Verify call setup, displayed CLID and connection. And if the call disconnect correctly. Verify call setup, displayed CLID and connection. And if the call disconnect correctly.

Result without PRACK in allow header

Result retest with UPDATE supported

Result retest with UPDATE removed in allow header(outgoing)

IPT version : 3.1.3.132. Sonus : Lync2013

NA

NA

OK

OK, tested with UPDATE supported. Tracefile marked with 3.

OK OK, no RPACK in allow hesader. OK, no prack in Allow header?

OK

OK NA

OK, tested with UPDATE supported. Tracefile marked with 3.

NA OK, tested with UPDATE disabled. Tracefile marked with 5. Prack is not used here beacuse IPT is disabling PRACK when UPDATE is not supported.

CPE Test Library\Basic

CLIR

basic_busy_pstn

Force P6(PSTN) to become busy. Call from C1 to P6(PSTN)

basic_clir_pstn

Activate CLIR on P6(PSTN). Call from P6(PSTN) to C1.

basic_earlymedia_ 183sessionprogre ss

Activate CLIR on C1. Call from C1 to P6(PSTN). Call from C1 to 82090100. This is a solution that sends you an announcement before connected, Early media. In SIP signaling, you will recieve 180 Ringing from IPT. Call from C1 to 82095100. This is a solution that sends you an announcement before connected, Early media. In SIP signaling, you will recieve 183 Session Progress from IPT.

supplementary_cal lhold_pstntocpe

Set up a call from P6(PSTN) to C1. Activate callHold(CH) on C1 and then resume the call. In the same call, activate CH on P6(PSTN) and then resume the Call.

basic_clir_cpe

CPE Test Library\Basic

CPE Test Library\Supple mentary

Earlymedia

Call Hold

basic_earlymedia_ 180ringing

supplementary_cal lhold_cpetosip_se ndonly

Set up a call from C1 to P6(PSTN). Activate callhold(CH) on C1 and then resume the call. In the same call activate CH on P6(PSTN) and then resume the call. Set up a call from C1 to T1(SIP). Activate CH on T1(SIP). resume Call. Activate CH on C1 and then resume call. The T1(SIP) should use the callhold method, mediaattribute=INACTIVE. T1(SIP) can be a Lync system. Set up a call from C1 to S1(SIP). Activate CH on S1(SIP). resume Call. Activate CH on C1 and then resume call. The S1(SIP) should use the callhold method, mediaattribute=sendonly. The S1(SIP) can be Linksys or Snom IP telephone.

supplementary_cal lhold_cpetosip_lat esdp

Set up a call from C1 to T1(SIP). Activate CH on T1(SIP). resume Call. Activate CH on C1 and then resume call. The T1(SIP) should use the callhold method, mediaattribute=INACTIVE. The S1(SIP) must be a Cisco UCM system, configured with CUBE.

supplementary_cal lhold_cpetopstn

supplementary_cal lhold_cpetosip_ina ctive

Verify that C1 receives busy signal Verify call setup and disconnect. Verify that CLID is not displayed on C1. Verify call setup and disconnect. Verify that CLID is not displayed on P6(PSTN).

Verify that you get the ivr message before you get b answer.

Verify that you get the ivr message before you get b answer. Verify the two hold and resume, check media both directions after resume. Note the method used in the hold/resume(sendonly/recvonly/ina ctive/blackhole) Verify the two holds and resumes, check media both directions after resume. Note the method used in the hold/resume(sendonly/recvonly/ina ctive/blackhole) Verify the two holds and resumes, check media both directions after resume. Note the method used in the hold/resume(sendonly/recvonly/ina ctive/blackhole)

OK

OK

OK

OK, tested with UPDATE disabled. Tracefile marked with 5.

OK, tested with UPDATE supported. Tracefile marked with 3.

OK, tested with UPDATE disabled. Tracefile marked with 5.

OK, tested with UPDATE disabled. Tracefile marked with 5.

OK, tested with UPDATE supported. Tracefile marked with 3.

OK, tested with UPDATE disabled. Tracefile marked with 5.

OK, tested with UPDATE supported. Tracefile marked with 3.

OK, tested with UPDATE disabled. Tracefile marked with 5. Sonus is not signaling hold.

OK, no trace. Sonus using inactive.

OK

OK

Verify the two holds and resumes, check media both directions after resume. Note the method used in the hold/resume(sendonly/recvonly/ina ctive/blackhole)

OK

Verify the two holds and resumes, check media both directions after resume. Note the method used in the hold/resume(sendonly/recvonly/ina ctive/blackhole)

NA, no cisco pbx available.

OK, tested with UPDATE disabled. Tracefile marked with 5. Sonus is not signaling hold.

CPE Test Library\Supple mentary

Call Waiting

supplementary_cal lwaiting

CPE Test Library\Supple mentary

Conference Call

supplementary_co nference

CPE Test Library\Supple mentary

Forwarding

CPE Test Library\Supple mentary

CPE Test Library\Supple mentary

CPE Test Library\Supple mentary

CPE Test Library\Supple mentary

Blindtransfer

Consultationtran sfer

Establish a call between P6(PSTN) and C1 then call from P7(PSTN) to C1. Put P6(PSTN) on hold and anwer the call from P7(PSTN). Hang up P7(PSTN) and resume the call from P6(PSTN) Set up a call from P6(PSTN) to C1. Set P6(PSTN) on hold and then set up a new call from C1 to P7(PSTN). Set up a conference between C1, P6(PSTN) and P7(PSTN).

supplementary_cf u_pstntocpetopstn

Activate CFU from C1 to P7(PSTN) then call from P6(PSTN) to C1. Answer the call on P7(PSTN)

supplementary_cf nr_pstntocpetopst n

Activate CFNR from C1 to P7(PSTN). Call from P6(PSTN) to C1. Answer call on P7(PSTN)

supplementary_cf b_pstntocpetopstn

Activate CFB from C1 to P7(PSTN). Force C1 to become busy then call from P6(PSTN) to C1. Answer the call on P7(PSTN)

supplementary_bli ndtransfer_pstntoc petopstn

Set up a call from P6(PSTN) to C1 and transfer incoming call to P7(PSTN) immediate.

supplementary_bli ndtransfer_pstntoc petocpe

Set up a call from P6(PSTN) to C1 and transfer incoming call to C2 immediate.

supplementary_co nsulttransfer_pstnt ocpetopstn

Set up a call from P6(PSTN) to C1. Put incoming call on hold/transfer and set up a new call to P7(PSTN). Answer the call on P7(PSTN) and then transfer the call from P6(PSTN) to P7(PSTN).

Verify Call Waiting indicator on C1 when receiving the call from P7(PSTN). Verify connection between the calls. Verify connection between the attendentees. Note! How many attendentees are possible. Is there any limitations regarding internal/external users. Verify correct call and note CLIDdisplayed on P7(PSTN), should be P6(PSTN). Note that type of method used then doing callforward, ex "302 Moved Temporary" or "reinvite"? Note where media is terminated if reINVITE is used, in SBC or PBX? Verify that P7(PSTN) starts ringing according to timer for no reply and note CLIDdisplayed on P7(PSTN), should be P6(PSTN). Note that type of method used then doing callforward, ex "302 Moved Temporary" or "reinvite"? Verify correct call and note CLIDdisplated on P7(PSTN), should be P6(PSTN). Note that type of method used then doing callforward, ex "302 Moved Temporary" or "reinvite"? P6(PSTN) shall receive ringing then C1 have transfered the call. Verify connection between P6(PSTN) and P7(PSTN). Note CLIDdisplayed on P7(PSTN). Verify media connect time. Note where media is terminated, in SBC or PBX? P6(PSTN) shall receive ringing then C1 have transfered the call. Verify connection between P6(PSTN) and C2. Note CLIDdisplayed on C2. Verify media connect time. P6(PSTN) shall receive a information tone when it is parked. Verify connection between P6(PSTN) and P7(PSTN). Note CLID displayed on P7(PSTN). Note where media is terminated, in SBC or PBX?

OK

OK

OK

OK, tested with UPDATE supported. Tracefile marked with 3.

OK, tested with UPDATE disabled. A number is dispayed at C. Tracefile marked with 5. Original A number is displayed at C. ReInvite is used for CFU.

OK, tested with UPDATE supported. Tracefile marked with 3.

OK, tested with UPDATE disabled. A number is dispayed at C. Tracefile marked with 5. Original A number is displayed at C.

OK

NA

OK

OK

OK

CPE Test Library\Miscell aneous

CPE Test Library\Miscell aneous

CPE Test Library\Miscell aneous

DTMF

FAX

Long call

supplementary_co nsulttransfer_pstnt ocpetocpe

Set up a call from P6(PSTN) to C1. Put incoming call on hold/transfer and set up a new call to C2. Answer the call on C2 and then transfer the call from P6(PSTN) to C2.

miscellaneous_dt mf_fromcpe

Dial 23419056. Whenever in the announcement you can enter 9 digits and finish with #. All the digits wil be repeated by the called system.

miscellaneous_dt mf_frompstn

Configure PBX/Phone to recieve DTMF digits. For ex with a "menu" script. Dial from P6(PSTN) to C1.

miscellaneous_fax _fromcpe

Test with t.38 fax protocoll. Send at least 2 pages from C3(SIP) to P9(PSTN).

miscellaneous_fax _frompstn

Test with fax T.38 protocoll. Send at least 2 pages from P9(PSTN) to C3(SIP).

P6(PSTN) shall receive ringing then C1 have transfered the call. Verify connection between P6(PSTN) and C2. Note CLIDdisplayed on C2. Verify media connect time. Verify and confirm the message "Du har tastet, xxxxxxxxx….". Recommended solution for in- and outgoing DTMF is according to RFC2833. If RFC 2833 is not supported and the CPE signals support for SIP INFO, Telenor IPT will send to and accept from CPE DTMF using SIP INFO with “content type = application/dtmfrelay”. CPE must should use RFC 2833. Verify if pbx/phone recieve correct DTMF. Recommended solution for in- and outgoing DTMF is according to RFC2833. If RFC 2833 is not supported and the CPE signals support for SIP INFO, Telenor IPT will send to and accept from CPE DTMF using SIP INFO with “content type = application/dtmf-relay”. Pages is transfered with no errors in both directions. The IPT service supports T.38 fax mode. If T.38 is not available, G.711 pass-through MUST be supported by the CPE as fallback solution. Note: G.711 pass-through mode is considered less robust and vulnerable to jitter and packet loss. Pages is transfered with no errors in both directions. The IPT service supports T.38 fax mode. If T.38 is not available, G.711 pass-through MUST be supported by the CPE as fallback solution. Note: G.711 pass-through mode is considered less robust and vulnerable to jitter and packet loss.

miscellaneous_lon gcall_pstntocpe

Set up a call between P6(PSTN) and C1. Wait until you get two update or reinvite(keepalive message) from the IPT plattform or CPE(about 45-60 min).

The call must not be disconnected after this update or reinvite message.

OK

OK, using RFC 2833.

OK, using RFC 2833.

NA

NA

OK

miscellaneous_lon gcall_cpetopstn CPE Test Library\Miscell aneous

IPT Partner Test

iptpartner_basic_c alls_pstntocpe_ha nguppstn iptpartner_basic_c alls_cpetopstn_ha ngupcpe

iptpartner_supple mentary_callhold_ pstntocpe

CPE Test Library\Miscell aneous

UPDATE test

Set up a call between C1 and P6(PSTN). Wait until you get two update or reinvite(keepalive message) from the IPT plattform or CPE(about 45-60 min).

The call must not be disconnected after this update or reinvite message.

OK

Call from P6(PSTN) to C1. Answer the call. Hang up the call from P6(PSTN)

The CPE sending a P-PreferredIdentity, GDN number.

OK

Call from C1 to P6(PSTN). Answer the call. Hang up the call from C1 Set up a call from P6(PSTN) to C1. Activate callHold(CH) on C1 and then resume the call. In the same call, activate CH on P6(PSTN) and then resume the Call.

OK, tested with UPDATE disabled. Tracefile marked with 5.

OK

OK

iptpartner_supple mentary_cfu_pstnt ocpetopstn iptpartner_supple mentary_blindtran sfer_pstntocpetop stn

Activate CFU from C1 to P7(PSTN) then call from P6(PSTN) to C1. Answer the call on P7(PSTN)

OK

Set up a call from P6(PSTN) to C1 and transfer incoming call to P7(PSTN) immediate.

OK

2xCFU_jbnr_updat e

Set up a call against 22391721 with cfu to mobile. And then cfnr to PSTN.

IPT plattform is sending UPDATE to A

Not tested

NOK, Sonus sending 200 OK without SDP on an UPDATE with SDP.

OK, tested with UPDATE disabled. Tracefile marked with 5.