Subject: Re: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers

From: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Date: Sat, 20 Feb 2010 10:02:38 -0500

So the scope is limited to SMB

----- Original Message -----
From: [email-masked] <[email-masked]>
To: 'MARTINI' <[email-masked]>
Sent: Sat Feb 20 09:50:24 2010
Subject: Re: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers

I think this requirement can safely be removed. The vast majority of installations I'm aware of that use Implicit Registration are typically sub 24 CUA's in the single site SMB market.

 Section 5

    DES2 - The mechanism SHOULD scale to SIP-PBXs of several thousand
    assigned telephone numbers.

 [BA] Do we really think that the MARTINI mechanism will be used to
 register several thousand AORs??  I had thought that is mechanism is most
 likely to appeal to small businesses or branch offices with a modest
 number of extensions (e.g. typically a few hundred at most).

 Recommending that the mechanism work with several thousand AORs has
 implications for issues such as request or response fragmentation, SIP
 message size, etc.  So before putting in a requirement like this (even if
 it is only desirable), I'd like to see concrete evidence that there are
 real customers out there who both might
 use it that way, and have good reasons to do so (e.g. there is a good
 reason why they can't use RFC 3263 domain routing instead with a static or
 even a dynamically assigned address and dynamic DNS).

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/martini/trac/ticket/2>
martini <http://tools.ietf.org/martini/>

_______________________________________________
martini mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/martini

_______________________________________________
martini mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/martini

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 20 Feb 2010 10:34:50 -0500

Well Marty I never want to say never but it seems to be the reality. Then you have to define SMB and I don’t think we want to go there either ..its like the FCC trying to define Broadband.

----- Original Message -----
From: [email-masked] <[email-masked]>
To: 'MARTINI' <[email-masked]>
Sent: Sat Feb 20 09:50:24 2010
Subject: Re: [martini] #2: Scaling to Several Thousand Assigned TelephoneNumbers

 Section 5

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 20 Feb 2010 10:56:44 -0600

(where "SMB" is defined as "the number of AoRs that we don't have to worry 
about fragmentation to include") :-) ?

> I think this requirement can safely be removed. The vast majority of 
> installations I'm aware of that use Implicit Registration are typically 
> sub 24 CUA's in the single site SMB market.
>
>
>
> Section 5
>

---

From: Dean Willis <[email-masked]>
Date: Sun, 21 Feb 2010 10:17:27 -0600

Spencer Dawkins wrote:
> (where "SMB" is defined as "the number of AoRs that we don't have to
> worry about fragmentation to include") :-) ?
>
Ok, that's a good question.

Exactly what is the limit on the number of AORs that we can encode
without worrying about fragmentation?

Reverse-engineering, I suppose we should have a number for the size of a
current registration message. I just wiresharked my ekiga and gizmo
registrations, and they're 584 and 633 bytes each, respectively. If
that's representative, this gives something in the neighborhood of 700
bytes of wiggle room. At 10 bytes per phone number range, that's about
70 numbers. So, worst-case, we COULD explicitly list a few dozen URIs
without having to worry about clever encoding of ranges, and with clever
encoding we might reasonably expect more than 50 phone number ranges.

By the way, I had not done a packet capture on my Ekiga client lately.
My goodness it is chatty! Lots of 489 and 405 messages, too, indicating
somebody didn't capabilities-match very well.

--
Dean

--
Dean