Subject: Re: [BLISS] Fwd: I-D ACTION:draft-johnston-bliss-mla-req-00.txt

From: [email-masked]
Date: Mon, 2 Apr 2007 16:50:31 -0400

From: "Elwell, John" <[email-masked]>

   "REQ-5 The mechanism must scale for large numbers of appearances, n,
      and large numbers of UAs, N, without introducing excessive messaging
      traffic."
   One consequence of a large N is, depending on solution, the establishment of
   N early dialogs towards the UAC and N parallel ICE procedures, N parallel
   key management procedures, etc.. This might not be important for values of N
   of the order of 3-5, but with much larger values of N this could certainly
   be a problem. I assume this requirement is intended to cover this and to
   include messages in general (such as STUN and whatever in-band key
   management is used) as well as SIP messaging.

And this is trickier than it first appears.  From a theoretical point
of view, the best that one could hope for is that the messaging scales
linearly with the number of appearances of the AOR.  And it seems that
we can achieve this without a problem.

But in practice, even scaling linearly is difficult to support, as the
calling UA is likely to have a small and fixed capacity for the number
of early dialogs it can negotiate at one time.

Dale

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: Alan Johnston <[email-masked]>
Date: Wed, 04 Apr 2007 11:26:53 -0500

Hi Martin,

I agree that an emergency call should override this behavior.  We can 
put in a note about that.

Thanks,
Alan

DOLLY, MARTIN C, ATTLABS wrote:
> Alan 
>
> Section 6.2 "Call Originated by a UA in a BLA group", the first
> paragraph states that "the UA just before allowing the user to place a
> call,
> shall send out a dialog event NOTIFY with state (trying). The User Agent
> MUST wait for a 200 OK response from the State Agent, before it proceeds
> with sending out the INVITE to the address entered by the end user."
> This
> places the State Agent in the critical path for whether or not a call
> goes
> through.  In a 911 scenario I don't know if we want to have a dependency
> on
> the responsiveness of the State Agent (which has to deal with many
> SUBSCRIBEs and NOTIFYs as per this draft) before a 911 call (or some
> other
> type of emergency call) can go through.  
>
> Cheers,
>
> Martin
>
>
>