Hi, The main open issue in the 199 draft at the moment is when a UAS sends 199 - IF a UAS sends 199. The alternative proposals I have at the moment are described below (can also be found in the slides I was supposed to present yesterday). 1. UAS never sends 199: In this case only forking proxies/B2BUA would send 199. 2. UAS always sends 199: The issue with this alternative is that 199 would be sent even if no forking has occurred - which can be assumed to be the case in a large percentage of all calls. 3. UAS sends 199 if forking proxy does not support 199: With this alternative the forking proxy would have to insert an indicator that it supports 199. Also, the UAS mayFrom sip-bounces at ietf.org Tue Nov 18 11:17:36 2008 Return-Path: <sip-bounces at ietf.org> X-Original-To: sip-archive at optimus.ietf.org Delivered-To: ietfarch-sip-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324E03A6B0A; Tue, 18 Nov 2008 11:17:36 -0800 (PST) X-Original-To: sip at core3.amsl.com Delivered-To: sip at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD5B3A6A58 for <sip at core3.amsl.com>; Tue, 18 Nov 2008 11:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG2c+TaoHTcT for <sip at core3.amsl.com>; Tue, 18 Nov 2008 11:17:34 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 767463A6A13 for <sip at ietf.org>; Tue, 18 Nov 2008 11:17:32 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8D27420152 for <sip at ietf.org>; Tue, 18 Nov 2008 20:17:30 +0100 (CET) X-AuditID: c1b4fb3e-adf84bb00000537b-e1-492314ca3658 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 50E0E20133 for <sip at ietf.org>; Tue, 18 Nov 2008 20:17:30 +0100 (CET) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 20:17:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Nov 2008 20:17:29 +0100 Message-ID: <CA9998CD4A020D418654FCDEF4E707DF05C0F976 at esealmw113.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 199 Open Issue: UAS sending 199 thread-index: AclJskyM7I9+F6eVT6W1OajXQtDzMg=From: "Christer Holmberg" <christer.holmberg at ericsson.com> To: "IETF SIP List" <sip at ietf.org> X-OriginalArrivalTime: 18 Nov 2008 19:17:30.0241 (UTC) FILETIME=[4D0C0710:01C949B2] X-Brightmail-Tracker: AAAAAA=Subject: [Sip] 199 Open Issue: UAS sending 199 X-BeenThere: sip at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol <sip.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request at ietf.org?subject=unsubscribe> List-Post: <mailto:sip at ietf.org> List-Help: <mailto:sip-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request at ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="==============18928687==" Sender: sip-bounces at ietf.org Errors-To: sip-bounces at ietf.org This is a multi-part message in MIME format.Title: 199 Open Issue: UAS sending 199
Hi,
The main open issue in the 199 draft at the moment is when a UAS sends 199 - IF a UAS sends 199.
The alternative proposals I have at the moment are described below (can also be found in the slides I was supposed to present yesterday).
1. UAS never sends 199:
In this case only forking proxies/B2BUA would send 199.
2. UAS always sends 199:
The issue with this alternative is that 199 would be sent even if no forking has occurred - which can be assumed to be the case in a large percentage of all calls.
3. UAS sends 199 if forking proxy does not support 199:
With this alternative the forking proxy would have to insert an indicator that it supports 199.
Also, the UAS may not know whether it is the forking proxy closest to the UAS that has inserted the indicator. This may not be a big issues, since I assume in most forking cases there will only be one forking proxy in the signalling path.
4. UAS sends 199 once procedures have reached a certain state
With this alternative 199 would not be sent until certain actions have taken place on an early dialog
Example: preconditions have been indicated as met
Example: SDP answer has been sent
The issue is that one would always have to specify at what point of different procedures 199 would be sengt.
5. UAC and UAS negotiate sending of 199 once the early dialog has been established:
With this ah this alternative that UAC would tell the UAS that forking has occurred (could this be useful information also for non-199 procedures?), and that it wants 199 to be sent.
The issues with this alternative is that it may require additional signalling (unless PRACK/UPDATE won't be sent for other reasons) to inform the UAS that forking has occurred.
Other alternatives?
NOTE: Robert S also raised an issue on what Require: 199 means. But, I think that outcome of that issue may depend on what way forward we choose for the issue in this mail.
Regards,
Christer
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip