1 Interoperation with the Circuit-Switched Telephone System ffl interoperation scenarios ffl mapping E.164 phone numbers to addresses ffl finding hop-off gateways: TR
2 Interoperation assumptions each phone needs to be reachable from the PSTN, without ffl dialing an! address possible IETF working group, ETSI Tiphon LDAP DNS multiple gateways from to PSTN ffl (almost) any gateway can call any! phone locate best / closest / cheapest attributes distributing and merging attributes! TR
3 DNS for number mapping ffl SCP may treat DNS as yet another database ffl use DNS NAPTR rewriting for local number portability (LNP) ffl find out which signaling services are supported Issues for any scheme: ffl rapid, secure, globally visible updates (e.g., for LNP) ffl ownership of addresses or neutral third party?
4 e164.arpa 1. convert to digits:! +46-8-56264000 46856264000 2. insert dots: 4.6.8.5.6.4.0.0.0 3. reverse: 0.0.0.4.6.5.8.6.4 4. append TLD: 0.0.0.4.6.5.8.6.4.e164.arpa
5 Phone number rewriting ffl NAPTR (RFC 2168, being updated): originally for URN rewriting ffl flag: a for A RR, s for SRV RR 2.8.0.4.6.2.6.5.8.6.4.e164.int. IN NAPTR 10 10 "a" "sip+n2r" "" "sip:paf@swip.net". IN NAPTR 102 10 "s" "potscall+n2r" "" _potscall._tcp.paf.swip IN NAPTR 102 10 "a" "smtp+n2r" "" "mailto:paf@swip.net".
6 Local number portability ffl old number: +46-346-23232, but has moved to a telcoy. 2.3.2.3.2.6.4.3.6.4.e164.int. IN NS ns.telcoy.net. ffl Telco Y allocates +46-8-919191: $ORIGIN 6.4.e164.int. _potscall._tcp.2.3.2.3.2.6.4.3 IN SRV 10 10 1.9.1.9.1.9.8
7 Translation from E.164 to S +46-76-11223344 gets translated via Global Title Translation by the SCP finding DNS record: 4.4.3.3.2.2.1.1.6.7.6.4.e164.int. IN SOA... IN NS... IN NAPTR 100 10 "a" "sip+n2r" "" "sip:foobar@x.example.ne Then, call can only be made by S. The SCP routes the call to the correct gateway, using a mechanism currently not specified.
8 PSTN-to-Vo gateway location ffl currently, not specified use hop-off closest to destination or where doing number ffl translation? maybe get address via S OPTIONS and then determine best ffl hop-off point?
9 Gateway location protocol architecture ITAD 1 ITAD 2 GW 00 1 LS EU 01 0 TR 01 0 01 0 ITAD 3
10 Gateway location protocol ffl inter-domain distribution of gateway properties ffl multiple signaling hops - aggregation! additional server aggregation of entries (e.g., Cologne/Bonn area +49221, +49228, ffl +492222,..!. +4922) ffl but difficult in NANP: NJ has 201, 609, 732, 908, 973. ffl local calling areas may have a hundred exchange codes! ffl generally, use most specific match ffl policy filtering to restrict advertising prefixes
11 Gateway aggregation GW LS (49221, 193.29.188.3, 0.08DM) (4922, 193.29.188.3, 0.24 DM) Cologne (49, 193.29.188.3, 0.36 DM) +49 221 01 0 Bornheim (49222, 212.63.153.60, 0.10DM) +49 2222 010 (4922, 194.231.195.1, 0.08 DM) Königswinter +49 2223 010... query S query S To: tel:+492232790 S S Brühl... 194.231.195.1 193.159.218.76 +49 2232 01 0 192.129.40.243 voice data RTP Bonn +49 228 01 0... Dortmund +49 231 010 (49231, 195.138.36.100, 0.08 DM) (49, 195.138.36.100, 0.36 DM)
12 Attributes ß DestinationPhoneNumbers phone number prefix (+1201) NextHopSignalingServer direct H.323, S,...here AdvertisementPath BGP AS PATH, object path GatewayCapacity load balancing? SignalingProtocols H.323, S,... Pricing $/minute, setup charges, increment,... LastModifiedBy verifiable source of attribute NumSignalingHops min/max signaling (not media) hops AtomicAggregate aggregation indicator MultiExitDisc preference between multiple LS LS links
13 Attribute transitivity Optional: if not set, must be understood to process routing object; IndependentTransitive: propagate even if not understood; DependentTransitive: propagate if not understood, but don t touch next-hop; LastModifiedByFlag: covered by last-modified-by parameter. route objects always contain (DestinationPhoneNumbers, NextHopSignalingServer), where server is in ITAD of originating LS
14 Telephony Routing Information Protocol (TR) ffl from BGP-4: transport (TCP), message format (TLV) ffl from OSPF and SCSP: flooding ffl initially, exchange routing database when establishing connection ffl incremental updates (no refreshes) UPDATE advertised route signaling server price withdrawn route withdrawn route
15 TR LS peered with OPEN KEEPALIVE OPEN LS open handshake UPDATE KeepAlive (30s) NOTIFICATION error condition
16 Signaling: S to ISDN S INVITE 100 ISDN SETUP CALL PROC 183 PRACK 200 (PRACK) PROGress two way RTP 200 ACK one way voice CONNect CONNect ACK BYE 200 DISConnect RELease RELease COMplete
17 Signaling: S to ISUP NGW caller S +1 212 555 0202 ISUP +1 212 55 0101 INVITE sip:+1 212 555 0101 100 Trying IAM 183 Session Progress ACM duplex RTP media one way voice 200 OK ANM ACK BYE 200 OK REL RLC
18 References ffl P. Faltstrom, E.164 number and DNS, Internet Draft, October 1999. ffl A. Brown, E.164 Resolution, Internet Draft, October 1999. J. Rosenberg, H. Schulzrinne, Internet Telephony Gateway Location, ffl IEEE Infocom, San Francisco, March 1999. J. Rosenberg, H. Salama, M. Squire, Attributes for a Gateway Location ffl Protocol, Internet draft, June 1999. J. Rosenberg and H. Schulzrinne, A Framework for a Gateway Location ffl Protocol, Internet Draft, June 1999. J. Rosenberg, H. Salama, M. Squire, Telephony Routing Information ffl Protocol (TR), Internet Draft, October 1999.