The calling community gives feedback on SIP 603+
The SIP 603+ standards task force invited feedback from an association of calling community businesses. The association responded. Does the standards draft satisfy their issues? Let’s have a look.
The standards task force asked for the calling community to list issues that they want to see addressed in the standards. An association of high-volume callers participated in their reply. These members included the following:
- American Bankers Association
- ACA International
- American Financial Services Association
- Credit Union National Association
- Mortgage Bankers Association
- National Association of Federally-Insured Credit Unions
- National Council of Higher Education Resources
- Student Loan Servicing Alliance
In their ex parte filing, the association advocated for the adoption of the SIP 608 call blocking notification without the J-Card. They also shared their response to the ATIS SIP Forum IP-NNI Task Force, which had requested feedback on priorities that callers have for call blocking notification.
In this letter to the IP-NNI, the association listed eight issues that the SIP 603+ standards should address. We’ve listed these requests in the following table, along with our assessment of whether the draft standards document covers each request.
|Nbr||Issue||Addressed in draft standard?||Reference|
|1.||Uniform, standard word or phrase in the header of the code that clearly indicates that the call has been blocked using analytics.||Yes||“If a service provider blocks a call due to analytics, the service provider shall reply with a SIP 603… The SIP 603 response shall have a reason phrase of ‘Network Blocked’”|
|2.||The code can be read using automated, machine-readable technology.||Yes||The standards framework is built upon other SIP standards, such as RFC-3261, which describe how SIP messages are formatted. The format is machine-readable.|
|3.||It should be clear that a 603+ Code without a reason header signifies the called party has declined the call, per existing IETF documentation.||Yes||“603+ is differentiated from a 603 response in that it contains a format where it has a reason phrase NETWORKED BLOCKED (i.e., 603 NETWORKED BLOCKED) with a Reason code that has reason = analytics, and the contact information of whom blocked. The contact information allows the calling party to communicate with the entity responsible for the blocking. Any 603 received without this syntax included should be treated as current handled today.”|
|4.||The reason header must include, in standardized formats, the name and contact information for the blocking entity.||Yes||“The text value shall include at least one url, tel, or email parameter.”|
|5.||The standard should address, to the extent practicable, the transmission of the 603+ Code across international boundaries.||Yes||“This standard is primarily developed for and adoption by US service providers. Other countries may adopt these standards and they may be implemented through bilateral agreement with business partners in the US pursuant to their business agreement. This standard is not precluded from being used internationally.”|
|6.||“The standard for SIP Code 603+ should address which entity should receive notification where a third party initiates the call on behalf of a customer, for example, where a call center is utilized.”||Yes||“The transit network shall transparently forward a SIP 603 received. The originating network shall forward the SIP 603 message toward the CgP [calling party].”|
|7.||“To the extent practicable, the standard for SIP Code 603+ should consider cost of deployment and implementation by small carriers and both large and small enterprise callers.”||No||There’s nothing in the draft standard that explicitly addresses cost of deployment. It shows how SIP 603+ is done. However, its advocates claim that 603+ would be a less costly method.|
|8.||“The standard for SIP Code 603+ should ensure that callers’ calling applications are able to interrogate the header on the 603+ Code.”||Yes||“The transit network shall transparently forward a SIP 603 received. The originating network shall forward the SIP 603 message toward the CgP [calling party].”|
By our tally, the draft standard clearly satisfied seven of the eight requests. The one open request, cost of deployment, is not explicitly discussed in the standards document. (One could debate whether such discussion is required in a standards document.) However, affordability is a primary benefit claimed in the comments from SIP 603+ advocates.
Does this exchange foreshadow an emerging consensus on SIP 603+ for call blocking notification? The draft standards document seems to easily cover these issues and concerns. It will be interesting to see how this unfolds.
TransNexus is a leader in developing innovative software to manage and protect telecommunications networks. The company has over 20 years’ experience in providing telecom software solutions including toll fraud prevention, robocall mitigation and prevention, TDoS prevention, analytics, routing, billing support, STIR/SHAKEN and SHAKEN certificate services.
Contact us today to learn more.
This information will only be used to respond to your inquiry. TransNexus will not share your data with any third parties. We will retain your information for as long as needed to retain a record of your inquiry. For more information about how we use personal data, please see our privacy statement.
Our STIR/SHAKEN products:
- Work with your existing network
- Support SIP and TDM
- Affordable, easy to deploy