Transit presentation

1
Transit presentation

• International Inbound Services Forum
• Xian, China, September 2004

2
The need for transit

• When two carriers wish to implement IFS/HCD but
  do not have direct circuits
• They need to route calls via a transit carrier
• Need for IFS/HCD via transit is growing
• more carriers wanting to introduce service
• customer demand for new countries
• carriers closing direct circuits

3
Trends

• Some carriers will not implement IFS/HCD via
  transit
• accounting system cannot recognise origin carrier
  (can only recognise incoming route)
• problems with origin carrier sending traffic via
  wrong transit carrier
• policy, legal reasons
• lack of understanding between network and
  commercial staff about each others issues

4
Trends

• Some carriers will not act as transit carrier
• extra work with need to maintain routing codes
• difficulties with settlement (not receiving
  transit fee from destination knowing to chase up
  the right carrier)
• Some carriers ceasing to provide transit

5
Trends

• Preference for direct accounting rather than
  cascade
• Some carriers agreeing to end bilateral
  accounting relationships (all traffic is refiled)

6
Transit scenarios

• Traditional transit (reverse-class)

7
Transit scenarios

• Traditional transit (reverse-class)
• Carrier A (destination) and Carrier B (origin)
  have a IFS/HCD agreement
• Carrier A (destination) and Carrier C have a
  transit agreement

8
Transit scenarios

• Traditional transit (reverse-class)
• Carrier C must maintain a switch routing table in
  order to route the calls to the correct
  destination carrier
• Carrier C has to know that the traffic is
  reverse-class and expect declaration from the
  destination, not the origin
• Carrier A has to identify both the origin and
  transit carriers and declare to both

9
Transit scenarios

• Traditional declaration replaced with invoices

10
Transit scenarios

• Traditional declaration replaced with invoices
• this scenario recognises that traditional
  declarations are being replaced with invoices in
  some agreements
• Carrier C must still maintain a switch routing
  table in order to route the calls to the correct
  destination carrier
• Carrier C still has to know that the traffic is
  reverse-class and send the invoice to the
  destination, not the origin

11
Transit scenarios

• IISFs alternative scenario with traditional
  declaration

12
Transit scenarios

• IISFs alternative scenario with traditional
  declaration
• proposed at an ITFF meeting some years ago
• eliminates the issues for the transit carrier
  relating to collecting the transit fee from
  destination
• Carrier C no longer has to know that the traffic
  is reverse-class

13
Transit scenarios

• IISFs alternative scenario with invoices

14
Transit scenarios

• A hubbing (refile) model

15
Transit scenarios

• A hubbing (refile) model
• The call is refiled through Carrier C as if it
  were an IDD call
• Carrier A and B still have bilateral IFS/HCD
  agreement (this is not wholesale IFS/HCD)
• Carrier B then invoices Carrier A for IFS/HCD
  access

16
Proposal for an IISF-sponsored hub

• A new option proposed by the Transit Task Force
• Extends the refile model
• No reverse billing for the transit fee
• this addresses an issue that stops many carriers
  acting as IFS/HCD transit point
• in line with trend away from traditional switched
  transit to hubbed (refiled) services

17
Proposal for an IISF-sponsored hub

• Example of implementation
• Carriers A, B, C, D indicate willingness to be
  transit hubs
• Carriers 1 and 7 enter into IFS/HCD agreement and
  need transit

18
Proposal for an IISF-sponsored hub

• Carrier 1 routes its IFS/HCD calls for Carrier 7
  to Carrier A
• Carrier A screens routing prefix routes calls
  to Carrier C
• Carrier C screens routing prefix routes calls
  to Carrier 7

19
Proposal for an IISF-sponsored hub

• Carrier A invoices Carrier 1 for terminating a
  call to Carrier 7
• Carrier C invoices Carrier A for terminating a
  call to Carrier 7

20
Proposal for an IISF-sponsored hub

• Carrier 7 pays Carrier 1 for originating an
  IFS/HCD call
• Payment includes reimbursement for the transit
  costs
• The payment could be by declaration or after
  invoicing

21
Proposal for an IISF-sponsored hub

• To implement the proposed hub
• carriers able to act as a transit hub indicate
  their willingness
• each carrier in hub publishes a list of IFS/HCD
  destination carriers they can reach
• destination codes would be the routing number
  prefixes of the destination country
• some hub carriers would need to buy terminations
  off others in the hub

22
Proposal for an IISF-sponsored hub

• The money flow
• it is anticipated that the transit hub would
  operate on invoicing (in line with the trend away
  from traditional declarations)
• transit carrier would invoice the sender (IFS/HCD
  origin)
• IFS/HCD routing codes would just be another
  destination on hub carriers price list

23
Proposal for an IISF-sponsored hub

• The money flow
• destination carrier would pay origin carrier for
  IFS/HCD access and reimburse origin carrier for
  transit costs
• for HCD, charging would have to be on circuit
  time, not conversation time

24
Proposal for an IISF-sponsored hub

• Questions?
• Discussion
• Interest in proceeding?

25
VoIP

• Does VoIP offer new transit options?
• What use are carriers making of VoIP?
• Where do you see this in five years time?

26
Transit presentation

• International Inbound Services Forum
• Xian, China, September 2004