Subject: [Speermint] Requirements draft comments (Section 2.3)

From: Daryl Malas <[email-masked]>
Date: Mon, 18 Sep 2006 09:16:40 -0600

I do not agree with this section.  A blocked call does not create a lot
of delay, if a 503 is sent immediately.  Operators do this every day
while trying to fill up least cost route choices.  This is a crankback
for route advancing to the next LCR.  The only time I can see this
causing a lot of delay is if the SF is not capable of responding because
it is overloaded.  This is different than blocking though.  Perhaps
simply changing the section title to something else??

--Daryl

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

---

From: "Geoff Devine" <[email-masked]>
Date: Mon, 18 Sep 2006 11:26:57 -0400

I believe "No blocked calls" is really "Avoid Blocked Calls"
 
The motiviation is to avoid inducing work in the network when resources are exhausted.  Call setup delay is a second order issue.
 
Geoff

________________________________

From: Daryl Malas [mailto:[email-masked]]
Sent: Mon 9/18/2006 11:16 AM
To: [email-masked]
Subject: [Speermint] Requirements draft comments (Section 2.3)

--Daryl

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 18 Sep 2006 17:56:32 +0200

> simply changing the section title to something else??

My aim with that section was the following:

You shouldn't send an INVITE packet to some other VSPs border element
unless you can tell beforehand that that VSPs is willing to take calls
from you at all (or even more fundamentally, talk SIP with you).

If he is filtering your INVITES at the IP or TLS layer than you'll not
get a 503 back in 20 msec, but a timeout some seconds later.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 18 Sep 2006 17:56:32 +0200

/ol