A Unified Proposal for Bulk AOR Dynamic Rou:ng - - PowerPoint PPT Presentation

▶
a unified proposal for bulk aor dynamic rou ng dra roach
SMART_READER_LITE
LIVE PREVIEW

A Unified Proposal for Bulk AOR Dynamic Rou:ng - - PowerPoint PPT Presentation

May 28, 2023 491 likes •620 views

A Unified Proposal for Bulk AOR Dynamic Rou:ng dra<roachmar:niup00 MARTINI Interim Mee:ng January 7, 2010 Problems with Proposed/Deployed Models REGISTER seman:cs inherently deal with a single user. Extending REGISTER

slide-1
SLIDE 1

A Unified Proposal for Bulk AOR Dynamic Rou:ng dra<‐roach‐mar:ni‐up‐00

MARTINI Interim Mee:ng January 7, 2010

slide-2
SLIDE 2

Problems with Proposed/Deployed Models

  • REGISTER seman:cs inherently deal with a

single user.

  • Extending REGISTER to work with mul:ple

users is a change to the exis:ng authoriza:on model for a core SIP request method. This may break assump:ons of deployed servers.

slide-3
SLIDE 3

Problems, con:nued

  • By reversing model of who indicates the AORs being

registered (i.e., delega:ng determina:on of registered AORs to the registrar using implicit registra:on), ar:ficial mismatches between SSP behavior and PBX expecta:ons can arise.

– No good solu:on: by the :me the PBX knows something is wrong, the incorrect network state is already created. – When the PBX detects the error, there is no protocol recovery path. – If we return to the model in which the client explicitly indicates the AORs under considera:on, and the server indicates whether the requested AORs are in policy, then this ar:ficial problem dissolves.

slide-4
SLIDE 4

Many Documented “Problems” are Issues with Solu:on

  • Many of the documented “problems” are not

inherent to the issue of bulk registra:ons, and arise only from stretching REGISTER in direc:ons it was never intended. These problems simply dissolve when addressed using other mechanisms:

– The need for explicit indicators – PAU mismatch issues – Register response sizes – Target informa:on loss – “Loose rou:ng” issues

slide-5
SLIDE 5

“Backwards Compa:bility” is a Fallacy

  • Objec:ons to using approaches other than a

“tweaked REGISTER” generally reduce to “but we currently have REGISTER deployed.”

  • Currently deployed solu:ons suffer from

myriad problems; cf. mixing‐problems document.

  • Therefore, protocol changes are required.
  • If protocol changes are required, then all

currently deployed solu:ons require upda:ng.

slide-6
SLIDE 6

Overview of Proposal

  • Informa:on in SIP Loca:on Server db is

available through two mechanisms:

– REGISTER can both set and get informa:on for a single user – SUBSCRIBE/NOTIFY with ‘reg’ event package can get informa:on for mul:ple users

  • Natural extension of the foregoing: PUBLISH

with ‘reg’ event package can set informa:on for mul:ple users

slide-7
SLIDE 7

Behavior

  • Publisher (e.g., SIP PBX) publishes and

maintains routes using ‘reg’ event PUBLISH

  • requests. To conserve space, we define a new

body type for ‘reg’ event that can aggregate several AORs into a single record.

  • Dynamic Rou:ng Server updates Loca:on

Server db with informa:on from PUBLISH requests.

slide-8
SLIDE 8

Example: Rou:ng E.164 Range

PUBLISH sip:company@rou:ng‐server.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:pbx.example.com;tag=xyzygg To: sip:company@rou:ng‐server.example.com Call‐ID: 9987@app.example.com CSeq: 1288 PUBLISH Max‐Forwards: 70 Expires: 3600 Event: reg Content‐Type: applica:on/reginfo‐bulk Content‐Length: ... 1 full /sip:+1214329(0...)@example.com/sip:\1@pbx.example.net/ 14 registered

slide-9
SLIDE 9

Example: Rou:ng Domain

PUBLISH sip:company@rou:ng‐server.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:pbx.example.com;tag=xyzygg To: sip:company@rou:ng‐server.example.com Call‐ID: 9987@app.example.com CSeq: 1288 PUBLISH Max‐Forwards: 70 Expires: 3600 Event: reg Content‐Type: applica:on/reginfo‐bulk Content‐Length: ... 1 full /sip:(.*)@example.net/sip:\1@192.0.2.5/ 14 registered

slide-10
SLIDE 10

Example: Rou:ng Mul:ple Ranges

PUBLISH sip:company@rou:ng‐server.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:pbx.example.com;tag=xyzygg To: sip:company@rou:ng‐server.example.com Call‐ID: 9987@app.example.com CSeq: 1288 PUBLISH Max‐Forwards: 70 Expires: 3600 Event: reg Content‐Type: applica:on/reginfo‐bulk Content‐Length: ... 1 full /sip:+1214329(0...)@example.com/sip:\1@pbx.example.net/ 14 registered /sip:+1919555([123456789]...)@example.com/sip:\1@pbx.example.net/ 14 registered

slide-11
SLIDE 11

Advantages

  • By mimicking REGISTER on an AOR‐by‐AOR

basis, many of the problems that arise from implicit registra:on with mul:ple users are completely sidestepped.

– “Loose rou:ng” and “target URI” problems disappear – request processing is iden:cal to singly‐registered AORs. – Ambigui:es that cause authoriza:on policy and “P‐Asserted‐Iden:ty” mismatches are far clearer with this model.

slide-12
SLIDE 12

Advantages, cont.

  • Because REGISTER is not overloaded to mean two

different things, no explicit indicator is required.

  • Because the UAC specifies the AORs to be routed,

no opportunity for (e.g. P‐Associated‐URI) mismatches arise.

  • Also because the UAC specifies the AORs,

response size is not an issue.

  • Compact representa:on of AORs to be routed

helps manage total message sizes.