Basic RTCP Voice over IP Metrics
RTP control protocol (RTCP as per RFC 3550) measures the call quality and generates a report based on key metrics such as Packet loss rate/discard rate, Max*Jitter, Mean*Jitter, Average Round Trip Delay, Max Round Trip Delay, Burst length/density and gap length/density. RTCP is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol provides multiplexing of the data and control packets, for example using separate port numbers with UDP.
The primary function of RTCP involves providing feedback on the quality of the data distribution and sending reception feedback reports to all participants, which in turn will allow the QOS administrator to evaluate whether problems are local or global.
RTCP support on VX supports RFC 3550 and RFC 3611 with exception to the parameters listed under Sec 2.2 RFC Compliance. Following functionality is supported on VX:
- Building and Sending RTCP SR and RR report as per RFC 3550.
- Transmission interval for sending RTCP packets will be configurable.
- Receiving RTCP packets and extracting SR and RR report as per RFC 3550. VX will generate a CDR based report based on the metrics calculated
- Receiving RTCP*XR packet and extracting Statistical Summary and VoIP metrics as per RFC 3611.
- Sending of RTCP*XR packets will be supported with exceptions to the parameters listed under Sec 2.2 RFC Compliance.
- RTCP functionality will be supported for SIP transport only. For other protocols, VX will not process RTCP but will send and receive RTCP.
- RTCP metrics logs CDRs on per call basis.
The CNG tone is the first tone sent by the calling fax machine, and is used to determine when a call is going to be a fax call. This way a particular number does not need to be dedicated to automated voice or fax.
Previous VX releases only started T.38 when the receiving fax machine sent the 2100 Hz tone. This change will cause T.38 to start earlier, at the time when the sending fax begins the call.
The DSPs on the STIX card provide CNG tone detection. This is not needed for the normal fax case, as the receiving fax sends the data signal to indicate it is ready for fax reception. However, on systems that need to autodetect between a voice call and a fax call, the CNG tone is frequently used. Therefore, as soon as the CNG tone is detected, we will now switch the call to T.38 mode, causing the MSG*REQUEST on BSP calls and the REINVITE on SIP calls. H.323 also has a variety of codec renegotiation methods, and these will be triggered as needed. The exact same display will show on all monitoring tools, however a close observation will reveal that the MSG*REQUEST/REINVITE is sent upon the first CNG after the call is connected.
The delay of the REQUEST/REINVITE is needed so that the answering device is fully prepared to be advised of the fax call.
SIP 180 Ringing Event Pass Through and Longer SIP Call-ID
Events Pass Through
VX previously supported passing through headers that are not processed untouched in proxy like mode. This functionality is extended for the "180 Ringing" and "183 Session Progress" messages in the same way as it is done for "INVITE" message.
Longer SIP Call-Id
Call-Id act as an unique identifier used to uniquely identify a call between two user agents. They are case-sensitive and are simply compared byte-by-byte. Example: Call-Id: firstname.lastname@example.org. The SIP calls initiated from the VX previously had short SIP call ID values (e.g.: email@example.com). This can cause duplication problems in scenarios where the call ID is used as a unique identifier across time and space to locate a call.
PBX2 Certification Enhancements
VX now supports 802.1q and 802.1p specifications such that packets going out of VX's Ethernet port will be marked with VLAN-ID (802.1q) based on IP interface being used to transmit the data. Individual applications like SIP, H323, and BSP will be able to set VLAN priority (802.1p) for packets going out.
PBX Network Scenario
Consider the network scenario shown in the illustration below.
- VX is physically connected to a core switch (a L3 router). The switch is configured such that the line between VX and the switch behaves as an Ethernet trunk carrying multiple trunk-links (tagged packets), one for each VLAN.
- SIP phone 184.108.40.206 is in public domain (In a network which is not directly connected).
- All other networks are directly connected.
- Interface IP0 to IP5 are configured on a single adapter and is physically connected to core switch (a L3 router) via an Ethernet trunk.
- Interface IP6 is configured on a separate adapter and sends and receives untagged packets.
VLAN-ID (802.1q) is the identification of a virtual LAN on trunk link, where packets from multiple VLANs will be passing at same time. However, in order to communicate on a LAN (or VLAN for that matter), any machine needs an IP address belonging to that network. Therefore, IP interfaces on VX will be configurable to specify their VLAN. So, each IP interface will belong to only one VLAN at a time. In case network to which IP interface belongs is untagged in nature i.e. it does not carry 802.1q tagged packets, IP interface can be configured to 'Untagged'.
VX will accept tagged packets arriving on its IP interface only if the VLAN-ID on the packet matches the configured value. Inbound call signaling packets will use inbound call routing table to match required TG on basis of remote-ip address and transport type. Since, VX has to decide VLAN priority at application level, 802.1p value will be configurable separately for Media (RTP/VTP/T38) and Signaling (SIP/H323/BSP) at Trunkgroup.
Once the call is routed, Out-bound trunkgroup will identify the priority values for media and signaling respectively. So, the packets going out will have the VLAN-ID of IP interface and priority as decided by higher layers. On inbound call leg, responses will be marked with same priority with which the request arrived.
It is important to note here that 802.1p priority can be configured on TG but if packet leaves VX from an IP interface configured as 'Untagged', there will not be any 802.1q header present, implying that their will be no 802.1p information available as well.
Apart from TG, 802.1p priority is configurable at IP route and IP interface as well. This is done for data being routed through VX (when VX is used as a router) or packets which have not been assigned priority by applications. This kind of packets include data originated from VX like SBCP, Telnet, FTP, BMP, SSH, SYSLOG, SNMP etc. Peer table will have 802.1p priority to be used for pings sent to peer.
Following explains the behavior in different scenarios:
- SIP/RTP from 192.168.6.10 (sipp1) to 192.168.5.10 (sipp2)
- SIP INVITE message reaches VX at ip interface ip5 with VLAN-ID 6 and priority 3. Call flow with VLAN-ID and priority will be as follows:
- In call flow (x, y) represent (VLAN-ID, Priority):
- VX trunkgroup used in this call is configured with Media 802.1p priority 2 and signaling 802.1p priority 4.
- Only first few messages of call flow are shown here to demonstrate the behavior by way of VLAN-ID and 802.1p priority.
- Note here, that on inbound call leg VX responds with same priority with which the initial request came in.
MWI (Message Waiting Indication) support is to be added to the QSIG ISDN protocol as part of the VX 4.3 release. Also enhancements to the support within SIP that already exists will be made so that Subscription messages will not have to be used before the MWI NOTIFY message is received. The current SIP to NI-2 MWI signaling will also still be supported.
Previous VX releases support MWI in a limited fashion between SIP and the NI-2 ISDN protocol. This support is only available for indications going from SIP to ISDN and the SIP side requires a Subscription request to precede the MWI NOTIFY.
QSIG Calling Party Name Support
This feature adds the Calling Party Name Identification Presentation supplementary service (SS-CNIP) in QSIG.
This feature is supported both for calls from QSIG network to the SIP network (incoming call) as well as for a call from the SIP network to QSIG network (outgoing call).
This feature does not support the user profiles which enable the user to override the Calling Name Identification Restriction (Refer , section220.127.116.11).
The basic call services are already supported in QSIG. This feature will add a supplementary service which enables the called party to see the name of the calling party.
The Calling Party Name Identification support is already implemented in the NI-2 flavor of ISDN protocol supported on the VX. This feature shall implement the same for QSIG.
Calling Name Identification Presentation (CNIP) is a supplementary service which is offered to the called user and which provides the name of the calling user (Calling Party Name) to the called user.
Passing Call Diversion Information Between QSIG and SIP
This feature enables VX to support passing of call Diversion information from QSIG based PBX to SIP based Microsoft Exchange UM server. In QSIG, it is possible to send following type of diversion reasons:
- Call forward no Reply (CFNR)
- Call forwarding busy (CFB)
- Call forwarding unconditional (CFU)
The illustration below shows a typical scenario in which this feature will be used:
The VX may receive a diverting number and diverting reason from QSIG message and transform them in to SIP messages. The UM server may in turn use this information to play appropriate prompt based on the diversion Information.
- The implementation depends on recommendations for diversion header in SIP as specified in draft-levy-sip-diversion-08.txt (expired) and as specified in ECMA-174, ECMA-360 for QSIG.
- This will describe the functionality modifications on VX for supporting Call Diversion from QSIG to SIP only.
- Previously VX supported basic calls between QSIG to SIP and SIP to QSIG. It also supported Diversion information between NI2 and SIP but, it didn't support call Diversion service from QSIG to SIP.
- The diverting Number and call diversion reason specified in the QSIG setup message will be conveyed to a SIP UM server using Diversion header in SIP INVITE request. The rest of the messages will not carry any other information related to this feature.