Re: [BLISS] draft-ietf-bliss-call-completion-18

"Anton Tveretin" <> Sun, 30 December 2012 22:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0304721F8B30 for <>; Sun, 30 Dec 2012 14:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 4.253
X-Spam-Level: ****
X-Spam-Status: No, score=4.253 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, FAKE_REPLY_C=2.012, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, RCVD_IN_SORBS_WEB=0.619, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bd+TcWUsGCYY for <>; Sun, 30 Dec 2012 14:40:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 414AE21F8B28 for <>; Sun, 30 Dec 2012 14:40:51 -0800 (PST)
Received: by (Postfix, from userid 1116) id 5E8B9515F1F; Mon, 31 Dec 2012 04:39:03 +0600 (YEKT)
Received: from Gateway (unknown []) by (Postfix) with ESMTPA id 47E1C51459F for <>; Mon, 31 Dec 2012 04:39:00 +0600 (YEKT)
Message-ID: <69B8A685D1FE4D8BB2953BECCE62F574@Gateway>
From: "Anton Tveretin" <>
To: <>
Date: Mon, 31 Dec 2012 04:40:24 +0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Antivirus: avast! (VPS 121230-0, 30.12.2012), Outbound message
X-Antivirus-Status: Clean
Subject: Re: [BLISS] draft-ietf-bliss-call-completion-18
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Dec 2012 22:40:52 -0000

Hello All,
I think that "busy" state (as oppesed to "free" state) is not something
absolute. It means "out of resources" but different calls have different
resource requirements. A user might be busy to answer a voice call, but fax
could be received automatically. A private network with narrowband link
might accept just few video calls, yet might more voice calls.
Therefore, we should place enough information, preferrably the entire SDP,
into subscription (SUBSCRIBE request).
Suggestion: 9.3: add,
"The SUBSCRIBE body MUST contain the original session description, to
provide information about resource requirements."
This could be reproduced in Section 5, somewhat like "There are effectively
several queues for calls with different resource requirements".

12.2 Why is it application/call-completion, not text/call-completion?
Shouldn't charset appear explicitly? I'm afraid of different encoding
problems... This MIME type is also more compact.

What is about interoperability with RFC 4235? There is none, but IMO this
should be explicitly stated somewhere. E.g. in 6.1 or 6.2, "Caller MUST try
this procedure first, and if the "call-completion" event package is
unsupported, it may attempt complete the call as in RFC 4235".

Sorry for being away too long (and cross-posting, if any).

Anton Tveretin