Hadriel Kaplan

1. VERMOUTH for MARTINISIP MARTINI Variant of 'Event-package for Registrations‘ for Managed Open-ended Username Target Handling (VERMOUTH)draft-kaplan-martini-vermouth-00 Hadriel Kaplan

2. The Problem • GIN gives us reg-event for PBX side, but… • It’s also useful for Martini in the SSP side • For systems to learn when the IP-PBX is registered and its path/contact info • For the IP-PBX et al to verify/learn what AoRs the SSP associates with it • For SSP to Notify IP-PBX of adds/removes • But the usernames may be open-number-plan or Local Numbers • Each actual possible username is unknown to SSP • And it may be a very big list if it is known

3. Mismatched provisioning: a real problem • When SSP and PBX AoRs don’t match, bad things happen: • Calls fail to reach PBX • Calls loop (badly) • Sometimes the error is caught quickly, but usually not until it’s actually called • It takes time to troubleshoot, and reducing that time saves money and customer frustration

4. Possible Solutions • Use reg-event, define a syntax to handle open/wildcard usernames for AoRs in reg-event • Subscribe to something new (not reg-event) to learn about provisioned AoRs • Use PUBLISH to push from SSP to PBX VERMOUTH currently does #1, but it’s tempting to go for #2

5. Proposed Solution in Draft • Define a new “Bulk-AoR” for reg-event • Uses new “range” user param to indicate range • E.g.: sip:+12345678;range=0-9(1,4)@example.com bulk-aor-user = user ";range=" expansion expansion = exp-char-set exp-char-count exp-char-set = digit-char-set / any-char-set digit-char-set = dsc-begin "-" dsc-end dsc-begin = DIGIT dsc-end = DIGIT any-char-set = "." exp-char-count = "(" exp-min "," exp-max ")" exp-min = DIGIT exp-max = DIGIT

6. Why not regex? • Some common regex characters are not allowed in SIP URIs and would need to be escaped • ^, [, ], {, } • Regex patterns are good for figuring out if a given string matches the pattern, but not what all possible strings matching it are • E.g., you can tell if 12345 matches, but not that 12346 and 1234567 also match • In other words, it’s hard to tell if the SSP thinks more usernames belong to the PBX than the PBX does • There are numerous patterns which match the same strings

7. Example reginfo XML <?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="0" state="full"> <registration aor="sip:+12345678;range=0-9(1,4)@example.com" id="as9" state="active"> <contact id="76" state="active" event="registered" duration-registered="7322" q="0.8"> <uri>sip:192.1.2.3;bnc</uri> </contact> <contact id="77" state="terminated" event="expired" duration-registered="3600" q="0.5"> <uri>sip:192.4.5.6;bnc</uri> </contact> </registration> </reginfo>

8. Subscribing • The current 00 draft has the SSP process Subscribes to the AoRs, but GIN now does the opposite: normal Subscribes go to the PBX • GIN wins, so VERMOUTH draft will change • The question is what URI syntax to use for the PBX to subscribe to the SSP for the data • E.g., “sip:pbx1@ssp.com;bulk”

9. Choosing Option-2 • It’s tempting to define a new bnc-reg-event package • Can be made more efficient, because all AoR’s share same contact/path info • Don’t need to create a Bulk-AoR format as a URI – just do it as explicit XML • New package name lets SSP route it to appropriate server in SSP

10. Questions • Is this a problem worth solving? • Is there interest to do so in this WG?

11. Open Issues

12. Bulk AoR format • Should we just use regex and escape illegal characters? • Since the URI user type is of a specific type, should we create a new ‘user’ param enumeration value? • E.g., “;user=bulk” similar to user=phone

13. What about email-style AoRs? • Currently VERMOUTH includes this in the range syntax • E.g., “sip:.(1,9)@ssp.com” • But in practice they probably won’t work this way and would need to be enumerated, possibly leading to large sets • And reg-event’s XML schema is inefficient for that case