From bliss-bounces@ietf.org Fri Aug 17 09:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM1WN-0003pt-5L; Fri, 17 Aug 2007 09:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM1WK-0003gY-9C for bliss@ietf.org; Fri, 17 Aug 2007 09:05:44 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM1WI-0003W1-KN for bliss@ietf.org; Fri, 17 Aug 2007 09:05:44 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP for bliss@ietf.org; Fri, 17 Aug 2007 15:05:35 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Aug 2007 15:05:34 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 17 Aug 2007 15:05:34 +0200 Message-Id: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of Warning: header to transport additional status indications Thread-Index: Acfgz0qJmh+ZCDEyT/Kj3qo6JgYoCQ== From: "Alexeitsev, D" To: X-OriginalArrivalTime: 17 Aug 2007 13:05:34.0602 (UTC) FILETIME=[4C487EA0:01C7E0CF] X-Spam-Score: -1.0 (-) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Subject: [BLISS] Use of Warning: header to transport additional status indications X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1763295491==" Errors-To: bliss-bounces@ietf.org This is a multi-part message in MIME format. --===============1763295491== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E0CF.4C11FD4D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E0CF.4C11FD4D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In several use cases there is a need to provide additional information about the status of the call or the activation of some additional services. For example in GSM and ISDN networks a common service is to provide calling party a reminder that the call diversion is activated for his line (A-party). This should not be mistake with the idication that the call diversion is taking place at the (B-Party). Another example is an indication for the A-Party, that the call-waiting procedure is taking place on the B-Party side. This indications are transmitted during call-establishment phase. A proposal is to reuse the Warning: header by extanding the warn-code with the values reflecting the described cases. The spare volumes of warn codes at the moment are 340-369 and 390-399, so the following new warn codes can be defined: Warning: 341 isi.edu "Call is a waiting call" Warning: 342 isi.edu "Diversion activated" The procedure at the SIP proxy is then to include the Warning: Header in to the 180 Ringing or 183 Session Progress response to provide the required indication to the A-Party.=20 SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=3Dz9hG4bK4b43c2ff8.1 To: Bob ;tag=3Da6c85cf From: Alice ;tag=3D1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Warning: 342 atlanta.com "Diversion activated" Content-Length: 0 Alice receives the idication from her home proxy atlanta.com that the diversion service is active for her URI. SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=3Dz9hG4bK4b43c2ff8.1 To: Bob ;tag=3Da6c85cf From: Alice ;tag=3D1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Warning: 341 biloxy.com "Call is a waiting call" Content-Length: 0 Alice receives the idication from the Bob's proxy biloxy.com that her call is in call-waiting mode on the Bob's side. Any comments question? Greetings, Denis Alexeitsev ------_=_NextPart_001_01C7E0CF.4C11FD4D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Use of Warning: header to transport additional status = indications

In several use cases there is a need to = provide additional information about the status of the call or the = activation of some additional services.

For example in GSM and ISDN networks a = common service is to provide calling party a reminder that the call = diversion is activated for his line (A-party). This should not be = mistake with the idication that the call diversion is taking place at = the (B-Party).

Another example is an indication for = the A-Party, that the call-waiting procedure is taking place on the = B-Party side.

This indications are transmitted during = call-establishment phase.

A proposal is to reuse the Warning: = header by extanding the warn-code with the values reflecting the = described cases. The spare volumes of warn codes at the moment are = 340-369 and 390-399, so the following new warn codes can be = defined:

Warning: 341 isi.edu "Call is a = waiting call"
Warning: 342 isi.edu "Diversion = activated"

The procedure at the = SIP proxy is then to include the Warning: Header in to the 180 Ringing = or 183 Session Progress response to provide the required indication to = the A-Party.

SIP/2.0 180 = Ringing
Via: SIP/2.0/UDP = server10.biloxi.com;branch=3Dz9hG4bK4b43c2ff8.1
To: Bob = <sip:bob@biloxi.com>;tag=3Da6c85cf
From: Alice = <sip:alice@atlanta.com>;tag=3D1928301774
Call-ID: = a84b4c76e66710
Contact: = <sip:bob@192.0.2.4>
CSeq: 314159 = INVITE
Warning: 342 = atlanta.com "Diversion activated"
Content-Length: = 0

Alice receives the = idication from her home proxy atlanta.com that the diversion service is = active for her URI.

SIP/2.0 180 = Ringing
Via: SIP/2.0/UDP = server10.biloxi.com;branch=3Dz9hG4bK4b43c2ff8.1
To: Bob = <sip:bob@biloxi.com>;tag=3Da6c85cf
From: Alice = <sip:alice@atlanta.com>;tag=3D1928301774
Call-ID: = a84b4c76e66710
Contact: = <sip:bob@192.0.2.4>
CSeq: 314159 = INVITE
Warning: 341 = biloxy.com "Call is a waiting call"
Content-Length: = 0

Alice receives the = idication from the Bob's proxy biloxy.com that her call is in = call-waiting mode on the Bob's side.

Any comments = question?

Greetings,
Denis = Alexeitsev

------_=_NextPart_001_01C7E0CF.4C11FD4D-- --===============1763295491== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============1763295491==-- From bliss-bounces@ietf.org Fri Aug 17 09:39:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM22w-0002w8-Mt; Fri, 17 Aug 2007 09:39:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM22v-0002w1-2r for bliss@ietf.org; Fri, 17 Aug 2007 09:39:25 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM22t-0004Ng-FQ for bliss@ietf.org; Fri, 17 Aug 2007 09:39:25 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JMX00L4X783IR@siemenscomms.co.uk> for bliss@ietf.org; Fri, 17 Aug 2007 14:38:27 +0100 (BST) Date: Fri, 17 Aug 2007 14:38:43 +0100 From: "Elwell, John" Subject: RE: [BLISS] Use of Warning: header to transport additional statusindications In-reply-to: To: "Alexeitsev, D" , bliss@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Thread-Topic: [BLISS] Use of Warning: header to transport additional statusindications Thread-Index: Acfgz0qJmh+ZCDEyT/Kj3qo6JgYoCQAAuzgw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1765607698==" Errors-To: bliss-bounces@ietf.org This is a multi-part message in MIME format. --===============1765607698== Content-type: multipart/alternative; boundary="Boundary_(ID_vF0fahYdWqSdOb8x8xA0Jw)" Content-class: urn:content-classes:message This is a multi-part message in MIME format. --Boundary_(ID_vF0fahYdWqSdOb8x8xA0Jw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Denis, See below. John ________________________________ From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] Sent: 17 August 2007 14:06 To: bliss@ietf.org Subject: [BLISS] Use of Warning: header to transport additional statusindications In several use cases there is a need to provide additional information about the status of the call or the activation of some additional services. For example in GSM and ISDN networks a common service is to provide calling party a reminder that the call diversion is activated for his line (A-party). This should not be mistake with the idication that the call diversion is taking place at the (B-Party). Another example is an indication for the A-Party, that the call-waiting procedure is taking place on the B-Party side. [JRE] I think these are quite different problems that merit different solutions. This indications are transmitted during call-establishment phase. [JRE] I understand why a user may wish to receive notifications that call diversion is active, but I fail to see why this should be synchronised with that user's attempts to establish calls. It seems to me that the SIP event framework would be ideally suited to this. A UA could subscribe to an event package, and any information related to the way incoming calls are handled at the proxy (not merely a simple indication that diversion is active) could be provided in notifications. I see this as part of the automated call handling topic in BLISS, so I will add it to my list of things to consider. A proposal is to reuse the Warning: header by extanding the warn-code with the values reflecting the described cases. The spare volumes of warn codes at the moment are 340-369 and 390-399, so the following new warn codes can be defined: Warning: 341 isi.edu "Call is a waiting call" [JRE] Why is the 182 Queued response insufficient? Warning: 342 isi.edu "Diversion activated" The procedure at the SIP proxy is then to include the Warning: Header in to the 180 Ringing or 183 Session Progress response to provide the required indication to the A-Party. [JRE] Why would a proxy need to do anything for call waiting? Call waiting is a function of the called UA, which would generate the necessary indication (182 response, in my opinion) when appropriate. How would the proxy be in a position to be able to generate such information? SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Warning: 342 atlanta.com "Diversion activated" Content-Length: 0 Alice receives the idication from her home proxy atlanta.com that the diversion service is active for her URI. SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Warning: 341 biloxy.com "Call is a waiting call" Content-Length: 0 Alice receives the idication from the Bob's proxy biloxy.com that her call is in call-waiting mode on the Bob's side. Any comments question? [JRE] So no, I don't see that warn codes are appropriate for either of these two cases. Greetings, Denis Alexeitsev --Boundary_(ID_vF0fahYdWqSdOb8x8xA0Jw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Use of Warning: header to transport additional status indications
Denis,
 
See below.
 
John

From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]
Sent: 17 August 2007 14:06
To: bliss@ietf.org
Subject: [BLISS] Use of Warning: header to transport additional statusindications


In several use cases there is a need to provide additional information about the status of the call or the activation of some additional services.

For example in GSM and ISDN networks a common service is to provide calling party a reminder that the call diversion is activated for his line (A-party). This should not be mistake with the idication that the call diversion is taking place at the (B-Party).

Another example is an indication for the A-Party, that the call-waiting procedure is taking place on the B-Party side.
[JRE] I think these are quite different problems that merit different solutions. 

This indications are transmitted during call-establishment phase.
[JRE] I understand why a user may wish to receive notifications that call diversion is active, but I fail to see why this should be synchronised with that user's attempts to establish calls. It seems to me that the SIP event framework would be ideally suited to this. A UA could subscribe to an event package, and any information related to the way incoming calls are handled at the proxy (not merely a simple indication that diversion is active) could be provided in notifications. I see this as part of the automated call handling topic in BLISS, so I will add it to my list of things to consider. 

A proposal is to reuse the Warning: header by extanding the warn-code with the values reflecting the described cases. The spare volumes of warn codes at the moment are 340-369 and 390-399, so the following new warn codes can be defined:

Warning: 341 isi.edu "Call is a waiting call"
[JRE] Why is the 182 Queued response insufficient?
Warning: 342 isi.edu "Diversion activated"

The procedure at the SIP proxy is then to include the Warning: Header in to the 180 Ringing or 183 Session Progress response to provide the required indication to the A-Party.
[JRE] Why would a proxy need to do anything for call waiting? Call waiting is a function of the called UA, which would generate the necessary indication (182 response, in my opinion) when appropriate. How would the proxy be in a position to be able to generate such information?

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Warning: 342 atlanta.com "Diversion activated"
Content-Length: 0

Alice receives the idication from her home proxy atlanta.com that the diversion service is active for her URI.

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Warning: 341 biloxy.com "Call is a waiting call"
Content-Length: 0

Alice receives the idication from the Bob's proxy biloxy.com that her call is in call-waiting mode on the Bob's side.

Any comments question?
[JRE] So no, I don't see that warn codes are appropriate for either of these two cases. 

Greetings,
Denis Alexeitsev

--Boundary_(ID_vF0fahYdWqSdOb8x8xA0Jw)-- --===============1765607698== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============1765607698==-- From bliss-bounces@ietf.org Fri Aug 17 10:13:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM2Zf-0003bZ-LT; Fri, 17 Aug 2007 10:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM2Ze-0003bU-Gi for bliss@ietf.org; Fri, 17 Aug 2007 10:13:14 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM2Zc-0005Fb-SB for bliss@ietf.org; Fri, 17 Aug 2007 10:13:14 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Fri, 17 Aug 2007 16:13:11 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Aug 2007 16:13:11 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] Use of Warning: header to transport additionalstatusindications Date: Fri, 17 Aug 2007 16:13:10 +0200 Message-Id: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additionalstatusindications Thread-Index: Acfgz0qJmh+ZCDEyT/Kj3qo6JgYoCQAAuzgwAAEGhvA= From: "Alexeitsev, D" To: X-OriginalArrivalTime: 17 Aug 2007 14:13:11.0263 (UTC) FILETIME=[BE3DD6F0:01C7E0D8] X-Spam-Score: -1.0 (-) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0571704744==" Errors-To: bliss-bounces@ietf.org This is a multi-part message in MIME format. --===============0571704744== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E0D8.BDE9FFD9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E0D8.BDE9FFD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello John =20 Thanks for the comments, responses inline.=20 =20 This indications are transmitted during call-establishment phase.=20 [JRE] I understand why a user may wish to receive notifications that call diversion is active, but I fail to see why this should be synchronised with that user's attempts to establish calls. It seems to me that the SIP event framework would be ideally suited to this. A UA could subscribe to an event package, and any information related to the way incoming calls are handled at the proxy (not merely a simple indication that diversion is active) could be provided in notifications. I see this as part of the automated call handling topic in BLISS, so I will add it to my list of things to consider. =20 =20 [DA] I think using event framework would be an overkill for such simple indication and Warning header even literary fits well for this case as a reminder. In addition the interworking with ISDN/GSM would be way to complicated if unbundled from the call establishment state. A proposal is to reuse the Warning: header by extanding the warn-code with the values reflecting the described cases. The spare volumes of warn codes at the moment are 340-369 and 390-399, so the following new warn codes can be defined: Warning: 341 isi.edu "Call is a waiting call"=20 [JRE] Why is the 182 Queued response insufficient?=20 [DA] It is not exactly the same as queued, because the B-party receives the session setup request, but with indication that the resources shall be made available in order to establish the session. In queued case the session in not presented to the B-party but queued by some instance before. =20 Warning: 342 isi.edu "Diversion activated"=20 The procedure at the SIP proxy is then to include the Warning: Header in to the 180 Ringing or 183 Session Progress response to provide the required indication to the A-Party.=20 [JRE] Why would a proxy need to do anything for call waiting? Call waiting is a function of the called UA, which would generate the necessary indication (182 response, in my opinion) when appropriate. How would the proxy be in a position to be able to generate such information? [DA]The reasoning behind it is that network might limit the number of simultaneous sessions, that can be established with a specific URI. In this case an incoming call to the URI that has already reached the maximum number of simultaneous sessions would fall in to the call-waiting state. For this scenario an indication is needed to the A-party that is it not just normal ringing but call-waiting case. Greetings, Denis Alexeitsev ------_=_NextPart_001_01C7E0D8.BDE9FFD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nachricht
Hello=20 John
 
Thanks=20 for the comments, responses inline. 
 
 This indications are transmitted = during=20 call-establishment phase.
[JRE] I = understand why a user=20 may wish to receive notifications that call diversion is active, = but I fail=20 to see why this should be synchronised with that user's attempts to = establish=20 calls. It seems to me that the SIP event framework would be ideally = suited=20 to this. A UA could subscribe to an event package, and = any=20 information related to the way incoming calls are handled at the proxy = (not=20 merely a simple indication that diversion is active) could be provided = in=20 notifications. I see this as part of the automated call handling topic = in BLISS,=20 so I will add it to my list of things to consider.  
 
[DA] I think using event = framework would=20 be an overkill for such simple indication and Warning header even = literary fits=20 well for this case as a = reminder. In addition the interworking with = ISDN/GSM would=20 be way to complicated if unbundled from the call establishment=20 state.

A proposal is to reuse the Warning: = header by=20 extanding the warn-code with the values reflecting the described = cases. The=20 spare volumes of warn codes at the moment are 340-369 and 390-399, = so the=20 following new warn codes can be defined:

Warning: 341 isi.edu "Call is a = waiting=20 call"
[JRE] Why is the 182 Queued=20 response insufficient? 

[DA] It is not exactly the = same as=20 queued, because the B-party receives the session setup request, but = with=20 indication that the resources shall be made available in order to = establish=20 the session. In queued case the session in not presented to the = B-party but=20 queued by some instance = before.

 
<= FONT=20 face=3DArial size=3D2>Warning: 342 isi.edu "Diversion = activated"

The procedure = at the SIP=20 proxy is then to include the Warning: Header in to the 180 Ringing = or 183=20 Session Progress response to provide the required indication to the = A-Party.=20
[JRE] Why would=20 a proxy need to do anything for call waiting? Call waiting is a = function of=20 the called UA, which would generate the necessary indication (182 = response,=20 in my opinion) when appropriate. How would the proxy be in a = position=20 to be able to generate such=20 information?

[DA]The reasoning behind it is that = network might=20 limit the number of simultaneous sessions, that can be established = with a=20 specific URI. In this case an incoming call to the URI that has = already=20 reached the maximum number of simultaneous sessions would fall = in to=20 the call-waiting state. For this scenario an indication is needed to = the=20 A-party that is it not just normal ringing but call-waiting=20 case.

Greetings,

Denis=20 Alexeitsev

------_=_NextPart_001_01C7E0D8.BDE9FFD9-- --===============0571704744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss --===============0571704744==-- From bliss-bounces@ietf.org Fri Aug 17 10:31:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM2re-00011c-GU; Fri, 17 Aug 2007 10:31:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM2re-00011X-3q for bliss@ietf.org; Fri, 17 Aug 2007 10:31:50 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM2rc-0005ae-OR for bliss@ietf.org; Fri, 17 Aug 2007 10:31:50 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l7HEVldP022814; Fri, 17 Aug 2007 09:31:47 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 09:31:11 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 16:30:48 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transportadditionalstatusindications Date: Fri, 17 Aug 2007 16:30:46 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180015AEADC@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transportadditionalstatusindications Thread-Index: Acfgz0qJmh+ZCDEyT/Kj3qo6JgYoCQAAuzgwAAEGhvAAALIQIA== References: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> From: "DRAGE, Keith \(Keith\)" To: "Alexeitsev, D" , X-OriginalArrivalTime: 17 Aug 2007 14:30:48.0127 (UTC) FILETIME=[342E7CF0:01C7E0DB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org This indications are transmitted during call-establishment phase.=20 [JRE] I understand why a user may wish to receive notifications that call diversion is active, but I fail to see why this should be synchronised with that user's attempts to establish calls. It seems to me that the SIP event framework would be ideally suited to this. A UA could subscribe to an event package, and any information related to the way incoming calls are handled at the proxy (not merely a simple indication that diversion is active) could be provided in notifications. I see this as part of the automated call handling topic in BLISS, so I will add it to my list of things to consider. =20 =20 [DA] I think using event framework would be an overkill for such simple indication and Warning header even literary fits well for this case as a reminder. In addition the interworking with ISDN/GSM would be way to complicated if unbundled from the call establishment state.=20 [KED} These indications that diversion is active are equivalent to the old black phone equivalent of giving special dial tone when diversion is active and so on. When they were discussed in the evolution of the ISDN, they were regarded as part of the stimulus protocol rather than the functional protocol. Therefore no ISDN functional protocol was ever defined for them (at least I cannot see anything in ETSI EN 300 207-1 V3.1.1 (2001-06) which is the latest version of the DSS1 protocol document, and for which there should be a direct ITU-T equivalent.=20 Rather, some stimulus indication can be given, such as a tone or announcement. Now there have been extensive discussions in the past on stimulus versus functional in SIP... Regards Keith ________________________________ From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 Sent: Friday, August 17, 2007 3:13 PM To: bliss@ietf.org Subject: AW: [BLISS] Use of Warning: header to transportadditionalstatusindications =09 =09 Hello John =20 Thanks for the comments, responses inline.=20 =20 This indications are transmitted during call-establishment phase.=20 [JRE] I understand why a user may wish to receive notifications that call diversion is active, but I fail to see why this should be synchronised with that user's attempts to establish calls. It seems to me that the SIP event framework would be ideally suited to this. A UA could subscribe to an event package, and any information related to the way incoming calls are handled at the proxy (not merely a simple indication that diversion is active) could be provided in notifications. I see this as part of the automated call handling topic in BLISS, so I will add it to my list of things to consider. =20 =20 [DA] I think using event framework would be an overkill for such simple indication and Warning header even literary fits well for this case as a reminder. In addition the interworking with ISDN/GSM would be way to complicated if unbundled from the call establishment state. A proposal is to reuse the Warning: header by extanding the warn-code with the values reflecting the described cases. The spare volumes of warn codes at the moment are 340-369 and 390-399, so the following new warn codes can be defined: Warning: 341 isi.edu "Call is a waiting call"=20 [JRE] Why is the 182 Queued response insufficient?=20 [DA] It is not exactly the same as queued, because the B-party receives the session setup request, but with indication that the resources shall be made available in order to establish the session. In queued case the session in not presented to the B-party but queued by some instance before. =09 Warning: 342 isi.edu "Diversion activated"=20 The procedure at the SIP proxy is then to include the Warning: Header in to the 180 Ringing or 183 Session Progress response to provide the required indication to the A-Party.=20 [JRE] Why would a proxy need to do anything for call waiting? Call waiting is a function of the called UA, which would generate the necessary indication (182 response, in my opinion) when appropriate. How would the proxy be in a position to be able to generate such information? [DA]The reasoning behind it is that network might limit the number of simultaneous sessions, that can be established with a specific URI. In this case an incoming call to the URI that has already reached the maximum number of simultaneous sessions would fall in to the call-waiting state. For this scenario an indication is needed to the A-party that is it not just normal ringing but call-waiting case. Greetings, Denis Alexeitsev _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 17 11:06:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3Ow-0002Ub-JV; Fri, 17 Aug 2007 11:06:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3Ov-0002UV-2F for bliss@ietf.org; Fri, 17 Aug 2007 11:06:13 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM3Ou-0001qZ-3k for bliss@ietf.org; Fri, 17 Aug 2007 11:06:12 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JMX00J6ZB5MT8@siemenscomms.co.uk> for bliss@ietf.org; Fri, 17 Aug 2007 16:03:22 +0100 (BST) Date: Fri, 17 Aug 2007 16:03:37 +0100 From: "Elwell, John" Subject: RE: [BLISS] Use of Warning: header to transport additionalstatusindications In-reply-to: To: "Alexeitsev, D" , bliss@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026F299@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [BLISS] Use of Warning: header to transport additionalstatusindications Thread-Index: Acfgz0qJmh+ZCDEyT/Kj3qo6JgYoCQAAuzgwAAEGhvAAAQSDYA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Denis, More below. John > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] > Sent: 17 August 2007 15:13 > To: bliss@ietf.org > Cc: Elwell, John > Subject: AW: [BLISS] Use of Warning: header to transport > additionalstatusindications > > Hello John > > Thanks for the comments, responses inline. > > This indications are transmitted during call-establishment phase. > [JRE] I understand why a user may wish to receive > notifications that call diversion is active, but I fail to > see why this should be synchronised with that user's attempts > to establish calls. It seems to me that the SIP event > framework would be ideally suited to this. A UA could > subscribe to an event package, and any information related to > the way incoming calls are handled at the proxy (not merely a > simple indication that diversion is active) could be provided > in notifications. I see this as part of the automated call > handling topic in BLISS, so I will add it to my list of > things to consider. > > [DA] I think using event framework would be an overkill for > such simple indication and Warning header even literary fits > well for this case as a reminder. In addition the > interworking with ISDN/GSM would be way to complicated if > unbundled from the call establishment state. [JRE] I don't see how it is needed for interworking with ISDN/GSM networks, because your proposal is only between a calling user's proxy and the calling user's UA. The only case I can think of is where the calling UA is actually an adaptor to an ISDN or GSM phone. I must admit I forget whether there is Q.931 signalling for this to an ISDN phone and I don't know what provision there is for a GSM phone. I am doubtful about the wisdom of assigning SIP codepoints for such specific interworking purposes, particularly when it only satisfies a small subset of a potentially bigger problem space of more general applicability. Let's see what others think. > > A proposal is to reuse the Warning: header by > extanding the warn-code with the values reflecting the > described cases. The spare volumes of warn codes at the > moment are 340-369 and 390-399, so the following new warn > codes can be defined: > > Warning: 341 isi.edu "Call is a waiting call" > [JRE] Why is the 182 Queued response insufficient? > > [DA] It is not exactly the same as queued, > because the B-party receives the session setup request, but > with indication that the resources shall be made available in > order to establish the session. In queued case the session in > not presented to the B-party but queued by some instance before. [JRE] I see nothing in the definition of 182 Queued in RFC 3263 to say that the session is not presented to the B-party. This is just a user interface matter, and I would imagine, for both queued and call waiting, the B-party would be given some indication as to the presence of the queued or waiting call. In other words, I fail to see the difference. > > > Warning: 342 isi.edu "Diversion activated" > > The procedure at the SIP proxy is then to > include the Warning: Header in to the 180 Ringing or 183 > Session Progress response to provide the required indication > to the A-Party. > [JRE] Why would a proxy need to do anything for > call waiting? Call waiting is a function of the called UA, > which would generate the necessary indication (182 response, > in my opinion) when appropriate. How would the proxy be in a > position to be able to generate such information? > > [DA]The reasoning behind it is that network > might limit the number of simultaneous sessions, that can be > established with a specific URI. In this case an incoming > call to the URI that has already reached the maximum number > of simultaneous sessions would fall in to the call-waiting > state. [JRE] I don't see it this way. If the called UA is busy on one session, and a further INVITE request arrives that cannot be processed normally because resources are occupied by the existing session, then that is exactly the situation where the UA might apply call waiting (according to policy dictated by the user) and send back a 182 response. So in other words, we get to the call waiting state without exceeding any network limit to the number of sessions - only the UA limit to the number of active sessions has been exceeded, which is typically 1 (although could well be more for message sessions, for example, or if join is requested). I think what you are talking about here is the case where the "network" (the inbound proxy) has a policy to limit the number of sessions at the UA (including those in call waiting state), and that any further sessions establishment requests beyond this limit also be given call waiting state, but not by the UA. That could certainly be done, and in effect the proxy would forward any further INVITE requests to an alternative UA (which could be collocated with the proxy) that would queue the requests and send back 182. However, I see two difficulties with this. How is the user advised of these additional queued requests? How do they eventually get answered? Presumably the proxy has to somehow know when the normal UA has resources to accept further requests, and then cancel them from the alternative UA and forward them to the normal UA. It all seems rather complicated and all it seems to do is save some resources at the normal called UA. Shouldn't it be a matter for the called UA to decide how many it can accept, and then deal with any additional INVITE requests appropriately, e.g., reject or redirect to an alternative answering point? > For this scenario an indication is needed to the > A-party that is it not just normal ringing but call-waiting case. [JRE] Why does the calling user need to be aware of this subtle difference between waiting at the called UA and waiting at an alternative UA somehow closely associated with the proxy? > > Greetings, > > Denis Alexeitsev > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 17 11:39:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3vU-0006Ce-IL; Fri, 17 Aug 2007 11:39:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM3vT-00067V-7Y for bliss@ietf.org; Fri, 17 Aug 2007 11:39:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM3vR-0008Lr-Qp for bliss@ietf.org; Fri, 17 Aug 2007 11:39:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Aug 2007 11:39:50 -0400 X-IronPort-AV: i="4.19,275,1183348800"; d="scan'208"; a="129152183:sNHT60977638" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7HFdnU1010000; Fri, 17 Aug 2007 11:39:49 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7HFdmja014534; Fri, 17 Aug 2007 15:39:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 11:39:48 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 11:39:47 -0400 Message-ID: <46C5C144.20708@cisco.com> Date: Fri, 17 Aug 2007 11:39:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] Use of Warning: header to transport additionalstatusindications References: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D026F299@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026F299@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2007 15:39:47.0710 (UTC) FILETIME=[D790B9E0:01C7E0E4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7509; t=1187365189; x=1188229189; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Use=20of=20Warning=3A=20header=20to=20trans port=09additionalstatusindications |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=woGguntvHlSD2g9d9npY228F543gM6zRYC1NpJaXgbo=; b=ljWQyf9NNQOPKnpgD8DXqe8DGZgkSv9t1L+5ztfI5H91VqSAXJmbfY3acj0oaSM2nZe3i8st Fmnj2I6KfuBYq5+LVwmvQUUU/Mn21gzPvAeKO31YtrLHT8uewOOa8TZF; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org The 182 Queued response may be a little underspecified. Its far from clear to me that it is appropriate in the call waiting case. I fail to see any significant difference between call waiting and a phone with two lines for the same number. And little difference between that and two phones registered for the same number and sitting on the same desk in front of a single person. In all of these cases, when the second call comes in the callee is alerted, and has the option of answering the call. The callee may need to do something before answering the phone - put a different call on hold, put down his cup of coffee, or whatever. In all these cases why isn't 180 the appropriate response? Why should I expect to get some special call waiting status if it is a phone with "call waiting" service and another call active, while not if it is a phone with two "lines", or two phones on one desk? If I am implementing a phone, how do I decide whether to return "call waiting" status? Paul Elwell, John wrote: > Denis, > > More below. > > John > >> -----Original Message----- >> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] >> Sent: 17 August 2007 15:13 >> To: bliss@ietf.org >> Cc: Elwell, John >> Subject: AW: [BLISS] Use of Warning: header to transport >> additionalstatusindications >> >> Hello John >> >> Thanks for the comments, responses inline. >> >> This indications are transmitted during call-establishment phase. >> [JRE] I understand why a user may wish to receive >> notifications that call diversion is active, but I fail to >> see why this should be synchronised with that user's attempts >> to establish calls. It seems to me that the SIP event >> framework would be ideally suited to this. A UA could >> subscribe to an event package, and any information related to >> the way incoming calls are handled at the proxy (not merely a >> simple indication that diversion is active) could be provided >> in notifications. I see this as part of the automated call >> handling topic in BLISS, so I will add it to my list of >> things to consider. >> >> [DA] I think using event framework would be an overkill for >> such simple indication and Warning header even literary fits >> well for this case as a reminder. In addition the >> interworking with ISDN/GSM would be way to complicated if >> unbundled from the call establishment state. > [JRE] I don't see how it is needed for interworking with ISDN/GSM > networks, because your proposal is only between a calling user's proxy > and the calling user's UA. The only case I can think of is where the > calling UA is actually an adaptor to an ISDN or GSM phone. I must admit > I forget whether there is Q.931 signalling for this to an ISDN phone and > I don't know what provision there is for a GSM phone. I am doubtful > about the wisdom of assigning SIP codepoints for such specific > interworking purposes, particularly when it only satisfies a small > subset of a potentially bigger problem space of more general > applicability. Let's see what others think. > >> A proposal is to reuse the Warning: header by >> extanding the warn-code with the values reflecting the >> described cases. The spare volumes of warn codes at the >> moment are 340-369 and 390-399, so the following new warn >> codes can be defined: >> >> Warning: 341 isi.edu "Call is a waiting call" >> [JRE] Why is the 182 Queued response insufficient? >> >> [DA] It is not exactly the same as queued, >> because the B-party receives the session setup request, but >> with indication that the resources shall be made available in >> order to establish the session. In queued case the session in >> not presented to the B-party but queued by some instance before. > [JRE] I see nothing in the definition of 182 Queued in RFC 3263 to say > that the session is not presented to the B-party. This is just a user > interface matter, and I would imagine, for both queued and call waiting, > the B-party would be given some indication as to the presence of the > queued or waiting call. In other words, I fail to see the difference. > >> >> Warning: 342 isi.edu "Diversion activated" >> >> The procedure at the SIP proxy is then to >> include the Warning: Header in to the 180 Ringing or 183 >> Session Progress response to provide the required indication >> to the A-Party. >> [JRE] Why would a proxy need to do anything for >> call waiting? Call waiting is a function of the called UA, >> which would generate the necessary indication (182 response, >> in my opinion) when appropriate. How would the proxy be in a >> position to be able to generate such information? >> >> [DA]The reasoning behind it is that network >> might limit the number of simultaneous sessions, that can be >> established with a specific URI. In this case an incoming >> call to the URI that has already reached the maximum number >> of simultaneous sessions would fall in to the call-waiting >> state. > [JRE] I don't see it this way. If the called UA is busy on one session, > and a further INVITE request arrives that cannot be processed normally > because resources are occupied by the existing session, then that is > exactly the situation where the UA might apply call waiting (according > to policy dictated by the user) and send back a 182 response. So in > other words, we get to the call waiting state without exceeding any > network limit to the number of sessions - only the UA limit to the > number of active sessions has been exceeded, which is typically 1 > (although could well be more for message sessions, for example, or if > join is requested). > I think what you are talking about here is the case where the "network" > (the inbound proxy) has a policy to limit the number of sessions at the > UA (including those in call waiting state), and that any further > sessions establishment requests beyond this limit also be given call > waiting state, but not by the UA. That could certainly be done, and in > effect the proxy would forward any further INVITE requests to an > alternative UA (which could be collocated with the proxy) that would > queue the requests and send back 182. However, I see two difficulties > with this. How is the user advised of these additional queued requests? > How do they eventually get answered? Presumably the proxy has to somehow > know when the normal UA has resources to accept further requests, and > then cancel them from the alternative UA and forward them to the normal > UA. It all seems rather complicated and all it seems to do is save some > resources at the normal called UA. Shouldn't it be a matter for the > called UA to decide how many it can accept, and then deal with any > additional INVITE requests appropriately, e.g., reject or redirect to an > alternative answering point? > >> For this scenario an indication is needed to the >> A-party that is it not just normal ringing but call-waiting case. > [JRE] Why does the calling user need to be aware of this subtle > difference between waiting at the called UA and waiting at an > alternative UA somehow closely associated with the proxy? > > >> Greetings, >> >> Denis Alexeitsev >> >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 17 12:05:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4Jo-0003LL-W3; Fri, 17 Aug 2007 12:05:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM4Jn-0003LB-6O for bliss@ietf.org; Fri, 17 Aug 2007 12:04:59 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM4Jl-0000dF-I3 for bliss@ietf.org; Fri, 17 Aug 2007 12:04:59 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JMX00B9BDZSFI@siemenscomms.co.uk> for bliss@ietf.org; Fri, 17 Aug 2007 17:04:40 +0100 (BST) Date: Fri, 17 Aug 2007 17:04:55 +0100 From: "Elwell, John" Subject: RE: [BLISS] Use of Warning: header to transportadditionalstatusindications In-reply-to: <46C5C144.20708@cisco.com> To: Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026F2B3@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [BLISS] Use of Warning: header to transportadditionalstatusindications Thread-Index: Acfg5SnNeKwCLI8iQYWEMar0YIXT8gAAvWuw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D026F299@GBNTHT12009MSX.gb002.siemens.net> <46C5C144.20708@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Paul, I agree that the called UA could choose to send 180, but I think 182 is equally valid. However, my point really was that I don't see the need for anything beyond what is already in RFC 3261 for call waiting. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 17 August 2007 16:40 > To: Elwell, John > Cc: Alexeitsev, D; bliss@ietf.org > Subject: Re: [BLISS] Use of Warning: header to > transportadditionalstatusindications > > The 182 Queued response may be a little underspecified. > Its far from clear to me that it is appropriate in the call > waiting case. > > I fail to see any significant difference between call waiting and a > phone with two lines for the same number. And little > difference between > that and two phones registered for the same number and sitting on the > same desk in front of a single person. > > In all of these cases, when the second call comes in the callee is > alerted, and has the option of answering the call. The callee > may need > to do something before answering the phone - put a different call on > hold, put down his cup of coffee, or whatever. In all these cases why > isn't 180 the appropriate response? > > Why should I expect to get some special call waiting status > if it is a > phone with "call waiting" service and another call active, > while not if > it is a phone with two "lines", or two phones on one desk? > > If I am implementing a phone, how do I decide whether to return "call > waiting" status? > > Paul > > Elwell, John wrote: > > Denis, > > > > More below. > > > > John > > > >> -----Original Message----- > >> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] > >> Sent: 17 August 2007 15:13 > >> To: bliss@ietf.org > >> Cc: Elwell, John > >> Subject: AW: [BLISS] Use of Warning: header to transport > >> additionalstatusindications > >> > >> Hello John > >> > >> Thanks for the comments, responses inline. > >> > >> This indications are transmitted during call-establishment phase. > >> [JRE] I understand why a user may wish to receive > >> notifications that call diversion is active, but I fail to > >> see why this should be synchronised with that user's attempts > >> to establish calls. It seems to me that the SIP event > >> framework would be ideally suited to this. A UA could > >> subscribe to an event package, and any information related to > >> the way incoming calls are handled at the proxy (not merely a > >> simple indication that diversion is active) could be provided > >> in notifications. I see this as part of the automated call > >> handling topic in BLISS, so I will add it to my list of > >> things to consider. > >> > >> [DA] I think using event framework would be an overkill for > >> such simple indication and Warning header even literary fits > >> well for this case as a reminder. In addition the > >> interworking with ISDN/GSM would be way to complicated if > >> unbundled from the call establishment state. > > [JRE] I don't see how it is needed for interworking with ISDN/GSM > > networks, because your proposal is only between a calling > user's proxy > > and the calling user's UA. The only case I can think of is where the > > calling UA is actually an adaptor to an ISDN or GSM phone. > I must admit > > I forget whether there is Q.931 signalling for this to an > ISDN phone and > > I don't know what provision there is for a GSM phone. I am doubtful > > about the wisdom of assigning SIP codepoints for such specific > > interworking purposes, particularly when it only satisfies a small > > subset of a potentially bigger problem space of more general > > applicability. Let's see what others think. > > > >> A proposal is to reuse the Warning: header by > >> extanding the warn-code with the values reflecting the > >> described cases. The spare volumes of warn codes at the > >> moment are 340-369 and 390-399, so the following new warn > >> codes can be defined: > >> > >> Warning: 341 isi.edu "Call is a waiting call" > >> [JRE] Why is the 182 Queued response insufficient? > >> > >> [DA] It is not exactly the same as queued, > >> because the B-party receives the session setup request, but > >> with indication that the resources shall be made available in > >> order to establish the session. In queued case the session in > >> not presented to the B-party but queued by some instance before. > > [JRE] I see nothing in the definition of 182 Queued in RFC > 3263 to say > > that the session is not presented to the B-party. This is > just a user > > interface matter, and I would imagine, for both queued and > call waiting, > > the B-party would be given some indication as to the presence of the > > queued or waiting call. In other words, I fail to see the > difference. > > > >> > >> Warning: 342 isi.edu "Diversion activated" > >> > >> The procedure at the SIP proxy is then to > >> include the Warning: Header in to the 180 Ringing or 183 > >> Session Progress response to provide the required indication > >> to the A-Party. > >> [JRE] Why would a proxy need to do anything for > >> call waiting? Call waiting is a function of the called UA, > >> which would generate the necessary indication (182 response, > >> in my opinion) when appropriate. How would the proxy be in a > >> position to be able to generate such information? > >> > >> [DA]The reasoning behind it is that network > >> might limit the number of simultaneous sessions, that can be > >> established with a specific URI. In this case an incoming > >> call to the URI that has already reached the maximum number > >> of simultaneous sessions would fall in to the call-waiting > >> state. > > [JRE] I don't see it this way. If the called UA is busy on > one session, > > and a further INVITE request arrives that cannot be > processed normally > > because resources are occupied by the existing session, then that is > > exactly the situation where the UA might apply call waiting > (according > > to policy dictated by the user) and send back a 182 response. So in > > other words, we get to the call waiting state without exceeding any > > network limit to the number of sessions - only the UA limit to the > > number of active sessions has been exceeded, which is typically 1 > > (although could well be more for message sessions, for > example, or if > > join is requested). > > I think what you are talking about here is the case where > the "network" > > (the inbound proxy) has a policy to limit the number of > sessions at the > > UA (including those in call waiting state), and that any further > > sessions establishment requests beyond this limit also be given call > > waiting state, but not by the UA. That could certainly be > done, and in > > effect the proxy would forward any further INVITE requests to an > > alternative UA (which could be collocated with the proxy) that would > > queue the requests and send back 182. However, I see two > difficulties > > with this. How is the user advised of these additional > queued requests? > > How do they eventually get answered? Presumably the proxy > has to somehow > > know when the normal UA has resources to accept further > requests, and > > then cancel them from the alternative UA and forward them > to the normal > > UA. It all seems rather complicated and all it seems to do > is save some > > resources at the normal called UA. Shouldn't it be a matter for the > > called UA to decide how many it can accept, and then deal with any > > additional INVITE requests appropriately, e.g., reject or > redirect to an > > alternative answering point? > > > >> For this scenario an indication is needed to the > >> A-party that is it not just normal ringing but call-waiting case. > > [JRE] Why does the calling user need to be aware of this subtle > > difference between waiting at the called UA and waiting at an > > alternative UA somehow closely associated with the proxy? > > > > > >> Greetings, > >> > >> Denis Alexeitsev > >> > >> > > > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 17 13:51:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM5zF-0001iW-6X; Fri, 17 Aug 2007 13:51:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM5zC-0001iO-EX for bliss@ietf.org; Fri, 17 Aug 2007 13:51:50 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM5zB-0004Fq-70 for bliss@ietf.org; Fri, 17 Aug 2007 13:51:50 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7HHpjL11712; Fri, 17 Aug 2007 17:51:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transportadditionalstatusindications Date: Fri, 17 Aug 2007 12:51:44 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711634E24B@zrc2hxm2.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026F2B3@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transportadditionalstatusindications Thread-Index: Acfg5SnNeKwCLI8iQYWEMar0YIXT8gAAvWuwAAOqClA= References: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D026F299@GBNTHT12009MSX.gb002.siemens.net> <46C5C144.20708@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D026F2B3@GBNTHT12009MSX.gb002.siemens.net> From: "Brian Stucker" To: "Elwell, John" , "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I would agree with you John, that what's needed for CWT is already specified in 3261. 180 versus 182 (to me) is just a matter of 'politeness' if you consider that it might be nice to send a 182 back if you suspect that the terminator will take a little longer than usual to evaluate your new call to them because they're already engaged in a call. It could also be used to let you know a little bit about why your call might have been diverted or declined, but this could be equally well handled with a 181 or a 486, 603, etc. response depending upon the desired outcome. I've never found much use for 182. Can anyone who is using 182 explain why they are using it? Regards, Brian > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com]=20 > Sent: Friday, August 17, 2007 11:05 AM > To: Paul Kyzivat > Cc: bliss@ietf.org; Alexeitsev, D > Subject: RE: [BLISS] Use of Warning: header to=20 > transportadditionalstatusindications >=20 > Paul, >=20 > I agree that the called UA could choose to send 180, but I=20 > think 182 is equally valid. However, my point really was that=20 > I don't see the need for anything beyond what is already in=20 > RFC 3261 for call waiting. >=20 > John=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 17 August 2007 16:40 > > To: Elwell, John > > Cc: Alexeitsev, D; bliss@ietf.org > > Subject: Re: [BLISS] Use of Warning: header to=20 > > transportadditionalstatusindications > >=20 > > The 182 Queued response may be a little underspecified. > > Its far from clear to me that it is appropriate in the call waiting=20 > > case. > >=20 > > I fail to see any significant difference between call waiting and a=20 > > phone with two lines for the same number. And little difference=20 > > between that and two phones registered for the same number=20 > and sitting=20 > > on the same desk in front of a single person. > >=20 > > In all of these cases, when the second call comes in the callee is=20 > > alerted, and has the option of answering the call. The=20 > callee may need=20 > > to do something before answering the phone - put a=20 > different call on=20 > > hold, put down his cup of coffee, or whatever. In all these=20 > cases why=20 > > isn't 180 the appropriate response? > >=20 > > Why should I expect to get some special call waiting status=20 > if it is a=20 > > phone with "call waiting" service and another call active,=20 > while not=20 > > if it is a phone with two "lines", or two phones on one desk? > >=20 > > If I am implementing a phone, how do I decide whether to=20 > return "call=20 > > waiting" status? > >=20 > > Paul > >=20 > > Elwell, John wrote: > > > Denis, > > >=20 > > > More below. > > >=20 > > > John > > >=20 > > >> -----Original Message----- > > >> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] > > >> Sent: 17 August 2007 15:13 > > >> To: bliss@ietf.org > > >> Cc: Elwell, John > > >> Subject: AW: [BLISS] Use of Warning: header to transport=20 > > >> additionalstatusindications > > >> > > >> Hello John > > >> =20 > > >> Thanks for the comments, responses inline.=20 > > >> =20 > > >> This indications are transmitted during=20 > call-establishment phase.=20 > > >> [JRE] I understand why a user may wish to receive notifications=20 > > >> that call diversion is active, but I fail to see why=20 > this should be=20 > > >> synchronised with that user's attempts to establish=20 > calls. It seems=20 > > >> to me that the SIP event framework would be ideally=20 > suited to this.=20 > > >> A UA could subscribe to an event package, and any information=20 > > >> related to the way incoming calls are handled at the proxy (not=20 > > >> merely a simple indication that diversion is active) could be=20 > > >> provided in notifications. I see this as part of the=20 > automated call=20 > > >> handling topic in BLISS, so I will add it to my list of=20 > things to=20 > > >> consider. > > >> =20 > > >> [DA] I think using event framework would be an overkill for such=20 > > >> simple indication and Warning header even literary fits well for=20 > > >> this case as a reminder. In addition the interworking=20 > with ISDN/GSM=20 > > >> would be way to complicated if unbundled from the call=20 > > >> establishment state. > > > [JRE] I don't see how it is needed for interworking with ISDN/GSM=20 > > > networks, because your proposal is only between a calling > > user's proxy > > > and the calling user's UA. The only case I can think of=20 > is where the=20 > > > calling UA is actually an adaptor to an ISDN or GSM phone. > > I must admit > > > I forget whether there is Q.931 signalling for this to an > > ISDN phone and > > > I don't know what provision there is for a GSM phone. I=20 > am doubtful=20 > > > about the wisdom of assigning SIP codepoints for such specific=20 > > > interworking purposes, particularly when it only=20 > satisfies a small=20 > > > subset of a potentially bigger problem space of more general=20 > > > applicability. Let's see what others think. > > >=20 > > >> A proposal is to reuse the Warning: header by=20 > extanding the=20 > > >> warn-code with the values reflecting the described=20 > cases. The spare=20 > > >> volumes of warn codes at the moment are 340-369 and=20 > 390-399, so the=20 > > >> following new warn codes can be defined: > > >> > > >> Warning: 341 isi.edu "Call is a waiting call"=20 > > >> [JRE] Why is the 182 Queued response insufficient?=20 > > >> > > >> [DA] It is not exactly the same as queued,=20 > because the B-party=20 > > >> receives the session setup request, but with indication that the=20 > > >> resources shall be made available in order to establish the=20 > > >> session. In queued case the session in not presented to=20 > the B-party=20 > > >> but queued by some instance before. > > > [JRE] I see nothing in the definition of 182 Queued in RFC > > 3263 to say > > > that the session is not presented to the B-party. This is > > just a user > > > interface matter, and I would imagine, for both queued and > > call waiting, > > > the B-party would be given some indication as to the=20 > presence of the=20 > > > queued or waiting call. In other words, I fail to see the > > difference. > > >=20 > > >> =09 > > >> Warning: 342 isi.edu "Diversion activated"=20 > > >> > > >> The procedure at the SIP proxy is then to=20 > include the Warning:=20 > > >> Header in to the 180 Ringing or 183 Session Progress response to=20 > > >> provide the required indication to the A-Party. > > >> [JRE] Why would a proxy need to do anything for=20 > call waiting?=20 > > >> Call waiting is a function of the called UA, which would=20 > generate=20 > > >> the necessary indication (182 response, in my opinion) when=20 > > >> appropriate. How would the proxy be in a position to be able to=20 > > >> generate such information? > > >> > > >> [DA]The reasoning behind it is that network=20 > might limit the=20 > > >> number of simultaneous sessions, that can be established with a=20 > > >> specific URI. In this case an incoming call to the URI that has=20 > > >> already reached the maximum number of simultaneous=20 > sessions would=20 > > >> fall in to the call-waiting state. > > > [JRE] I don't see it this way. If the called UA is busy on > > one session, > > > and a further INVITE request arrives that cannot be > > processed normally > > > because resources are occupied by the existing session,=20 > then that is=20 > > > exactly the situation where the UA might apply call waiting > > (according > > > to policy dictated by the user) and send back a 182=20 > response. So in=20 > > > other words, we get to the call waiting state without=20 > exceeding any=20 > > > network limit to the number of sessions - only the UA=20 > limit to the=20 > > > number of active sessions has been exceeded, which is typically 1=20 > > > (although could well be more for message sessions, for > > example, or if > > > join is requested). > > > I think what you are talking about here is the case where > > the "network" > > > (the inbound proxy) has a policy to limit the number of > > sessions at the > > > UA (including those in call waiting state), and that any further=20 > > > sessions establishment requests beyond this limit also be=20 > given call=20 > > > waiting state, but not by the UA. That could certainly be > > done, and in > > > effect the proxy would forward any further INVITE requests to an=20 > > > alternative UA (which could be collocated with the proxy)=20 > that would=20 > > > queue the requests and send back 182. However, I see two > > difficulties > > > with this. How is the user advised of these additional > > queued requests? > > > How do they eventually get answered? Presumably the proxy > > has to somehow > > > know when the normal UA has resources to accept further > > requests, and > > > then cancel them from the alternative UA and forward them > > to the normal > > > UA. It all seems rather complicated and all it seems to do > > is save some > > > resources at the normal called UA. Shouldn't it be a=20 > matter for the=20 > > > called UA to decide how many it can accept, and then deal=20 > with any=20 > > > additional INVITE requests appropriately, e.g., reject or > > redirect to an > > > alternative answering point? > > >=20 > > >> For this scenario an indication is needed to the A-party=20 > that is it=20 > > >> not just normal ringing but call-waiting case. > > > [JRE] Why does the calling user need to be aware of this subtle=20 > > > difference between waiting at the called UA and waiting at an=20 > > > alternative UA somehow closely associated with the proxy? > > >=20 > > >=20 > > >> Greetings, > > >> > > >> Denis Alexeitsev > > >> > > >> > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/bliss > > >=20 > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 17 14:04:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM6Bb-0005wC-HD; Fri, 17 Aug 2007 14:04:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM6BZ-0005w5-H0 for bliss@ietf.org; Fri, 17 Aug 2007 14:04:37 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM6BY-0001KH-Jj for bliss@ietf.org; Fri, 17 Aug 2007 14:04:37 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7HI2YD13192; Fri, 17 Aug 2007 18:02:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transportadditionalstatusindications Date: Fri, 17 Aug 2007 13:04:32 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711634E2A2@zrc2hxm2.corp.nortel.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180015AEADC@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transportadditionalstatusindications Thread-Index: Acfgz0qJmh+ZCDEyT/Kj3qo6JgYoCQAAuzgwAAEGhvAAALIQIAAHkEzA References: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> <5D1A7985295922448D5550C94DE29180015AEADC@DEEXC1U01.de.lucent.com> From: "Brian Stucker" To: "DRAGE, Keith (Keith)" , "Alexeitsev, D" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I don't know about everyone else, but just sitting here trying to work through in my head how all of these indicators are going to sync up during a relatively quick call establishment phase is making my head spin with race conditions (esp. with SUB/NOTIFY in parallel with the INVITE). If someone were to want to provide this type of service, I think you'd be best served by simply connecting your call to a media source prior to routing the INVITE onward to play the CFD active tone. I don't think warning headers were intended to trigger services like this, and it's pretty unlikely that clients will pay attention to it the way you want. I've seen implementations that use the Alert-Info header for this type of function (essentially convey the information that supervision used to handle for us) and it's something that is going to be very non-compatible with most every implementation out there (read: nobody is going to honor it, so the service will break). A problem with the Warning header (or Alert-Info for that matter) approach is that it these headers are in responses that ostensibly describes something related to the party you are intending to reach, not the party making the call. Regards, Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Friday, August 17, 2007 9:31 AM > To: Alexeitsev, D; bliss@ietf.org > Subject: RE: [BLISS] Use of Warning: header to=20 > transportadditionalstatusindications >=20 > This indications are transmitted during=20 > call-establishment phase.=20 >=20 > [JRE] I understand why a user may wish to receive=20 > notifications that call diversion is active, but I fail to=20 > see why this should be synchronised with that user's attempts=20 > to establish calls. It seems to me that the SIP event=20 > framework would be ideally suited to this. A UA could=20 > subscribe to an event package, and any information related to=20 > the way incoming calls are handled at the proxy (not merely a=20 > simple indication that diversion is active) could be provided=20 > in notifications. > I see this as part of the automated call handling topic in=20 > BLISS, so I will add it to my list of things to consider. =20 > =20 > [DA] I think using event framework would be an overkill=20 > for such simple indication and Warning header even literary=20 > fits well for this case as a reminder. In addition the=20 > interworking with ISDN/GSM would be way to complicated if=20 > unbundled from the call establishment state.=20 >=20 > [KED} These indications that diversion is active are=20 > equivalent to the old black phone equivalent of giving=20 > special dial tone when diversion is active and so on. When=20 > they were discussed in the evolution of the ISDN, they were=20 > regarded as part of the stimulus protocol rather than the=20 > functional protocol. Therefore no ISDN functional protocol=20 > was ever defined for them (at least I cannot see anything in=20 > ETSI EN 300 207-1 > V3.1.1 (2001-06) which is the latest version of the DSS1=20 > protocol document, and for which there should be a direct=20 > ITU-T equivalent.=20 >=20 > Rather, some stimulus indication can be given, such as a tone=20 > or announcement. Now there have been extensive discussions in=20 > the past on stimulus versus functional in SIP... >=20 > Regards >=20 > Keith >=20 > ________________________________ >=20 > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > Sent: Friday, August 17, 2007 3:13 PM > To: bliss@ietf.org > Subject: AW: [BLISS] Use of Warning: header to=20 > transportadditionalstatusindications > =09 > =09 > Hello John > =20 > Thanks for the comments, responses inline.=20 > =20 > This indications are transmitted during=20 > call-establishment phase.=20 > [JRE] I understand why a user may wish to receive=20 > notifications that call diversion is active, but I fail to=20 > see why this should be synchronised with that user's attempts=20 > to establish calls. It seems to me that the SIP event=20 > framework would be ideally suited to this. A UA could=20 > subscribe to an event package, and any information related to=20 > the way incoming calls are handled at the proxy (not merely a=20 > simple indication that diversion is active) could be provided=20 > in notifications. > I see this as part of the automated call handling topic in=20 > BLISS, so I will add it to my list of things to consider. =20 > =20 > [DA] I think using event framework would be an overkill=20 > for such simple indication and Warning header even literary=20 > fits well for this case as a reminder. In addition the=20 > interworking with ISDN/GSM would be way to complicated if=20 > unbundled from the call establishment state. >=20 > A proposal is to reuse the Warning:=20 > header by extanding the warn-code with the values reflecting=20 > the described cases. > The spare volumes of warn codes at the moment are 340-369 and=20 > 390-399, so the following new warn codes can be defined: >=20 > Warning: 341 isi.edu "Call is a waiting call"=20 > [JRE] Why is the 182 Queued response > insufficient?=20 >=20 > [DA] It is not exactly the same as=20 > queued, because the B-party receives the session setup=20 > request, but with indication that the resources shall be made=20 > available in order to establish the session. In queued case=20 > the session in not presented to the B-party but queued by=20 > some instance before. >=20 > =09 > Warning: 342 isi.edu "Diversion activated"=20 >=20 > The procedure at the SIP proxy is then=20 > to include the Warning: Header in to the 180 Ringing or 183=20 > Session Progress response to provide the required indication=20 > to the A-Party.=20 > [JRE] Why would a proxy need to do=20 > anything for call waiting? Call waiting is a function of the=20 > called UA, which would generate the necessary indication (182=20 > response, in my opinion) when appropriate. How would the=20 > proxy be in a position to be able to generate such information? >=20 > [DA]The reasoning behind it is that=20 > network might limit the number of simultaneous sessions, that=20 > can be established with a specific URI. In this case an=20 > incoming call to the URI that has already reached the maximum=20 > number of simultaneous sessions would fall in to the=20 > call-waiting state. For this scenario an indication is needed=20 > to the A-party that is it not just normal ringing but=20 > call-waiting case. >=20 > Greetings, >=20 > Denis Alexeitsev >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 17 16:23:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM8LW-0003jt-0x; Fri, 17 Aug 2007 16:23:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM8LT-0003jG-HV for bliss@ietf.org; Fri, 17 Aug 2007 16:22:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM8LS-0005ND-It for bliss@ietf.org; Fri, 17 Aug 2007 16:22:59 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2007 16:22:58 -0400 X-IronPort-AV: i="4.19,277,1183348800"; d="scan'208"; a="68304119:sNHT64454028" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7HKMwlm007639; Fri, 17 Aug 2007 16:22:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7HKMfjU024671; Fri, 17 Aug 2007 20:22:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 16:22:44 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Aug 2007 16:22:44 -0400 Message-ID: <46C60391.6070609@cisco.com> Date: Fri, 17 Aug 2007 16:22:41 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] Use of Warning: header to transportadditionalstatusindications References: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> <5D1A7985295922448D5550C94DE29180015AEADC@DEEXC1U01.de.lucent.com> <6FC4416DDE56C44DA0AEE67BC7CA43711634E2A2@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711634E2A2@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2007 20:22:44.0273 (UTC) FILETIME=[5E62AA10:01C7E10C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8094; t=1187382178; x=1188246178; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Use=20of=20Warning=3A=20header=09to=09trans portadditionalstatusindications |Sender:=20 |To:=20Brian=20Stucker=20; bh=YeX5tadj6wIjLb876LHs6UfWgKhDWE4/r8G0YZ0ezIA=; b=SMJYBgkl3AZGflkV8jA8RCDlsrSKqsFB835BSewYgKXR4azQE13EC6I7Xzaicnpy8S/rDBzC Kpo/ZWpYaTnG73IUzeST5qEtp62zalDnS1/jAEWiWGNRbAD76UsOvbXB; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Another way of achieving this sort of thing, if you want it (why?), is with an Alert-Info header in the response. The UAC may act on that to generate a selected local ringback. But IMO using ringback, however triggered, to indicate you have call forwarding enabled is just an old PSTN hack. And does the pstn even do it as part of the response to a call establishment request? I thought it resulted in an altered dial tone, which in sip terms means it is known to the phone *before* an invite is sent. A subscription can deliver the info to the UA, and it can then remember the state. If it has a suitable UI it can light a light or put something on a display about the state. If not it can alter the dialtone it plays. There could be a special subscription for this. But I expect the kind of environment where this is interesting may well already involve a subscription to the config event package. It would then be simple to include the forwarding mode as a piece of the configuration state, and send a notification if/when it is changed. (I.e. because you went to a web page and changed it.) Paul Brian Stucker wrote: > I don't know about everyone else, but just sitting here trying to work > through in my head how all of these indicators are going to sync up > during a relatively quick call establishment phase is making my head > spin with race conditions (esp. with SUB/NOTIFY in parallel with the > INVITE). > > If someone were to want to provide this type of service, I think you'd > be best served by simply connecting your call to a media source prior to > routing the INVITE onward to play the CFD active tone. I don't think > warning headers were intended to trigger services like this, and it's > pretty unlikely that clients will pay attention to it the way you want. > I've seen implementations that use the Alert-Info header for this type > of function (essentially convey the information that supervision used to > handle for us) and it's something that is going to be very > non-compatible with most every implementation out there (read: nobody is > going to honor it, so the service will break). > > A problem with the Warning header (or Alert-Info for that matter) > approach is that it these headers are in responses that ostensibly > describes something related to the party you are intending to reach, not > the party making the call. > > Regards, > Brian > >> -----Original Message----- >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] >> Sent: Friday, August 17, 2007 9:31 AM >> To: Alexeitsev, D; bliss@ietf.org >> Subject: RE: [BLISS] Use of Warning: header to >> transportadditionalstatusindications >> >> This indications are transmitted during >> call-establishment phase. >> >> [JRE] I understand why a user may wish to receive >> notifications that call diversion is active, but I fail to >> see why this should be synchronised with that user's attempts >> to establish calls. It seems to me that the SIP event >> framework would be ideally suited to this. A UA could >> subscribe to an event package, and any information related to >> the way incoming calls are handled at the proxy (not merely a >> simple indication that diversion is active) could be provided >> in notifications. >> I see this as part of the automated call handling topic in >> BLISS, so I will add it to my list of things to consider. >> >> [DA] I think using event framework would be an overkill >> for such simple indication and Warning header even literary >> fits well for this case as a reminder. In addition the >> interworking with ISDN/GSM would be way to complicated if >> unbundled from the call establishment state. >> >> [KED} These indications that diversion is active are >> equivalent to the old black phone equivalent of giving >> special dial tone when diversion is active and so on. When >> they were discussed in the evolution of the ISDN, they were >> regarded as part of the stimulus protocol rather than the >> functional protocol. Therefore no ISDN functional protocol >> was ever defined for them (at least I cannot see anything in >> ETSI EN 300 207-1 >> V3.1.1 (2001-06) which is the latest version of the DSS1 >> protocol document, and for which there should be a direct >> ITU-T equivalent. >> >> Rather, some stimulus indication can be given, such as a tone >> or announcement. Now there have been extensive discussions in >> the past on stimulus versus functional in SIP... >> >> Regards >> >> Keith >> >> ________________________________ >> >> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] >> Sent: Friday, August 17, 2007 3:13 PM >> To: bliss@ietf.org >> Subject: AW: [BLISS] Use of Warning: header to >> transportadditionalstatusindications >> >> >> Hello John >> >> Thanks for the comments, responses inline. >> >> This indications are transmitted during >> call-establishment phase. >> [JRE] I understand why a user may wish to receive >> notifications that call diversion is active, but I fail to >> see why this should be synchronised with that user's attempts >> to establish calls. It seems to me that the SIP event >> framework would be ideally suited to this. A UA could >> subscribe to an event package, and any information related to >> the way incoming calls are handled at the proxy (not merely a >> simple indication that diversion is active) could be provided >> in notifications. >> I see this as part of the automated call handling topic in >> BLISS, so I will add it to my list of things to consider. >> >> [DA] I think using event framework would be an overkill >> for such simple indication and Warning header even literary >> fits well for this case as a reminder. In addition the >> interworking with ISDN/GSM would be way to complicated if >> unbundled from the call establishment state. >> >> A proposal is to reuse the Warning: >> header by extanding the warn-code with the values reflecting >> the described cases. >> The spare volumes of warn codes at the moment are 340-369 and >> 390-399, so the following new warn codes can be defined: >> >> Warning: 341 isi.edu "Call is a waiting call" >> [JRE] Why is the 182 Queued response >> insufficient? >> >> [DA] It is not exactly the same as >> queued, because the B-party receives the session setup >> request, but with indication that the resources shall be made >> available in order to establish the session. In queued case >> the session in not presented to the B-party but queued by >> some instance before. >> >> >> Warning: 342 isi.edu "Diversion activated" >> >> The procedure at the SIP proxy is then >> to include the Warning: Header in to the 180 Ringing or 183 >> Session Progress response to provide the required indication >> to the A-Party. >> [JRE] Why would a proxy need to do >> anything for call waiting? Call waiting is a function of the >> called UA, which would generate the necessary indication (182 >> response, in my opinion) when appropriate. How would the >> proxy be in a position to be able to generate such information? >> >> [DA]The reasoning behind it is that >> network might limit the number of simultaneous sessions, that >> can be established with a specific URI. In this case an >> incoming call to the URI that has already reached the maximum >> number of simultaneous sessions would fall in to the >> call-waiting state. For this scenario an indication is needed >> to the A-party that is it not just normal ringing but >> call-waiting case. >> >> Greetings, >> >> Denis Alexeitsev >> >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 17 17:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM9EH-0002vj-50; Fri, 17 Aug 2007 17:19:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM9EF-0002vR-Tj for bliss@ietf.org; Fri, 17 Aug 2007 17:19:35 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IM9EE-0002XO-U7 for bliss@ietf.org; Fri, 17 Aug 2007 17:19:35 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7HLJV712027; Fri, 17 Aug 2007 21:19:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transportadditionalstatusindications Date: Fri, 17 Aug 2007 16:19:30 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711639EBA6@zrc2hxm2.corp.nortel.com> In-Reply-To: <46C60391.6070609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transportadditionalstatusindications Thread-Index: AcfhDGt89NPN+uHdQsqKhry95bfKzwABwabQ References: <0D5F89FAC29E2C41B98A6A762007F5D026F27E@GBNTHT12009MSX.gb002.siemens.net> <5D1A7985295922448D5550C94DE29180015AEADC@DEEXC1U01.de.lucent.com> <6FC4416DDE56C44DA0AEE67BC7CA43711634E2A2@zrc2hxm2.corp.nortel.com> <46C60391.6070609@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, August 17, 2007 3:23 PM > To: Stucker, Brian (RICH1:AR00) > Cc: DRAGE, Keith (Keith); Alexeitsev, D; bliss@ietf.org > Subject: Re: [BLISS] Use of Warning: header to=20 > transportadditionalstatusindications >=20 > Another way of achieving this sort of thing, if you want it=20 > (why?), is with an Alert-Info header in the response. The UAC=20 > may act on that to generate a selected local ringback. IMHO- Alert-Info is generally a bad idea. I know it's used, but it's usually used as a hack from what I've seen. I certainly wouldn't trust an Alert-Info from another domain, so in the case of a roaming mobile, it seems fairly unlikely that it would be proxied along. I'm pretty certain that most operators actually strip this header out of any signaling received from another proxy and only allow Alert-Info headers generated by an authoritative/local outbound type proxy toward the UA to be passed along. >=20 > But IMO using ringback, however triggered, to indicate you=20 > have call forwarding enabled is just an old PSTN hack. And=20 > does the pstn even do it as part of the response to a call=20 > establishment request? I thought it resulted in an altered=20 > dial tone, which in sip terms means it is known to the phone=20 > *before* an invite is sent. It's handled via line supervision. Serious PSTN voodoo. >=20 > A subscription can deliver the info to the UA, and it can=20 > then remember the state. If it has a suitable UI it can light=20 > a light or put something on a display about the state. If not=20 > it can alter the dialtone it plays. This seems more reasonable, especially for a form-factor smart enough to run SIP. I've seen implementations that do this in the wild. I thought we were talking about trying to do it inline with the INVITE. >=20 > There could be a special subscription for this. But I expect=20 > the kind of environment where this is interesting may well=20 > already involve a subscription to the config event package.=20 > It would then be simple to include the forwarding mode as a=20 > piece of the configuration state, and send a notification=20 > if/when it is changed. (I.e. because you went to a web page=20 > and changed it.) >=20 > Paul >=20 > Brian Stucker wrote: > > I don't know about everyone else, but just sitting here=20 > trying to work=20 > > through in my head how all of these indicators are going to sync up=20 > > during a relatively quick call establishment phase is=20 > making my head=20 > > spin with race conditions (esp. with SUB/NOTIFY in parallel=20 > with the=20 > > INVITE). > >=20 > > If someone were to want to provide this type of service, I=20 > think you'd=20 > > be best served by simply connecting your call to a media=20 > source prior=20 > > to routing the INVITE onward to play the CFD active tone. I don't=20 > > think warning headers were intended to trigger services=20 > like this, and=20 > > it's pretty unlikely that clients will pay attention to it=20 > the way you want. > > I've seen implementations that use the Alert-Info header=20 > for this type=20 > > of function (essentially convey the information that=20 > supervision used=20 > > to handle for us) and it's something that is going to be very=20 > > non-compatible with most every implementation out there=20 > (read: nobody=20 > > is going to honor it, so the service will break). > >=20 > > A problem with the Warning header (or Alert-Info for that matter)=20 > > approach is that it these headers are in responses that ostensibly=20 > > describes something related to the party you are intending=20 > to reach,=20 > > not the party making the call. > >=20 > > Regards, > > Brian > >=20 > >> -----Original Message----- > >> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > >> Sent: Friday, August 17, 2007 9:31 AM > >> To: Alexeitsev, D; bliss@ietf.org > >> Subject: RE: [BLISS] Use of Warning: header to=20 > >> transportadditionalstatusindications > >> > >> This indications are transmitted during=20 > call-establishment phase. > >> > >> [JRE] I understand why a user may wish to receive=20 > notifications that=20 > >> call diversion is active, but I fail to see why this should be=20 > >> synchronised with that user's attempts to establish calls.=20 > It seems=20 > >> to me that the SIP event framework would be ideally suited=20 > to this. A=20 > >> UA could subscribe to an event package, and any=20 > information related=20 > >> to the way incoming calls are handled at the proxy (not merely a=20 > >> simple indication that diversion is active) could be provided in=20 > >> notifications. > >> I see this as part of the automated call handling topic in=20 > BLISS, so=20 > >> I will add it to my list of things to consider. > >> =20 > >> [DA] I think using event framework would be an overkill=20 > for such=20 > >> simple indication and Warning header even literary fits=20 > well for this=20 > >> case as a reminder. In addition the interworking with=20 > ISDN/GSM would=20 > >> be way to complicated if unbundled from the call=20 > establishment state. > >> > >> [KED} These indications that diversion is active are equivalent to=20 > >> the old black phone equivalent of giving special dial tone when=20 > >> diversion is active and so on. When they were discussed in the=20 > >> evolution of the ISDN, they were regarded as part of the stimulus=20 > >> protocol rather than the functional protocol. Therefore no ISDN=20 > >> functional protocol was ever defined for them (at least I=20 > cannot see=20 > >> anything in ETSI EN 300 207-1 > >> V3.1.1 (2001-06) which is the latest version of the DSS1 protocol=20 > >> document, and for which there should be a direct ITU-T equivalent. > >> > >> Rather, some stimulus indication can be given, such as a tone or=20 > >> announcement. Now there have been extensive discussions in=20 > the past=20 > >> on stimulus versus functional in SIP... > >> > >> Regards > >> > >> Keith > >> > >> ________________________________ > >> > >> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > >> Sent: Friday, August 17, 2007 3:13 PM > >> To: bliss@ietf.org > >> Subject: AW: [BLISS] Use of Warning: header to=20 > >> transportadditionalstatusindications > >> =09 > >> =09 > >> Hello John > >> =20 > >> Thanks for the comments, responses inline.=20 > >> =20 > >> This indications are transmitted during=20 > call-establishment phase. > >> [JRE] I understand why a user may wish to receive=20 > notifications that=20 > >> call diversion is active, but I fail to see why this should be=20 > >> synchronised with that user's attempts to establish calls.=20 > It seems=20 > >> to me that the SIP event framework would be ideally suited=20 > to this. A=20 > >> UA could subscribe to an event package, and any=20 > information related=20 > >> to the way incoming calls are handled at the proxy (not merely a=20 > >> simple indication that diversion is active) could be provided in=20 > >> notifications. > >> I see this as part of the automated call handling topic in=20 > BLISS, so=20 > >> I will add it to my list of things to consider. > >> =20 > >> [DA] I think using event framework would be an overkill=20 > for such=20 > >> simple indication and Warning header even literary fits=20 > well for this=20 > >> case as a reminder. In addition the interworking with=20 > ISDN/GSM would=20 > >> be way to complicated if unbundled from the call=20 > establishment state. > >> > >> A proposal is to reuse the Warning:=20 > >> header by extanding the warn-code with the values reflecting the=20 > >> described cases. > >> The spare volumes of warn codes at the moment are 340-369 and=20 > >> 390-399, so the following new warn codes can be defined: > >> > >> Warning: 341 isi.edu "Call is a waiting call"=20 > >> [JRE] Why is the 182 Queued response=20 > insufficient? > >> > >> [DA] It is not exactly the same as=20 > queued, because the B-party=20 > >> receives the session setup request, but with indication that the=20 > >> resources shall be made available in order to establish=20 > the session.=20 > >> In queued case the session in not presented to the B-party=20 > but queued=20 > >> by some instance before. > >> > >> =09 > >> Warning: 342 isi.edu "Diversion activated"=20 > >> > >> The procedure at the SIP proxy is then=20 > to include the Warning:=20 > >> Header in to the 180 Ringing or 183 Session Progress response to=20 > >> provide the required indication to the A-Party. > >> [JRE] Why would a proxy need to do=20 > anything for call waiting? Call=20 > >> waiting is a function of the called UA, which would generate the=20 > >> necessary indication (182 response, in my opinion) when=20 > appropriate.=20 > >> How would the proxy be in a position to be able to generate such=20 > >> information? > >> > >> [DA]The reasoning behind it is that=20 > network might limit the number=20 > >> of simultaneous sessions, that can be established with a specific=20 > >> URI. In this case an incoming call to the URI that has already=20 > >> reached the maximum number of simultaneous sessions would=20 > fall in to=20 > >> the call-waiting state. For this scenario an indication is=20 > needed to=20 > >> the A-party that is it not just normal ringing but=20 > call-waiting case. > >> > >> Greetings, > >> > >> Denis Alexeitsev > >> > >> > >> _______________________________________________ > >> BLISS mailing list > >> BLISS@ietf.org > >> https://www1.ietf.org/mailman/listinfo/bliss > >> > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 20 04:42:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2pj-0005nU-Pl; Mon, 20 Aug 2007 04:41:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2pi-0005nP-QX for bliss@ietf.org; Mon, 20 Aug 2007 04:41:58 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN2pi-0000xo-AD for bliss@ietf.org; Mon, 20 Aug 2007 04:41:58 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Mon, 20 Aug 2007 10:41:55 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Aug 2007 10:41:54 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [BLISS] Use of Warning: header to transport additionalstatusindications X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 20 Aug 2007 10:41:53 +0200 Message-Id: In-Reply-To: <46C5C144.20708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additionalstatusindications Thread-Index: Acfg5NxFjMKiTpsZTxKGBHneyLwYagCIAdnA From: "Alexeitsev, D" To: , X-OriginalArrivalTime: 20 Aug 2007 08:41:54.0399 (UTC) FILETIME=[F5F256F0:01C7E305] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org If I am implementing a phone, how do I decide whether to return "call=20 waiting" status? [DA] Because the call-waiting service is based on the network policy (for example how many simultaneous session can be active over a given URI) the phone does not have to anything for this indication. It is network that adds this information to a response. My experience with UAs tells me that it is hard to say what kind of tone if at all the UA will apply on the receipt of the 182 Queued. That is why it is safer to add this Warning header to a 180 response. The UA that does not understand the Warning will ignore it and provide the normal ring back tone. The UA that knows the header will apply some additional indication. The question is does anything prohibits the use of Warning header to convey some additional indication on the status of the call or the status of the configuration? Greetings, Denis Alexeitsev _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 20 04:45:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2se-0006Vh-Bq; Mon, 20 Aug 2007 04:45:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2sd-0006UO-1m for bliss@ietf.org; Mon, 20 Aug 2007 04:44:59 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN2sb-0006Lx-Dq for bliss@ietf.org; Mon, 20 Aug 2007 04:44:59 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Mon, 20 Aug 2007 10:44:55 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Aug 2007 10:44:54 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [BLISS] Use of Warning: header to transportadditionalstatusindications X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 20 Aug 2007 10:44:53 +0200 Message-Id: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711634E2A2@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transportadditionalstatusindications Thread-Index: Acfgz0qJmh+ZCDEyT/Kj3qo6JgYoCQAAuzgwAAEGhvAAALIQIAAHkEzAAIOu9YA= From: "Alexeitsev, D" To: , , X-OriginalArrivalTime: 20 Aug 2007 08:44:54.0429 (UTC) FILETIME=[6140BCD0:01C7E306] X-Spam-Score: -1.0 (-) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org A problem with the Warning header (or Alert-Info for that matter) approach is that it these headers are in responses that ostensibly describes something related to the party you are intending to reach, not the party making the call. [DA] Got the point. Is there an appropriate parameter that can be used to convei some indication from the home proxy to the A party? Greetings, Denis Alexeitsev _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 20 04:51:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2yr-0002rk-N5; Mon, 20 Aug 2007 04:51:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN2yq-0002iz-6m for bliss@ietf.org; Mon, 20 Aug 2007 04:51:24 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN2yp-0001Au-Q5 for bliss@ietf.org; Mon, 20 Aug 2007 04:51:24 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JN200I4ODX0HT@siemenscomms.co.uk> for bliss@ietf.org; Mon, 20 Aug 2007 09:51:00 +0100 (BST) Date: Mon, 20 Aug 2007 09:51:15 +0100 From: "Elwell, John" Subject: RE: [BLISS] Use of Warning: header totransportadditionalstatusindications In-reply-to: To: "Alexeitsev, D" , bstucker@nortel.com, drage@alcatel-lucent.com, bliss@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026F317@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [BLISS] Use of Warning: header totransportadditionalstatusindications Thread-Index: Acfgz0qJmh+ZCDEyT/Kj3qo6JgYoCQAAuzgwAAEGhvAAALIQIAAHkEzAAIOu9YAAACEJUA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6FC4416DDE56C44DA0AEE67BC7CA43711634E2A2@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Denis, See below. John > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] > Sent: 20 August 2007 09:45 > To: bstucker@nortel.com; drage@alcatel-lucent.com; bliss@ietf.org > Subject: AW: [BLISS] Use of Warning: header > totransportadditionalstatusindications > > > A problem with the Warning header (or Alert-Info for that matter) > approach is that it these headers are in responses that ostensibly > describes something related to the party you are intending to > reach, not > the party making the call. > > [DA] Got the point. Is there an appropriate parameter that can be used > to convei some indication from the home proxy to the A party? [JRE] I don't think the requirement has arisen before. Based on discussions on this thread to date, it seems that diversion is not a compelling case for introducing such a capability. > > Greetings, > Denis Alexeitsev > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 20 05:17:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3OG-0006mD-43; Mon, 20 Aug 2007 05:17:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN3OF-0006m7-CY for bliss@ietf.org; Mon, 20 Aug 2007 05:17:39 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN3OE-00070K-3n for bliss@ietf.org; Mon, 20 Aug 2007 05:17:39 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l7K9HYYB009355; Mon, 20 Aug 2007 04:17:34 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 04:17:34 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 11:17:32 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header totransport additionalstatusindications Date: Mon, 20 Aug 2007 11:17:29 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180015AEC8C@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header totransport additionalstatusindications Thread-Index: Acfg5NxFjMKiTpsZTxKGBHneyLwYagCIAdnAAAFRhRA= References: <46C5C144.20708@cisco.com> From: "DRAGE, Keith \(Keith\)" To: "Alexeitsev, D" , , X-OriginalArrivalTime: 20 Aug 2007 09:17:32.0793 (UTC) FILETIME=[F0875E90:01C7E30A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org In the ISDN, there the call waiting service encompasses both a network recognition of insufficient resources to process the call and a terminal recognition of insufficient resources to process the call.=20 Surely from the called side, it is irrelevant who makes who makes this decision to send an indication. Therefore we should not be distinguishing the two cases as different responses, which is what is currently implied. Regards Keith > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > Sent: Monday, August 20, 2007 9:42 AM > To: pkyzivat@cisco.com; john.elwell@siemens.com > Cc: bliss@ietf.org > Subject: AW: [BLISS] Use of Warning: header totransport=20 > additionalstatusindications >=20 >=20 > If I am implementing a phone, how do I decide whether to=20 > return "call waiting" status? >=20 > [DA] Because the call-waiting service is based on the network=20 > policy (for example how many simultaneous session can be=20 > active over a given > URI) the phone does not have to anything for this indication.=20 > It is network that adds this information to a response. >=20 > My experience with UAs tells me that it is hard to say what=20 > kind of tone if at all the UA will apply on the receipt of=20 > the 182 Queued. That is why it is safer to add this Warning=20 > header to a 180 response. The UA that does not understand the=20 > Warning will ignore it and provide the normal ring back tone.=20 > The UA that knows the header will apply some additional indication. >=20 > The question is does anything prohibits the use of Warning=20 > header to convey some additional indication on the status of=20 > the call or the status of the configuration? >=20 > Greetings, > Denis Alexeitsev >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 20 10:10:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN7xQ-0000DS-Vj; Mon, 20 Aug 2007 10:10:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN7xP-0000DN-Vg for bliss@ietf.org; Mon, 20 Aug 2007 10:10:16 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IN7xP-0000DV-Er for bliss@ietf.org; Mon, 20 Aug 2007 10:10:15 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7KEACX25451; Mon, 20 Aug 2007 14:10:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transportadditionalstatusindications Date: Mon, 20 Aug 2007 09:09:41 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711639F34E@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transportadditionalstatusindications Thread-Index: Acfgz0qJmh+ZCDEyT/Kj3qo6JgYoCQAAuzgwAAEGhvAAALIQIAAHkEzAAIOu9YAACkYDwA== References: <6FC4416DDE56C44DA0AEE67BC7CA43711634E2A2@zrc2hxm2.corp.nortel.com> From: "Brian Stucker" To: "Alexeitsev, D" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org We're still talking about the call forwarding enabled indication here, right (not call waiting)? If so, then I think what it sounds like you're asking for is really two things, not one, and it's the second thing that people are having the most heartache about. You can send a notification using RFC-3265 back to party A at any time to tell them that call forwarding is active. The terminal can then do whatever it pleases with that information: change the UI, play a blurp when the user next dials, etc. The second thing it sounds like you want, though, in order to mimic existing PSTN behavior (where there may be no opportunity to send information outside of an estblished circuit) is that you want this information to be sent only once the user has initiated a call using the existing set of messages that are normally exchanged for a call setup. Is this correct? Because I don't think folks are opposed to having the proxy send information about the state of the user's services, but that there isn't a clear way of sending this information via response codes and headers in response messages while establishing a session. Regards, Brian > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > Sent: Monday, August 20, 2007 3:45 AM > To: Stucker, Brian (RICH1:AR00); drage@alcatel-lucent.com;=20 > bliss@ietf.org > Subject: AW: [BLISS] Use of Warning: header to=20 > transportadditionalstatusindications >=20 >=20 > A problem with the Warning header (or Alert-Info for that=20 > matter) approach is that it these headers are in responses=20 > that ostensibly describes something related to the party you=20 > are intending to reach, not the party making the call. >=20 > [DA] Got the point. Is there an appropriate parameter that=20 > can be used to convei some indication from the home proxy to=20 > the A party? >=20 > Greetings, > Denis Alexeitsev >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 20 10:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8PK-0004rN-Uv; Mon, 20 Aug 2007 10:39:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN8PJ-0004rH-BB for bliss@ietf.org; Mon, 20 Aug 2007 10:39:05 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN8PI-0006p2-3T for bliss@ietf.org; Mon, 20 Aug 2007 10:39:05 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Aug 2007 10:39:02 -0400 X-IronPort-AV: i="4.19,285,1183348800"; d="scan'208"; a="68463638:sNHT50357620" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7KEd3Bw007075; Mon, 20 Aug 2007 10:39:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7KEcsmf017753; Mon, 20 Aug 2007 14:39:03 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 10:38:48 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 10:38:48 -0400 Message-ID: <46C9A779.7000107@cisco.com> Date: Mon, 20 Aug 2007 10:38:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] Use of Warning: header to transportadditionalstatusindications References: <6FC4416DDE56C44DA0AEE67BC7CA43711634E2A2@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA43711639F34E@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711639F34E@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 14:38:48.0203 (UTC) FILETIME=[D19185B0:01C7E337] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2463; t=1187620743; x=1188484743; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Use=20of=20Warning=3A=20header=09to=09trans portadditionalstatusindications |Sender:=20 |To:=20Brian=20Stucker=20; bh=243cR1cu1Cp7lo5s8n2xeU0NIA/ea4WI4DgWE9kojfQ=; b=EjbOkp/BAuK0fxr8YFUTfVDYbqqcmGaRRZ6UIXNGJq2RAblcZ5wxTxUbUYrVMaL6Ka7/k/OS idHehlg8NMwzdLLQtBXaeAAqXp6mZ5SOTPh/gmILfd5ooKtSJGm5RM7t; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Brian Stucker wrote: > We're still talking about the call forwarding enabled indication here, > right (not call waiting)? > > If so, then I think what it sounds like you're asking for is really two > things, not one, and it's the second thing that people are having the > most heartache about. You can send a notification using RFC-3265 back to > party A at any time to tell them that call forwarding is active. The > terminal can then do whatever it pleases with that information: change > the UI, play a blurp when the user next dials, etc. > > The second thing it sounds like you want, though, in order to mimic > existing PSTN behavior (where there may be no opportunity to send > information outside of an estblished circuit) is that you want this > information to be sent only once the user has initiated a call using the > existing set of messages that are normally exchanged for a call setup. > > Is this correct? I'm curious to see the answer to this. If the answer is YES, then I have to ask WHY? Doing it that way in sip just because the PSTN did it that way isn't a good enough reason. (If the issue is gatewaying between the two models, then it may be worth discussing how that might be done.) > Because I don't think folks are opposed to having the > proxy send information about the state of the user's services, but that > there isn't a clear way of sending this information via response codes > and headers in response messages while establishing a session. > > Regards, > Brian > > > >> -----Original Message----- >> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] >> Sent: Monday, August 20, 2007 3:45 AM >> To: Stucker, Brian (RICH1:AR00); drage@alcatel-lucent.com; >> bliss@ietf.org >> Subject: AW: [BLISS] Use of Warning: header to >> transportadditionalstatusindications >> >> >> A problem with the Warning header (or Alert-Info for that >> matter) approach is that it these headers are in responses >> that ostensibly describes something related to the party you >> are intending to reach, not the party making the call. >> >> [DA] Got the point. Is there an appropriate parameter that >> can be used to convei some indication from the home proxy to >> the A party? >> >> Greetings, >> Denis Alexeitsev >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 20 12:11:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9qa-0006Z7-Gt; Mon, 20 Aug 2007 12:11:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9qY-0006Yb-JQ for bliss@ietf.org; Mon, 20 Aug 2007 12:11:18 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN9qX-0000nM-0r for bliss@ietf.org; Mon, 20 Aug 2007 12:11:18 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Mon, 20 Aug 2007 18:11:13 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Aug 2007 18:11:12 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [BLISS] Use of Warning: header to transportadditionalstatusindications X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 20 Aug 2007 18:11:08 +0200 Message-Id: In-Reply-To: <46C9A779.7000107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transportadditionalstatusindications Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niA From: "Alexeitsev, D" To: , X-OriginalArrivalTime: 20 Aug 2007 16:11:12.0966 (UTC) FILETIME=[BA813660:01C7E344] X-Spam-Score: -1.0 (-) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org > We're still talking about the call forwarding enabled indication here, > right (not call waiting)? There are two distinctive issues A) call forwarding enabled indication B) call waiting indication The initial idea was to use the Warning header for both of them. After the discussion it seams like for the case A) the Warning header is not applicable as it shall come from the B-party. By the way - where is this limitation defined? For the case B) I still think that Warning header could be reused, but I'm open to any proposals. If there is any interest of course. >If the answer is YES, then I have to ask WHY? Doing it that way in sip=20 >just because the PSTN did it that way isn't a good enough reason. (If=20 >the issue is gatewaying between the two models, then it may be worth=20 >discussing how that might be done.) Exactly - the interworking restrictions. Interworking unsynchronised SUB/NOT with call progress messages on the ISDN side that carry this indication is not the easiest thing to do. Greetings, Denis Alexeitsev _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 20 15:57:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDNm-0001vH-F3; Mon, 20 Aug 2007 15:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDNk-0001vA-Jk for bliss@ietf.org; Mon, 20 Aug 2007 15:57:49 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INDNj-0007xf-8g for bliss@ietf.org; Mon, 20 Aug 2007 15:57:48 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JN30021W8RS0F@siemenscomms.co.uk> for bliss@ietf.org; Mon, 20 Aug 2007 20:57:28 +0100 (BST) Date: Mon, 20 Aug 2007 20:57:43 +0100 From: "Elwell, John" Subject: RE: [BLISS] Use of Warning: header totransportadditionalstatusindications In-reply-to: To: "Alexeitsev, D" , pkyzivat@cisco.com, bstucker@nortel.com Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026F3A6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [BLISS] Use of Warning: header totransportadditionalstatusindications Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46C9A779.7000107@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Denis, > >If the answer is YES, then I have to ask WHY? Doing it that > way in sip > >just because the PSTN did it that way isn't a good enough > reason. (If > >the issue is gatewaying between the two models, then it may be worth > >discussing how that might be done.) > > Exactly - the interworking restrictions. Interworking unsynchronised > SUB/NOT with call progress messages on the ISDN side that carry this > indication is not the easiest thing to do. [JRE] I agree in this particular case, interworking NOTIFY would be difficult. However, I cannot get enthusiastic about a warning code for this purpose. 1. Call from PSTN. A warning code helps only if the called UA implements it, which for standard SIP devices is unlikely. There is just as much chance (maybe more chance) that a UA will issue a 182 as issue a warn code. Of course, if call waiting is done at the proxy (which I don't think is the best place to do it - I can't figure out exactly how it would work in all cases) the proxy could issue a warn code, but I don't see this as a mainstream case. 2. Call to PSTN. A standard SIP device as calling UA is unlikely to understand a warn code. There is probably more chance it will indicate something meaningful on receipt of a 182. John _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 20 16:33:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDw3-00020d-Kw; Mon, 20 Aug 2007 16:33:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INDw1-0001yK-TJ for bliss@ietf.org; Mon, 20 Aug 2007 16:33:14 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INDw0-0000If-J2 for bliss@ietf.org; Mon, 20 Aug 2007 16:33:13 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Aug 2007 16:33:10 -0400 X-IronPort-AV: i="4.19,285,1183348800"; d="scan'208"; a="129382283:sNHT52061636" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7KKXCNt000489; Mon, 20 Aug 2007 16:33:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7KKX1jY009260; Mon, 20 Aug 2007 20:33:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 16:33:04 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Aug 2007 16:33:04 -0400 Message-ID: <46C9FA80.9070203@cisco.com> Date: Mon, 20 Aug 2007 16:33:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] Use of Warning: header totransportadditionalstatusindications References: <46C9A779.7000107@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D026F3A6@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026F3A6@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Aug 2007 20:33:04.0441 (UTC) FILETIME=[4F460A90:01C7E369] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2488; t=1187641992; x=1188505992; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Use=20of=20Warning=3A=09header=09totranspor tadditionalstatusindications |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=+3qR94F7/QGYhVhSTvy3Aezg3TqP9AUWjy4XPuu+2lc=; b=UC9Oc4AN5bS8nL4PoTUXcLdK/VPaic2uOQuYlGDgRnmprVuhLKHMg/4nGxg+INNm7V6qSNYB M2sSHADpttrLPUOvaOZmrE7/2EsXIEvfl8Ze/UpMC9x3lm6rQbepBh/7; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Denis, How do you imagine this working (indicating forwarding is enabled locally)? My understanding is that the ISDN/whatever model is that this is signaled via a special dial tone, much as MWI is. As a result, it is signaled when you pick up the phone, *before* initiating a call. If you were to do this via a header in the response to an invite, then the device won't know about it until *after* a call has been dialed. So then when/how do you render an indication to the user? After he hangs up and then picks up the phone again? That doesn't seem very useful. You could use sub/not but refuse to maintain the subscription. Just send the initial notification with an indication the subscription has been terminated. This would only be useful for polling. But you could then have your device poll as soon as the device goes off-hook. But for any of this to matter it means that you have a sip phone connected through a gateway to an ISDN system that is handling the forwarding for it. That seems pretty peculiar. Wouldn't the forwarding for a sip phone normally be done by a sip server? Paul Elwell, John wrote: > Denis, > >>> If the answer is YES, then I have to ask WHY? Doing it that >> way in sip >>> just because the PSTN did it that way isn't a good enough >> reason. (If >>> the issue is gatewaying between the two models, then it may be worth >>> discussing how that might be done.) >> Exactly - the interworking restrictions. Interworking unsynchronised >> SUB/NOT with call progress messages on the ISDN side that carry this >> indication is not the easiest thing to do. > [JRE] I agree in this particular case, interworking NOTIFY would be > difficult. However, I cannot get enthusiastic about a warning code for > this purpose. > 1. Call from PSTN. A warning code helps only if the called UA implements > it, which for standard SIP devices is unlikely. There is just as much > chance (maybe more chance) that a UA will issue a 182 as issue a warn > code. Of course, if call waiting is done at the proxy (which I don't > think is the best place to do it - I can't figure out exactly how it > would work in all cases) the proxy could issue a warn code, but I don't > see this as a mainstream case. > 2. Call to PSTN. A standard SIP device as calling UA is unlikely to > understand a warn code. There is probably more chance it will indicate > something meaningful on receipt of a 182. > > John > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 21 08:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INSwt-00053u-Ur; Tue, 21 Aug 2007 08:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INSws-00053o-JK for bliss@ietf.org; Tue, 21 Aug 2007 08:35:06 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INSwr-0007Rr-1O for bliss@ietf.org; Tue, 21 Aug 2007 08:35:06 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Tue, 21 Aug 2007 14:34:59 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Aug 2007 14:34:54 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] Use of Warning: header totransportadditionalstatusindications Date: Tue, 21 Aug 2007 14:34:54 +0200 Message-Id: In-Reply-To: <46C9FA80.9070203@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header totransportadditionalstatusindications Thread-Index: AcfjaVt2AwYwS8toQGCTVZzDC1y2hAAhV7xA From: "Alexeitsev, D" To: , X-OriginalArrivalTime: 21 Aug 2007 12:34:54.0667 (UTC) FILETIME=[AD3FB1B0:01C7E3EF] X-Spam-Score: -1.0 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Thank you for the comments Paul >My understanding is that the ISDN/whatever model is that this is=20 >signaled via a special dial tone, much as MWI is. As a result, it is=20 >signaled when you pick up the phone, *before* initiating a call. There is a difference in implementation for analog and ISDN/GSM lines. Analog lines indeed have the tone applied immediately after off-hook. ISDN/GSM terminals provide the display information based on the generic notification indicator received in the call progress messages. There is no dial tone for GSM at all and ISDN supports dialling without going off-hook. That is why the off-hook tone can not be always applicable here. Greetings, Denis Alexeitsev=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 21 09:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTNu-0005f4-N7; Tue, 21 Aug 2007 09:03:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTNt-0005ex-AU for bliss@ietf.org; Tue, 21 Aug 2007 09:03:01 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INTNs-0004au-PZ for bliss@ietf.org; Tue, 21 Aug 2007 09:03:01 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Tue, 21 Aug 2007 15:02:42 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Aug 2007 15:02:41 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Aug 2007 15:02:40 +0200 Message-Id: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026F3A6@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwA== From: "Alexeitsev, D" To: , , X-OriginalArrivalTime: 21 Aug 2007 13:02:41.0398 (UTC) FILETIME=[8EB2A960:01C7E3F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: bliss@ietf.org Subject: [BLISS] Use of Warning: for Call-Waiting X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Comments below >1. Call from PSTN. A warning code helps only if the called UA implements >it, which for standard SIP devices is unlikely. There is just as much >chance (maybe more chance) that a UA will issue a 182 as issue a warn >code. Of course, if call waiting is done at the proxy (which I don't >think is the best place to do it - I can't figure out exactly how it >would work in all cases) the proxy could issue a warn code, but I don't >see this as a mainstream case. >2. Call to PSTN. A standard SIP device as calling UA is unlikely to >understand a warn code. There is probably more chance it will indicate >something meaningful on receipt of a 182. The UAs that are interested in this indication (Access Gateways, IAD, new SIP terminals) will implement the Warning: header and become new functionality. The ones that are not interested - legacy SIP terminals will not get harmed as Warning: header is optional. Is not it the rational way of adding new functionality? I still fail to see a technical problem with the call-waiting indication being transferred by means of Warning: or any other header (proposals?). Greetings, Denis Alexeitsev _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 21 09:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTWV-0002Tt-OK; Tue, 21 Aug 2007 09:11:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTWU-0002To-Ib for bliss@ietf.org; Tue, 21 Aug 2007 09:11:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INTWU-00059x-6n for bliss@ietf.org; Tue, 21 Aug 2007 09:11:54 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Aug 2007 09:11:52 -0400 X-IronPort-AV: i="4.19,289,1183348800"; d="scan'208"; a="129451310:sNHT47747726" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7LDBrHf019034; Tue, 21 Aug 2007 09:11:53 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7LDBejo021793; Tue, 21 Aug 2007 13:11:53 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:11:51 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 09:11:50 -0400 Message-ID: <46CAE496.409@cisco.com> Date: Tue, 21 Aug 2007 09:11:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Alexeitsev, D" Subject: Re: AW: [BLISS] Use of Warning: header totransportadditionalstatusindications References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Aug 2007 13:11:50.0930 (UTC) FILETIME=[D63E9720:01C7E3F4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1005; t=1187701913; x=1188565913; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20AW=3A=20[BLISS]=20Use=20of=20Warning=3A=09header=09to transportadditionalstatusindications |Sender:=20 |To:=20=22Alexeitsev,=20D=22=20; bh=A/3zQ+aWFzZI87LjbQntlvJxTO+/tOBKdjAcvafhnYc=; b=WzUcHmiQO8FC00XtCojPrtkOEFkEzNpkjdtdjuwKvhj3R/jGIw0ga4+f+SOBjHkLvDWd1/VY X7+DNtykAEeUj9xZcprc0ltdKEMBII1qVsMnm4RkXCTTMJaW8BiJgizD; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org So, if you forget that you enabled forwarding, and you don't get any calls for a long time, you will only discover the condition if you *make* a call??? That is not a service that I would be trying hard to emulate. Paul Alexeitsev, D wrote: > Thank you for the comments Paul > >> My understanding is that the ISDN/whatever model is that this is >> signaled via a special dial tone, much as MWI is. As a result, it is >> signaled when you pick up the phone, *before* initiating a call. > > There is a difference in implementation for analog and ISDN/GSM lines. > Analog lines indeed have the tone applied immediately after off-hook. > ISDN/GSM terminals provide the display information based on the generic > notification indicator received in the call progress messages. There is > no dial tone for GSM at all and ISDN supports dialling without going > off-hook. That is why the off-hook tone can not be always applicable > here. > > Greetings, > Denis Alexeitsev > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 21 09:21:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTfL-0004mm-OA; Tue, 21 Aug 2007 09:21:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTfK-0004mh-UC for bliss@ietf.org; Tue, 21 Aug 2007 09:21:02 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INTfK-0000Z0-DE for bliss@ietf.org; Tue, 21 Aug 2007 09:21:02 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7LDKwV15195; Tue, 21 Aug 2007 13:20:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Aug 2007 08:20:42 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116465CAB@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAAA7TQA References: <0D5F89FAC29E2C41B98A6A762007F5D026F3A6@GBNTHT12009MSX.gb002.siemens.net> From: "Brian Stucker" To: "Alexeitsev, D" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: bliss@ietf.org Subject: [BLISS] RE: Use of Warning: for Call-Waiting X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > Sent: Tuesday, August 21, 2007 8:03 AM > To: john.elwell@siemens.com; pkyzivat@cisco.com; Stucker,=20 > Brian (RICH1:AR00) > Cc: bliss@ietf.org > Subject: Use of Warning: for Call-Waiting >=20 > Comments below >=20 > >1. Call from PSTN. A warning code helps only if the called UA > implements > >it, which for standard SIP devices is unlikely. There is=20 > just as much=20 > >chance (maybe more chance) that a UA will issue a 182 as=20 > issue a warn=20 > >code. Of course, if call waiting is done at the proxy (which I don't=20 > >think is the best place to do it - I can't figure out exactly how it=20 > >would work in all cases) the proxy could issue a warn code,=20 > but I don't=20 > >see this as a mainstream case. > >2. Call to PSTN. A standard SIP device as calling UA is unlikely to=20 > >understand a warn code. There is probably more chance it=20 > will indicate=20 > >something meaningful on receipt of a 182. >=20 > The UAs that are interested in this indication (Access=20 > Gateways, IAD, new SIP terminals) will implement the Warning:=20 > header and become new functionality. The ones that are not=20 > interested - legacy SIP terminals will not get harmed as=20 > Warning: header is optional. Is not it the rational way of=20 > adding new functionality? >=20 > I still fail to see a technical problem with the call-waiting=20 > indication being transferred by means of Warning: or any=20 > other header (proposals?). The warning header is designed to carry human-consumable text indicating further information in the case of a problem arising while establishing a session. Take a look at section 20.43 and I think you'll quickly see that it was not intended to kick off a service and if, as you say, the UAs, gateways, IADs and new SIP terminals implement this, they'll not be implementing the intent of this SIP header.=20 On this basis, you could say that the Organization header is an appropriate place to put information to key off a service, or the Subject header. If everyone agrees that it's so, and the header isn't used for other essential functions, then it'll "work" but it won't be interoperable outside of your development community which I assume is important since you're posting to a list dedicated to solving interop problems. :) Alert-Info is more appropriate, but as a point in fact, if you go and talk to folks familiar with Alert-Info they'll tell you it might as well be a P-header because it's regularly stripped from messages and in order to make this work you'll have to specify a resource that is local to the device unless you want the devices to go to a box to play the appropriate tone. You could also investigate using early media along with RFC-4733 to denote playing a particular tone during call setup as another alternative. There are also techniques where you can have the BBUA point the call to a box that generates early media tones and announcements to generate the indication you are looking for in-band. As long as the client renders early media appropriately (and supports multiple responses to an offer correctly unless a relay is used) this will also work in many cases, but will break other services and may be fragile once forking is introduced into the mix (see my early media coping draft for a description of this type of service behavior and the associated problems). Regards, Brian _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 21 09:22:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTgl-00063l-HR; Tue, 21 Aug 2007 09:22:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INTgk-00061e-5E for bliss@ietf.org; Tue, 21 Aug 2007 09:22:30 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INTgj-0005Xe-JZ for bliss@ietf.org; Tue, 21 Aug 2007 09:22:30 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JN40090HL4YDY@siemenscomms.co.uk> for bliss@ietf.org; Tue, 21 Aug 2007 14:22:10 +0100 (BST) Date: Tue, 21 Aug 2007 14:22:23 +0100 From: "Elwell, John" In-reply-to: To: "Alexeitsev, D" , pkyzivat@cisco.com, bstucker@nortel.com Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026F3EC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAABPBQQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D026F3A6@GBNTHT12009MSX.gb002.siemens.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: bliss@ietf.org Subject: [BLISS] RE: Use of Warning: for Call-Waiting X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Denis, Below. John > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] > Sent: 21 August 2007 14:03 > To: Elwell, John; pkyzivat@cisco.com; bstucker@nortel.com > Cc: bliss@ietf.org > Subject: Use of Warning: for Call-Waiting > > Comments below > > >1. Call from PSTN. A warning code helps only if the called UA > implements > >it, which for standard SIP devices is unlikely. There is just as much > >chance (maybe more chance) that a UA will issue a 182 as issue a warn > >code. Of course, if call waiting is done at the proxy (which I don't > >think is the best place to do it - I can't figure out exactly how it > >would work in all cases) the proxy could issue a warn code, > but I don't > >see this as a mainstream case. > >2. Call to PSTN. A standard SIP device as calling UA is unlikely to > >understand a warn code. There is probably more chance it > will indicate > >something meaningful on receipt of a 182. > > The UAs that are interested in this indication (Access Gateways, IAD, > new SIP terminals) will implement the Warning: header and become new > functionality. The ones that are not interested - legacy SIP terminals > will not get harmed as Warning: header is optional. Is not it the > rational way of adding new functionality? [JRE] Sure, that is the normal way, but we only add new functionality when existing protocol mechanisms are inadequate. The advantage of using an existing mechanism is that existing devices just might support it. Hence my suggestion of 182. > > I still fail to see a technical problem with the call-waiting > indication > being transferred by means of Warning: or any other header > (proposals?). [JRE] Perhaps not a technical reason, but I am generally not a fan of the Warning header field. A lot of devices just ignore it, and asking a device that does not take account of the Warning header field when presenting information at its user interface to start taking it into account for this one case seems overkill. Had you thought about a new 18x response code if you regard 180 and 182 as unsuitable? > > Greetings, > Denis Alexeitsev > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 21 10:55:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INV8j-0008UP-0s; Tue, 21 Aug 2007 10:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INV8h-0008UI-Sx for bliss@ietf.org; Tue, 21 Aug 2007 10:55:27 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INV8g-0004XV-7F for bliss@ietf.org; Tue, 21 Aug 2007 10:55:27 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Tue, 21 Aug 2007 16:54:50 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Aug 2007 16:54:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Aug 2007 16:54:48 +0200 Message-Id: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026F3EC@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAABPBQQAAFxweA= From: "Huelsemann, Martin" To: , "Alexeitsev, D" , , X-OriginalArrivalTime: 21 Aug 2007 14:54:48.0729 (UTC) FILETIME=[387FE890:01C7E403] X-Spam-Score: -1.0 (-) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi, just for the Call Waiting case, I also think it would be the best = solution if this CW information for the caller is carried in the 180. = Because the basic situation is, that the call is presented to the = callee. But, as Brian said, it probably takes a littlebit longer until = the callee really answeres the call (e.g. because he first puts another = call on hold), so it's good to inform the caller about that fact. So if the caller is informed of the ringing with the 180 it's = sufficient, a very useful additional information for the caller is the = information about the CW case at the callee. So what we are looking for is something within the 180 to give the = caller additional CW information, which would at least make it possible = for the caller's terminal to render the information to the caller. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > Gesendet: Dienstag, 21. August 2007 15:22 > An: Alexeitsev, Denis; pkyzivat@cisco.com; bstucker@nortel.com > Cc: bliss@ietf.org > Betreff: [BLISS] RE: Use of Warning: for Call-Waiting >=20 >=20 > Denis, >=20 > Below. >=20 > John=20 >=20 > > -----Original Message----- > > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > > Sent: 21 August 2007 14:03 > > To: Elwell, John; pkyzivat@cisco.com; bstucker@nortel.com > > Cc: bliss@ietf.org > > Subject: Use of Warning: for Call-Waiting > >=20 > > Comments below > >=20 > > >1. Call from PSTN. A warning code helps only if the called UA > > implements > > >it, which for standard SIP devices is unlikely. There is=20 > just as much > > >chance (maybe more chance) that a UA will issue a 182 as=20 > issue a warn > > >code. Of course, if call waiting is done at the proxy=20 > (which I don't > > >think is the best place to do it - I can't figure out=20 > exactly how it > > >would work in all cases) the proxy could issue a warn code,=20 > > but I don't > > >see this as a mainstream case. > > >2. Call to PSTN. A standard SIP device as calling UA is unlikely to > > >understand a warn code. There is probably more chance it=20 > > will indicate > > >something meaningful on receipt of a 182. > >=20 > > The UAs that are interested in this indication (Access=20 > Gateways, IAD, > > new SIP terminals) will implement the Warning: header and become new > > functionality. The ones that are not interested - legacy=20 > SIP terminals > > will not get harmed as Warning: header is optional. Is not it the > > rational way of adding new functionality? > [JRE] Sure, that is the normal way, but we only add new functionality > when existing protocol mechanisms are inadequate. The=20 > advantage of using > an existing mechanism is that existing devices just might support it. > Hence my suggestion of 182. >=20 > >=20 > > I still fail to see a technical problem with the call-waiting=20 > > indication > > being transferred by means of Warning: or any other header=20 > > (proposals?). > [JRE] Perhaps not a technical reason, but I am generally not a fan of > the Warning header field. A lot of devices just ignore it,=20 > and asking a > device that does not take account of the Warning header field when > presenting information at its user interface to start taking it into > account for this one case seems overkill. Had you thought about a new > 18x response code if you regard 180 and 182 as unsuitable? >=20 > >=20 > > Greetings, > > Denis Alexeitsev > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 21 12:33:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWfi-00060t-OS; Tue, 21 Aug 2007 12:33:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWfh-000602-Qn for bliss@ietf.org; Tue, 21 Aug 2007 12:33:37 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INWfh-0004jE-4b for bliss@ietf.org; Tue, 21 Aug 2007 12:33:37 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7LGXWV10341; Tue, 21 Aug 2007 16:33:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] RE: Use of Warning: for Call-Waiting Date: Tue, 21 Aug 2007 11:33:31 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371164663B7@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAABPBQQAAFxweAABTuKUA== References: <0D5F89FAC29E2C41B98A6A762007F5D026F3EC@GBNTHT12009MSX.gb002.siemens.net> From: "Brian Stucker" To: "Huelsemann, Martin" , , "Alexeitsev, D" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Martin, I'm not aware of an appropriate header to convey this information in a = 180. I believe that's why John and I were mentioning using a different = response code to convey the difference in the call progression (much = like we have 183 versus 180 today). The downside is that terminals probably won't recognize a CWT specific = 18x response, but unless they're supporting a mechanism for conveying = this information today, they won't recognize an alternate method of = signaling this either. So if any given way of doing this has the = downside that it requires uptake by devices to support it, then we = should try to pick the best possible solution to the problem rather than = being a slave to a non-existant backwards compatability problem. I've typically seen this type of service implemented using an = application server/BBUA that is manipulating the early media streams = presented to the originator. The reason for doing this wasn't that it = was particularly brilliant, but that it required the terminals to do = very little other than render the early media RTP that was sent to them. The downside to this approach is that it creates conditions to aggravate = the existing problems within SIP with respect to early media, and in = particular, interworking PSTN early media with a SIP device. Regards, Brian=20 > -----Original Message----- > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net]=20 > Sent: Tuesday, August 21, 2007 9:55 AM > To: john.elwell@siemens.com; Alexeitsev, D;=20 > pkyzivat@cisco.com; Stucker, Brian (RICH1:AR00) > Cc: bliss@ietf.org > Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting >=20 > Hi, >=20 > just for the Call Waiting case, I also think it would be the=20 > best solution if this CW information for the caller is=20 > carried in the 180. Because the basic situation is, that the=20 > call is presented to the callee. But, as Brian said, it=20 > probably takes a littlebit longer until the callee really=20 > answeres the call (e.g. because he first puts another call on=20 > hold), so it's good to inform the caller about that fact. > So if the caller is informed of the ringing with the 180 it's=20 > sufficient, a very useful additional information for the=20 > caller is the information about the CW case at the callee. >=20 > So what we are looking for is something within the 180 to=20 > give the caller additional CW information, which would at=20 > least make it possible for the caller's terminal to render=20 > the information to the caller. >=20 >=20 > Regards, Martin >=20 >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > Gesendet: Dienstag, 21. August 2007 15:22 > > An: Alexeitsev, Denis; pkyzivat@cisco.com; bstucker@nortel.com > > Cc: bliss@ietf.org > > Betreff: [BLISS] RE: Use of Warning: for Call-Waiting > >=20 > >=20 > > Denis, > >=20 > > Below. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] > > > Sent: 21 August 2007 14:03 > > > To: Elwell, John; pkyzivat@cisco.com; bstucker@nortel.com > > > Cc: bliss@ietf.org > > > Subject: Use of Warning: for Call-Waiting > > >=20 > > > Comments below > > >=20 > > > >1. Call from PSTN. A warning code helps only if the called UA > > > implements > > > >it, which for standard SIP devices is unlikely. There is > > just as much > > > >chance (maybe more chance) that a UA will issue a 182 as > > issue a warn > > > >code. Of course, if call waiting is done at the proxy > > (which I don't > > > >think is the best place to do it - I can't figure out > > exactly how it > > > >would work in all cases) the proxy could issue a warn code, > > > but I don't > > > >see this as a mainstream case. > > > >2. Call to PSTN. A standard SIP device as calling UA is=20 > unlikely to=20 > > > >understand a warn code. There is probably more chance it > > > will indicate > > > >something meaningful on receipt of a 182. > > >=20 > > > The UAs that are interested in this indication (Access > > Gateways, IAD, > > > new SIP terminals) will implement the Warning: header and=20 > become new=20 > > > functionality. The ones that are not interested - legacy > > SIP terminals > > > will not get harmed as Warning: header is optional. Is not it the=20 > > > rational way of adding new functionality? > > [JRE] Sure, that is the normal way, but we only add new=20 > functionality=20 > > when existing protocol mechanisms are inadequate. The advantage of=20 > > using an existing mechanism is that existing devices just might=20 > > support it. > > Hence my suggestion of 182. > >=20 > > >=20 > > > I still fail to see a technical problem with the call-waiting=20 > > > indication being transferred by means of Warning: or any other=20 > > > header (proposals?). > > [JRE] Perhaps not a technical reason, but I am generally=20 > not a fan of=20 > > the Warning header field. A lot of devices just ignore it,=20 > and asking=20 > > a device that does not take account of the Warning header=20 > field when=20 > > presenting information at its user interface to start=20 > taking it into=20 > > account for this one case seems overkill. Had you thought=20 > about a new=20 > > 18x response code if you regard 180 and 182 as unsuitable? > >=20 > > >=20 > > > Greetings, > > > Denis Alexeitsev > > >=20 > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 21 12:43:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWp7-0004rd-Dt; Tue, 21 Aug 2007 12:43:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INWp5-0004rX-MN for bliss@ietf.org; Tue, 21 Aug 2007 12:43:19 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INWp4-0000Jk-5G for bliss@ietf.org; Tue, 21 Aug 2007 12:43:19 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JN400C5JUEV96@siemenscomms.co.uk> for bliss@ietf.org; Tue, 21 Aug 2007 17:42:32 +0100 (BST) Date: Tue, 21 Aug 2007 17:42:45 +0100 From: "Elwell, John" Subject: RE: [BLISS] RE: Use of Warning: for Call-Waiting In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA4371164663B7@zrc2hxm2.corp.nortel.com> To: Brian Stucker , "Huelsemann, Martin" , "Alexeitsev, D" , pkyzivat@cisco.com Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026F420@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [BLISS] RE: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAABPBQQAAFxweAABTuKUAAAT2JQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D026F3EC@GBNTHT12009MSX.gb002.siemens.net> <6FC4416DDE56C44DA0AEE67BC7CA4371164663B7@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I wouldn't go down the media server path. I prefer an indication in a = 18x response that the UA can render by whatever means is appropriate = (e.g., in the language of the caller). I thought 182 would fit this, but = I guess a further consideration is what do you want an existing UA to = do? If you wish it to apply ringback tone as a result, then 180 seems to = be the appropriate response code. If you don't want it to give ringback = tone, then don't use 180. Assuming we choose 180, as Martin suggested in his last message, then I = don't particularly like using the Warning header field for this purpose, = but I don't have an alternative suggestion (inventing a new header field = for this also seems excessive). So let's see what others prefer. John > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortel.com]=20 > Sent: 21 August 2007 17:34 > To: Huelsemann, Martin; Elwell, John; Alexeitsev, D;=20 > pkyzivat@cisco.com > Cc: bliss@ietf.org > Subject: RE: [BLISS] RE: Use of Warning: for Call-Waiting >=20 > Hi Martin, >=20 > I'm not aware of an appropriate header to convey this=20 > information in a 180. I believe that's why John and I were=20 > mentioning using a different response code to convey the=20 > difference in the call progression (much like we have 183=20 > versus 180 today). >=20 > The downside is that terminals probably won't recognize a CWT=20 > specific 18x response, but unless they're supporting a=20 > mechanism for conveying this information today, they won't=20 > recognize an alternate method of signaling this either. So if=20 > any given way of doing this has the downside that it requires=20 > uptake by devices to support it, then we should try to pick=20 > the best possible solution to the problem rather than being a=20 > slave to a non-existant backwards compatability problem. >=20 > I've typically seen this type of service implemented using an=20 > application server/BBUA that is manipulating the early media=20 > streams presented to the originator. The reason for doing=20 > this wasn't that it was particularly brilliant, but that it=20 > required the terminals to do very little other than render=20 > the early media RTP that was sent to them. >=20 > The downside to this approach is that it creates conditions=20 > to aggravate the existing problems within SIP with respect to=20 > early media, and in particular, interworking PSTN early media=20 > with a SIP device. >=20 > Regards, > Brian=20 >=20 > > -----Original Message----- > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net]=20 > > Sent: Tuesday, August 21, 2007 9:55 AM > > To: john.elwell@siemens.com; Alexeitsev, D;=20 > > pkyzivat@cisco.com; Stucker, Brian (RICH1:AR00) > > Cc: bliss@ietf.org > > Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting > >=20 > > Hi, > >=20 > > just for the Call Waiting case, I also think it would be the=20 > > best solution if this CW information for the caller is=20 > > carried in the 180. Because the basic situation is, that the=20 > > call is presented to the callee. But, as Brian said, it=20 > > probably takes a littlebit longer until the callee really=20 > > answeres the call (e.g. because he first puts another call on=20 > > hold), so it's good to inform the caller about that fact. > > So if the caller is informed of the ringing with the 180 it's=20 > > sufficient, a very useful additional information for the=20 > > caller is the information about the CW case at the callee. > >=20 > > So what we are looking for is something within the 180 to=20 > > give the caller additional CW information, which would at=20 > > least make it possible for the caller's terminal to render=20 > > the information to the caller. > >=20 > >=20 > > Regards, Martin > >=20 > >=20 > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Elwell, John [mailto:john.elwell@siemens.com] > > > Gesendet: Dienstag, 21. August 2007 15:22 > > > An: Alexeitsev, Denis; pkyzivat@cisco.com; bstucker@nortel.com > > > Cc: bliss@ietf.org > > > Betreff: [BLISS] RE: Use of Warning: for Call-Waiting > > >=20 > > >=20 > > > Denis, > > >=20 > > > Below. > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] > > > > Sent: 21 August 2007 14:03 > > > > To: Elwell, John; pkyzivat@cisco.com; bstucker@nortel.com > > > > Cc: bliss@ietf.org > > > > Subject: Use of Warning: for Call-Waiting > > > >=20 > > > > Comments below > > > >=20 > > > > >1. Call from PSTN. A warning code helps only if the called UA > > > > implements > > > > >it, which for standard SIP devices is unlikely. There is > > > just as much > > > > >chance (maybe more chance) that a UA will issue a 182 as > > > issue a warn > > > > >code. Of course, if call waiting is done at the proxy > > > (which I don't > > > > >think is the best place to do it - I can't figure out > > > exactly how it > > > > >would work in all cases) the proxy could issue a warn code, > > > > but I don't > > > > >see this as a mainstream case. > > > > >2. Call to PSTN. A standard SIP device as calling UA is=20 > > unlikely to=20 > > > > >understand a warn code. There is probably more chance it > > > > will indicate > > > > >something meaningful on receipt of a 182. > > > >=20 > > > > The UAs that are interested in this indication (Access > > > Gateways, IAD, > > > > new SIP terminals) will implement the Warning: header and=20 > > become new=20 > > > > functionality. The ones that are not interested - legacy > > > SIP terminals > > > > will not get harmed as Warning: header is optional. Is=20 > not it the=20 > > > > rational way of adding new functionality? > > > [JRE] Sure, that is the normal way, but we only add new=20 > > functionality=20 > > > when existing protocol mechanisms are inadequate. The=20 > advantage of=20 > > > using an existing mechanism is that existing devices just might=20 > > > support it. > > > Hence my suggestion of 182. > > >=20 > > > >=20 > > > > I still fail to see a technical problem with the call-waiting=20 > > > > indication being transferred by means of Warning: or any other=20 > > > > header (proposals?). > > > [JRE] Perhaps not a technical reason, but I am generally=20 > > not a fan of=20 > > > the Warning header field. A lot of devices just ignore it,=20 > > and asking=20 > > > a device that does not take account of the Warning header=20 > > field when=20 > > > presenting information at its user interface to start=20 > > taking it into=20 > > > account for this one case seems overkill. Had you thought=20 > > about a new=20 > > > 18x response code if you regard 180 and 182 as unsuitable? > > >=20 > > > >=20 > > > > Greetings, > > > > Denis Alexeitsev > > > >=20 > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/bliss > > >=20 > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 21 14:01:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INY2c-0000Z8-0t; Tue, 21 Aug 2007 14:01:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INY2Z-0000Z1-Vg for bliss@ietf.org; Tue, 21 Aug 2007 14:01:19 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INY2Y-0002dB-RK for bliss@ietf.org; Tue, 21 Aug 2007 14:01:19 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2007 14:01:19 -0400 X-IronPort-AV: i="4.19,290,1183348800"; d="scan'208"; a="68609480:sNHT64954712" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7LI1IEj026608; Tue, 21 Aug 2007 14:01:18 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7LI0vjk018167; Tue, 21 Aug 2007 18:01:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 14:01:09 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Aug 2007 14:01:09 -0400 Message-ID: <46CB2866.6030009@cisco.com> Date: Tue, 21 Aug 2007 14:01:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Elwell, John" Subject: Re: [BLISS] RE: Use of Warning: for Call-Waiting References: <0D5F89FAC29E2C41B98A6A762007F5D026F3EC@GBNTHT12009MSX.gb002.siemens.net> <6FC4416DDE56C44DA0AEE67BC7CA4371164663B7@zrc2hxm2.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D026F420@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026F420@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Aug 2007 18:01:09.0256 (UTC) FILETIME=[409CF080:01C7E41D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7577; t=1187719278; x=1188583278; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20RE=3A=20Use=20of=20Warning=3A=20for=20Call- Waiting |Sender:=20 |To:=20=22Elwell,=20John=22=20; bh=NPknIq4prY9NqeE4A4STRZHoK0yfwoc701fed98ncqc=; b=qp8lDwGibaNR+xr5BKYyPbteDlj4/JUzqtyUOTZ4k1qGHEjAURxxvtSfPA5ApQCRxuTzM9gg 1YuYX48yGlDSGynovKwnOsEn4RtTjurPwli9D7ogmFfJKaqVnvgCmJTy; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: bliss@ietf.org, "Alexeitsev, D" , "Huelsemann, Martin" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org IMO this is all about "a distinction without a difference". I see no useful reason to either convey or render this information. There are multitudes of ways in which a UAS (or group of UASs associated with an AOR) and the users of those device(s) can choose to multiplex themselves among multiple incoming calls. Does it make sense to try to enumerate those, signal which one is being applied back to the UAC, and expect the UAC to signal it to the caller? I don't think so. In this case the intent is to single out a particular way of doing the multiplexing and signal that one. Why is it more important than any other way? We already have something to give you info about the status of the callee - presence. It can tell you "on the phone" and a host of other things. Paul Elwell, John wrote: > I wouldn't go down the media server path. I prefer an indication in a 18x response that the UA can render by whatever means is appropriate (e.g., in the language of the caller). I thought 182 would fit this, but I guess a further consideration is what do you want an existing UA to do? If you wish it to apply ringback tone as a result, then 180 seems to be the appropriate response code. If you don't want it to give ringback tone, then don't use 180. > > Assuming we choose 180, as Martin suggested in his last message, then I don't particularly like using the Warning header field for this purpose, but I don't have an alternative suggestion (inventing a new header field for this also seems excessive). So let's see what others prefer. > > John > >> -----Original Message----- >> From: Brian Stucker [mailto:bstucker@nortel.com] >> Sent: 21 August 2007 17:34 >> To: Huelsemann, Martin; Elwell, John; Alexeitsev, D; >> pkyzivat@cisco.com >> Cc: bliss@ietf.org >> Subject: RE: [BLISS] RE: Use of Warning: for Call-Waiting >> >> Hi Martin, >> >> I'm not aware of an appropriate header to convey this >> information in a 180. I believe that's why John and I were >> mentioning using a different response code to convey the >> difference in the call progression (much like we have 183 >> versus 180 today). >> >> The downside is that terminals probably won't recognize a CWT >> specific 18x response, but unless they're supporting a >> mechanism for conveying this information today, they won't >> recognize an alternate method of signaling this either. So if >> any given way of doing this has the downside that it requires >> uptake by devices to support it, then we should try to pick >> the best possible solution to the problem rather than being a >> slave to a non-existant backwards compatability problem. >> >> I've typically seen this type of service implemented using an >> application server/BBUA that is manipulating the early media >> streams presented to the originator. The reason for doing >> this wasn't that it was particularly brilliant, but that it >> required the terminals to do very little other than render >> the early media RTP that was sent to them. >> >> The downside to this approach is that it creates conditions >> to aggravate the existing problems within SIP with respect to >> early media, and in particular, interworking PSTN early media >> with a SIP device. >> >> Regards, >> Brian >> >>> -----Original Message----- >>> From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] >>> Sent: Tuesday, August 21, 2007 9:55 AM >>> To: john.elwell@siemens.com; Alexeitsev, D; >>> pkyzivat@cisco.com; Stucker, Brian (RICH1:AR00) >>> Cc: bliss@ietf.org >>> Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting >>> >>> Hi, >>> >>> just for the Call Waiting case, I also think it would be the >>> best solution if this CW information for the caller is >>> carried in the 180. Because the basic situation is, that the >>> call is presented to the callee. But, as Brian said, it >>> probably takes a littlebit longer until the callee really >>> answeres the call (e.g. because he first puts another call on >>> hold), so it's good to inform the caller about that fact. >>> So if the caller is informed of the ringing with the 180 it's >>> sufficient, a very useful additional information for the >>> caller is the information about the CW case at the callee. >>> >>> So what we are looking for is something within the 180 to >>> give the caller additional CW information, which would at >>> least make it possible for the caller's terminal to render >>> the information to the caller. >>> >>> >>> Regards, Martin >>> >>> >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Elwell, John [mailto:john.elwell@siemens.com] >>>> Gesendet: Dienstag, 21. August 2007 15:22 >>>> An: Alexeitsev, Denis; pkyzivat@cisco.com; bstucker@nortel.com >>>> Cc: bliss@ietf.org >>>> Betreff: [BLISS] RE: Use of Warning: for Call-Waiting >>>> >>>> >>>> Denis, >>>> >>>> Below. >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] >>>>> Sent: 21 August 2007 14:03 >>>>> To: Elwell, John; pkyzivat@cisco.com; bstucker@nortel.com >>>>> Cc: bliss@ietf.org >>>>> Subject: Use of Warning: for Call-Waiting >>>>> >>>>> Comments below >>>>> >>>>>> 1. Call from PSTN. A warning code helps only if the called UA >>>>> implements >>>>>> it, which for standard SIP devices is unlikely. There is >>>> just as much >>>>>> chance (maybe more chance) that a UA will issue a 182 as >>>> issue a warn >>>>>> code. Of course, if call waiting is done at the proxy >>>> (which I don't >>>>>> think is the best place to do it - I can't figure out >>>> exactly how it >>>>>> would work in all cases) the proxy could issue a warn code, >>>>> but I don't >>>>>> see this as a mainstream case. >>>>>> 2. Call to PSTN. A standard SIP device as calling UA is >>> unlikely to >>>>>> understand a warn code. There is probably more chance it >>>>> will indicate >>>>>> something meaningful on receipt of a 182. >>>>> The UAs that are interested in this indication (Access >>>> Gateways, IAD, >>>>> new SIP terminals) will implement the Warning: header and >>> become new >>>>> functionality. The ones that are not interested - legacy >>>> SIP terminals >>>>> will not get harmed as Warning: header is optional. Is >> not it the >>>>> rational way of adding new functionality? >>>> [JRE] Sure, that is the normal way, but we only add new >>> functionality >>>> when existing protocol mechanisms are inadequate. The >> advantage of >>>> using an existing mechanism is that existing devices just might >>>> support it. >>>> Hence my suggestion of 182. >>>> >>>>> I still fail to see a technical problem with the call-waiting >>>>> indication being transferred by means of Warning: or any other >>>>> header (proposals?). >>>> [JRE] Perhaps not a technical reason, but I am generally >>> not a fan of >>>> the Warning header field. A lot of devices just ignore it, >>> and asking >>>> a device that does not take account of the Warning header >>> field when >>>> presenting information at its user interface to start >>> taking it into >>>> account for this one case seems overkill. Had you thought >>> about a new >>>> 18x response code if you regard 180 and 182 as unsuitable? >>>> >>>>> Greetings, >>>>> Denis Alexeitsev >>>>> >>>> _______________________________________________ >>>> BLISS mailing list >>>> BLISS@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/bliss >>>> > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 22 10:26:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrAP-0003XB-Ai; Wed, 22 Aug 2007 10:26:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrAN-0003Rj-RJ for bliss@ietf.org; Wed, 22 Aug 2007 10:26:39 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INrAM-0002h4-Ug for bliss@ietf.org; Wed, 22 Aug 2007 10:26:39 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Wed, 22 Aug 2007 16:26:36 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Aug 2007 16:26:36 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting Date: Wed, 22 Aug 2007 16:26:35 +0200 Message-Id: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116465CAB@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAAA7TQAADSZhlA= From: "Alexeitsev, D" To: , , X-OriginalArrivalTime: 22 Aug 2007 14:26:36.0147 (UTC) FILETIME=[720E2430:01C7E4C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Comments inline=20 >On this basis, you could say that the Organization header is an >appropriate place to put information to key off a service, or the >Subject header. If everyone agrees that it's so, and the header isn't >used for other essential functions, then it'll "work" but it won't be >interoperable outside of your development community which I assume is >important since you're posting to a list dedicated to solving interop >problems. :) Well my little understanding of standard bodies tells me that if everyone agrees to use the Organization header, than it is the standard. Having no standard at all is even less beneficial to interoperability isn't it? :) The IETF developer community and TISPAN/3GPP industry community together cover probably 70% of the telecom industry, so everything we define here is the de facto standard. >You could also investigate using early media along with RFC-4733 to denote playing a particular tone during call setup as another alternative. It is not about the tones, as I've pointed out the ISDN and GSM terminals provide a visual indication, so a parameter is needed. I'm not particularly keen on the Warning header but used it as an example to boost the discussion. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 22 10:36:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrK0-0002jI-3Y; Wed, 22 Aug 2007 10:36:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrJz-0002jD-4t for bliss@ietf.org; Wed, 22 Aug 2007 10:36:35 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INrJy-0002um-Ll for bliss@ietf.org; Wed, 22 Aug 2007 10:36:35 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Wed, 22 Aug 2007 16:36:33 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Aug 2007 16:36:33 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 22 Aug 2007 16:36:32 +0200 Message-Id: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D026F3EC@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAABPBQQADTNLlA= From: "Alexeitsev, D" To: , , X-OriginalArrivalTime: 22 Aug 2007 14:36:33.0177 (UTC) FILETIME=[D5E9B090:01C7E4C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: bliss@ietf.org Subject: [BLISS] AW: Use of Warning: for Call-Waiting X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Comments below >[JRE] Perhaps not a technical reason, but I am generally not a fan of >the Warning header field. A lot of devices just ignore it, and asking a >device that does not take account of the Warning header field when >presenting information at its user interface to start taking it into >account for this one case seems overkill. Had you thought about a new >18x response code if you regard 180 and 182 as unsuitable? If new response codes are defined, than we have an undefined behaviour at the deployed UAs. How would an IAD or a soft client react when it receives for example a 187 response? Would it=20 A) apply the ring tone, B) default special tone, C) Nothing, as it only implements a ring tone with static mapping to the 180 That is why I think a header for existing 180, 183 responses would be more appropriate. Greetings, Denis Alexeitsev _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 22 10:41:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrP1-0005Ql-68; Wed, 22 Aug 2007 10:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrP0-0005Qf-T3 for bliss@ietf.org; Wed, 22 Aug 2007 10:41:46 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INrOz-00055Z-9Q for bliss@ietf.org; Wed, 22 Aug 2007 10:41:46 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Wed, 22 Aug 2007 16:41:44 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Aug 2007 16:41:43 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: [BLISS] Use of Warning: header totransportadditionalstatusindications Date: Wed, 22 Aug 2007 16:41:42 +0200 Message-Id: In-Reply-To: <46CAE496.409@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [BLISS] Use of Warning: header totransportadditionalstatusindications Thread-Index: Acfj9sfC94CZeCjURg2djBsjhXE73wA0x5vg From: "Alexeitsev, D" To: X-OriginalArrivalTime: 22 Aug 2007 14:41:43.0530 (UTC) FILETIME=[8EE5CCA0:01C7E4CA] X-Spam-Score: -1.0 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Comments below >So, if you forget that you enabled forwarding, and you don't get any=20 >calls for a long time, you will only discover the condition if you=20 >*make* a call??? Correct >That is not a service that I would be trying hard to emulate. I would be happy to discuss a proposal on how to make the service better without making interworking impossible. Greetings, Denis Alexeitsev _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 22 10:55:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrcS-0006XT-Or; Wed, 22 Aug 2007 10:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrcR-0006XA-Mj for bliss@ietf.org; Wed, 22 Aug 2007 10:55:39 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INrcR-0005Oa-AK for bliss@ietf.org; Wed, 22 Aug 2007 10:55:39 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7MEtYD09867; Wed, 22 Aug 2007 14:55:34 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Aug 2007 09:55:31 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371164A99D5@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAABPBQQADTNLlAAAGTQwA== References: <0D5F89FAC29E2C41B98A6A762007F5D026F3EC@GBNTHT12009MSX.gb002.siemens.net> From: "Brian Stucker" To: "Alexeitsev, D" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: bliss@ietf.org Subject: [BLISS] RE: Use of Warning: for Call-Waiting X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > Sent: Wednesday, August 22, 2007 9:37 AM > To: john.elwell@siemens.com; pkyzivat@cisco.com; Stucker,=20 > Brian (RICH1:AR00) > Cc: bliss@ietf.org > Subject: AW: Use of Warning: for Call-Waiting >=20 > Comments below >=20 > >[JRE] Perhaps not a technical reason, but I am generally not=20 > a fan of=20 > >the Warning header field. A lot of devices just ignore it,=20 > and asking a=20 > >device that does not take account of the Warning header field when=20 > >presenting information at its user interface to start taking it into=20 > >account for this one case seems overkill. Had you thought=20 > about a new=20 > >18x response code if you regard 180 and 182 as unsuitable? >=20 > If new response codes are defined, than we have an undefined=20 > behaviour at the deployed UAs. How would an IAD or a soft=20 > client react when it receives for example a 187 response? >=20 > Would it > A) apply the ring tone, > B) default special tone, > C) Nothing, as it only implements a ring tone with static=20 > mapping to the 180 Probably C. But sending a 183 after a 180 is likely to be just as provocative an action at the UA as sending a second 180 or sending the example 187 response. What I don't think we want to do here is have 187 mean ring tone A, 188 mean special tone B, 186 mean some other tone C except if you're in Antartica in which case it means tone R, etc, etc... Ringback procedures in SIP implementations are pretty fragile. >=20 > That is why I think a header for existing 180, 183 responses=20 > would be more appropriate. >=20 > Greetings, > Denis Alexeitsev >=20 >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 22 11:06:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrmY-0007n4-So; Wed, 22 Aug 2007 11:06:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INrmW-0007mh-U9 for bliss@ietf.org; Wed, 22 Aug 2007 11:06:04 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INrmW-0003ct-7g for bliss@ietf.org; Wed, 22 Aug 2007 11:06:04 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7MF3vt08177; Wed, 22 Aug 2007 15:03:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] RE: Use of Warning: for Call-Waiting Date: Wed, 22 Aug 2007 10:05:58 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371164A9A33@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAAA7TQAADSZhlAAAYRkIA== References: <6FC4416DDE56C44DA0AEE67BC7CA437116465CAB@zrc2hxm2.corp.nortel.com> From: "Brian Stucker" To: "Alexeitsev, D" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > Sent: Wednesday, August 22, 2007 9:27 AM > To: Stucker, Brian (RICH1:AR00); john.elwell@siemens.com;=20 > pkyzivat@cisco.com > Cc: bliss@ietf.org > Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting >=20 > Comments inline=20 >=20 > >On this basis, you could say that the Organization header is an=20 > >appropriate place to put information to key off a service, or the=20 > >Subject header. If everyone agrees that it's so, and the=20 > header isn't=20 > >used for other essential functions, then it'll "work" but it=20 > won't be=20 > >interoperable outside of your development community which I=20 > assume is=20 > >important since you're posting to a list dedicated to=20 > solving interop=20 > >problems. :) >=20 > Well my little understanding of standard bodies tells me that=20 > if everyone agrees to use the Organization header, than it is=20 > the standard. Just because someone writes something down doesn't make it a good idea. :) > Having no standard at all is even less beneficial to=20 > interoperability isn't it? :) The IETF developer community=20 > and TISPAN/3GPP industry community together cover probably=20 > 70% of the telecom industry, so everything we define here is=20 > the de facto standard. >=20 > >You could also investigate using early media along with RFC-4733 to > denote playing a particular tone during call setup as another=20 > alternative. >=20 > It is not about the tones, as I've pointed out the ISDN and=20 > GSM terminals provide a visual indication, so a parameter is=20 > needed. I'm not particularly keen on the Warning header but=20 > used it as an example to boost the discussion. I had not caught the need for a visual indication. I thought you were trying to put a tone or stutter into the existing ringback heard by the originator. I think your requirements here really fall into a gap. Some folks will be opposed to the service itself (which, although I don't particularly like the service you describe I don't think it should prohibit the discussion of an acceptable way of signaling what you're looking for), some folks will not want to add yet-another-header and there's not a real great match that I'm aware of in an existing header to solve your issue, some folks will want to overload the semantics of an existing header or response code or define a new response code... For call diversion indication to a terminal, I think using 3265 is really the best solution. When/how it gets rendered will leave you with options going forward. For gateway to gateway communication though, I can see where this would be more difficult to deal with but not impossible though. It would look something like the SMDI indications that come back for MWI that the network is able to process. Unless we think this is an area of the protocol that is likely to grow in the future (I doubt that it will ever extend beyond PSTN interworking) you're probably looking at using a new p-header quite honestly. For Call waiting, I'm not sure why a 182 and some specified behavor at the UA wouldn't do the trick. Regards, Brian _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 22 11:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsFs-0006la-Uw; Wed, 22 Aug 2007 11:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INsFr-0006lP-9H for bliss@ietf.org; Wed, 22 Aug 2007 11:36:23 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INsFp-0006Kc-NV for bliss@ietf.org; Wed, 22 Aug 2007 11:36:23 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Wed, 22 Aug 2007 17:36:18 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Aug 2007 17:36:17 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting Date: Wed, 22 Aug 2007 17:36:16 +0200 Message-Id: In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371164A99D5@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: Use of Warning: for Call-Waiting Thread-Index: AcfjN93MJi+AkpCWQem8dbXLrA6ZWAAC4niAAAdzSxAAI87QwAABPBQQADTNLlAAAGTQwAABRTqw From: "Alexeitsev, D" To: , , X-OriginalArrivalTime: 22 Aug 2007 15:36:17.0222 (UTC) FILETIME=[2E2B8E60:01C7E4D2] X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Response below > If new response codes are defined, than we have an undefined=20 > behaviour at the deployed UAs. How would an IAD or a soft=20 > client react when it receives for example a 187 response? >=20 > Would it > A) apply the ring tone, > B) default special tone, > C) Nothing, as it only implements a ring tone with static=20 > mapping to the 180 >Ringback procedures in SIP implementations are pretty fragile. That is why I don't want to mess with the existing procedures, but to extend the 180 with an indication. If a UA will implement the new parameter it will be able to provide an additional service to the user. If not, then well known service will not get corrupted. Greetings, Denis Alexeistev _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 22 13:54:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INuPb-0007pa-5j; Wed, 22 Aug 2007 13:54:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INuPa-0007pU-HE for bliss@ietf.org; Wed, 22 Aug 2007 13:54:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1INuPZ-0007A6-S4 for bliss@ietf.org; Wed, 22 Aug 2007 13:54:34 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Aug 2007 13:54:33 -0400 X-IronPort-AV: i="4.19,295,1183348800"; d="scan'208"; a="129603390:sNHT54269568" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7MHsXLP003497; Wed, 22 Aug 2007 13:54:33 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7MHs1nj018461; Wed, 22 Aug 2007 17:54:29 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 13:53:56 -0400 Received: from [161.44.174.244] ([161.44.174.244]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 13:53:55 -0400 Message-ID: <46CC7830.6030504@cisco.com> Date: Wed, 22 Aug 2007 13:53:52 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] RE: Use of Warning: for Call-Waiting References: <6FC4416DDE56C44DA0AEE67BC7CA437116465CAB@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA4371164A9A33@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371164A9A33@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2007 17:53:55.0924 (UTC) FILETIME=[68BD7940:01C7E4E5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3924; t=1187805273; x=1188669273; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20RE=3A=20Use=20of=20Warning=3A=20for=20Call- Waiting |Sender:=20 |To:=20Brian=20Stucker=20; bh=mzFejVegEdDTSJEaBqJGAjVBvWXY1VhiwZWxG7Zp3g8=; b=bHSlM6ry7iZeVZaKurycgmuCHuw1JRFEMzJDdCSa8KiXrv/EfGwxeh4g5JezDMQ9iepJN5Jy oDIBKMBp9KFfCnSbVNiEbVVr7jpcJyyCKwC3/Au5x7gODzXSAp85jjbJ; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Based on what I have heard so far I do think that Alert-Info is the best fit. I have proposed before, in other fora, that Alert-Info be used with a URN. It is then up to the recipient to understand the meaning of the URN - there are no games with trying to reference local files on the device, or forcing network access. Certainly Alert-Info may be stripped in some environments, but as described, this should not be a problem in the environments where this is desired. Using A-I with a URN you just have to go find, or define, a suitable family of URNs to denote the things you want to convey. Paul Brian Stucker wrote: > > >> -----Original Message----- >> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] >> Sent: Wednesday, August 22, 2007 9:27 AM >> To: Stucker, Brian (RICH1:AR00); john.elwell@siemens.com; >> pkyzivat@cisco.com >> Cc: bliss@ietf.org >> Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting >> >> Comments inline >> >>> On this basis, you could say that the Organization header is an >>> appropriate place to put information to key off a service, or the >>> Subject header. If everyone agrees that it's so, and the >> header isn't >>> used for other essential functions, then it'll "work" but it >> won't be >>> interoperable outside of your development community which I >> assume is >>> important since you're posting to a list dedicated to >> solving interop >>> problems. :) >> Well my little understanding of standard bodies tells me that >> if everyone agrees to use the Organization header, than it is >> the standard. > > Just because someone writes something down doesn't make it a good idea. > :) > >> Having no standard at all is even less beneficial to >> interoperability isn't it? :) The IETF developer community >> and TISPAN/3GPP industry community together cover probably >> 70% of the telecom industry, so everything we define here is >> the de facto standard. >> >>> You could also investigate using early media along with RFC-4733 to >> denote playing a particular tone during call setup as another >> alternative. >> >> It is not about the tones, as I've pointed out the ISDN and >> GSM terminals provide a visual indication, so a parameter is >> needed. I'm not particularly keen on the Warning header but >> used it as an example to boost the discussion. > > I had not caught the need for a visual indication. I thought you were > trying to put a tone or stutter into the existing ringback heard by the > originator. I think your requirements here really fall into a gap. Some > folks will be opposed to the service itself (which, although I don't > particularly like the service you describe I don't think it should > prohibit the discussion of an acceptable way of signaling what you're > looking for), some folks will not want to add yet-another-header and > there's not a real great match that I'm aware of in an existing header > to solve your issue, some folks will want to overload the semantics of > an existing header or response code or define a new response code... > > For call diversion indication to a terminal, I think using 3265 is > really the best solution. When/how it gets rendered will leave you with > options going forward. For gateway to gateway communication though, I > can see where this would be more difficult to deal with but not > impossible though. It would look something like the SMDI indications > that come back for MWI that the network is able to process. Unless we > think this is an area of the protocol that is likely to grow in the > future (I doubt that it will ever extend beyond PSTN interworking) > you're probably looking at using a new p-header quite honestly. > > For Call waiting, I'm not sure why a 182 and some specified behavor at > the UA wouldn't do the trick. > > Regards, > Brian > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 23 05:35:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO95r-0005H1-Dz; Thu, 23 Aug 2007 05:35:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO95q-0005Gr-3g for bliss@ietf.org; Thu, 23 Aug 2007 05:35:10 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO95n-0001F6-VY for bliss@ietf.org; Thu, 23 Aug 2007 05:35:09 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Thu, 23 Aug 2007 11:35:06 +0200 Received: from S4DE9JSAAMW.ost.t-com.de ([10.125.177.114]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Aug 2007 11:35:06 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting Date: Thu, 23 Aug 2007 11:35:05 +0200 Message-Id: In-Reply-To: <46CC7830.6030504@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: Use of Warning: for Call-Waiting Thread-Index: Acfk5YGRQmdv4aPcTYimTk91LR2jYQAgtxZw From: "Alexeitsev, D" To: , X-OriginalArrivalTime: 23 Aug 2007 09:35:06.0454 (UTC) FILETIME=[E3CC8760:01C7E568] X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Thanks for the proposal. >Based on what I have heard so far I do think that Alert-Info is the best=20 >fit. I have proposed before, in other fora, that Alert-Info be used with=20 >a URN. It is then up to the recipient to understand the meaning of the=20 >URN - there are no games with trying to reference local files on the=20 >device, or forcing network access. >Certainly Alert-Info may be stripped in some environments, but as=20 >described, this should not be a problem in the environments where this=20 >is desired. >Using A-I with a URN you just have to go find, or define, a suitable=20 >family of URNs to denote the things you want to convey. Are there any objections, comments from the group to the use of the Alert-Info header to convey additional information about the call-waiting service? Greetings, Denis Alexeitsev _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 23 08:30:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBpN-00069Q-Up; Thu, 23 Aug 2007 08:30:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBpM-00069K-Uj for bliss@ietf.org; Thu, 23 Aug 2007 08:30:20 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOBpM-00057T-GV for bliss@ietf.org; Thu, 23 Aug 2007 08:30:20 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2007 05:30:19 -0700 X-IronPort-AV: i="4.19,300,1183359600"; d="scan'208"; a="394092195:sNHT50610512" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7NCUHn7003426; Thu, 23 Aug 2007 05:30:17 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7NCU3MH012346; Thu, 23 Aug 2007 12:30:15 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 08:30:05 -0400 Received: from [10.86.240.53] ([10.86.240.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Aug 2007 08:30:04 -0400 Message-ID: <46CD7DCC.9000401@cisco.com> Date: Thu, 23 Aug 2007 08:30:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Alexeitsev, D" Subject: Re: AW: [BLISS] RE: Use of Warning: for Call-Waiting References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2007 12:30:04.0867 (UTC) FILETIME=[55573930:01C7E581] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1867; t=1187872217; x=1188736217; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20AW=3A=20[BLISS]=20RE=3A=20Use=20of=20Warning=3A=20for =20Call-Waiting |Sender:=20; bh=h87RI/Jdh+km3CFHaClnN58CwZ69DthozIMUdHHoBxY=; b=ea37Qjpof4PqwUIXc9XwfqdkbAOo2WWRs+SDTqBJcSMYnGERE+yhivxsGJ/0B5s7O/vWCg3c 4mSZcTsTau22B2HgPaHgH/Aifw45IcFUbm59tLeOWGHWStMRr1xKbEIi; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org To elaborate, there are multiple ways to use this technique, depending on the approach you use for the URN: - you can use a URN that identifies what is to be presented in the alert. E.g. urn:tones:call-waiting-tone This would be a way to identify a particular sound (or picture, or text) by name rather than reference. - you can use a URN that identifies semantically what is to be presented, rather than a particular presentation. E.g. urn:alerts:call-waiting This way only the concept has been conveyed and it is up to the recipient to decide what sort of presentation is appropriate for the particular device and user. One UA might play a tone, while another displays an indicator on a display. Either way, this approach is only appropriate if what is being conveyed is truly *alert* info - info that is intended to impact the way the alert is done for the current call. Thanks, Paul Alexeitsev, D wrote: > Thanks for the proposal. > >> Based on what I have heard so far I do think that Alert-Info is the > best >> fit. I have proposed before, in other fora, that Alert-Info be used > with >> a URN. It is then up to the recipient to understand the meaning of the >> URN - there are no games with trying to reference local files on the >> device, or forcing network access. > >> Certainly Alert-Info may be stripped in some environments, but as >> described, this should not be a problem in the environments where this >> is desired. > >> Using A-I with a URN you just have to go find, or define, a suitable >> family of URNs to denote the things you want to convey. > > Are there any objections, comments from the group to the use of the > Alert-Info header to convey additional information about the > call-waiting service? > > Greetings, > Denis Alexeitsev > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 23 08:41:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBzy-0006zg-U0; Thu, 23 Aug 2007 08:41:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOBzx-0006zX-Lt for bliss@ietf.org; Thu, 23 Aug 2007 08:41:17 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOBzx-0005L5-1w for bliss@ietf.org; Thu, 23 Aug 2007 08:41:17 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JN80035Z8K8KO@siemenscomms.co.uk> for bliss@ietf.org; Thu, 23 Aug 2007 13:40:56 +0100 (BST) Date: Thu, 23 Aug 2007 13:41:30 +0100 From: "Elwell, John" Subject: RE: AW: [BLISS] RE: Use of Warning: for Call-Waiting In-reply-to: <46CD7DCC.9000401@cisco.com> To: Paul Kyzivat , "Alexeitsev, D" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D026F55B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: AW: [BLISS] RE: Use of Warning: for Call-Waiting Thread-Index: AcflgaxBbSbxh/vlRGeauWGNU4X/GwAAHerQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <46CD7DCC.9000401@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I would go for the semantic approach, so that no assumptions need to be made about the nature of the user interface on the calling device and it can apply to media other than audio, e.g., real-time text. Or it might be used in an intelligent way, e.g., offer the user the option of being informed when the called user is free (i.e., offer to set up a dialog package subscription). Also it might be usable by an automaton in some way. Finally, I think it would be better from a PSTN interworking point of view. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 23 August 2007 13:30 > To: Alexeitsev, D > Cc: bstucker@nortel.com; Elwell, John; bliss@ietf.org > Subject: Re: AW: [BLISS] RE: Use of Warning: for Call-Waiting > > To elaborate, there are multiple ways to use this technique, > depending > on the approach you use for the URN: > > - you can use a URN that identifies what is to be presented > in the alert. E.g. urn:tones:call-waiting-tone > This would be a way to identify a particular sound > (or picture, or text) by name rather than reference. > > - you can use a URN that identifies semantically what > is to be presented, rather than a particular presentation. > E.g. urn:alerts:call-waiting > This way only the concept has been conveyed and it is > up to the recipient to decide what sort of presentation > is appropriate for the particular device and user. > One UA might play a tone, while another displays an > indicator on a display. > > Either way, this approach is only appropriate if what is > being conveyed > is truly *alert* info - info that is intended to impact the way the > alert is done for the current call. > > Thanks, > Paul > > Alexeitsev, D wrote: > > Thanks for the proposal. > > > >> Based on what I have heard so far I do think that Alert-Info is the > > best > >> fit. I have proposed before, in other fora, that Alert-Info be used > > with > >> a URN. It is then up to the recipient to understand the > meaning of the > >> URN - there are no games with trying to reference local > files on the > >> device, or forcing network access. > > > >> Certainly Alert-Info may be stripped in some environments, but as > >> described, this should not be a problem in the > environments where this > >> is desired. > > > >> Using A-I with a URN you just have to go find, or define, > a suitable > >> family of URNs to denote the things you want to convey. > > > > Are there any objections, comments from the group to the use of the > > Alert-Info header to convey additional information about the > > call-waiting service? > > > > Greetings, > > Denis Alexeitsev > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 23 23:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOPgX-000503-Ji; Thu, 23 Aug 2007 23:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOPgV-0004yy-Ih for bliss@ietf.org; Thu, 23 Aug 2007 23:18:07 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOPgU-0003tm-Bl for bliss@ietf.org; Thu, 23 Aug 2007 23:18:07 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7O3I2s16107; Fri, 24 Aug 2007 03:18:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] RE: Use of Warning: for Call-Waiting Date: Thu, 23 Aug 2007 22:18:01 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711654FAB5@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] RE: Use of Warning: for Call-Waiting Thread-Index: Acfk5YGRQmdv4aPcTYimTk91LR2jYQAgtxZwACUzdGA= References: <46CC7830.6030504@cisco.com> From: "Brian Stucker" To: "Alexeitsev, D" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org No. I think it's probably the best fit without adding new headers to make it happen. The trick will all be in the urn definition though. I would strongly oppose something like http://localhost/tone/cwt1.wav or similar being proposed as the value. I've done this myself in a past life and it was a stupid thing to do in retrospect for a number of reasons. Regards, Brian=20 > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > Sent: Thursday, August 23, 2007 4:35 AM > To: pkyzivat@cisco.com; Stucker, Brian (RICH1:AR00) > Cc: john.elwell@siemens.com; bliss@ietf.org > Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting >=20 > Thanks for the proposal. >=20 > >Based on what I have heard so far I do think that Alert-Info is the > best=20 > >fit. I have proposed before, in other fora, that Alert-Info be used > with=20 > >a URN. It is then up to the recipient to understand the=20 > meaning of the=20 > >URN - there are no games with trying to reference local files on the=20 > >device, or forcing network access. >=20 > >Certainly Alert-Info may be stripped in some environments, but as=20 > >described, this should not be a problem in the environments=20 > where this=20 > >is desired. >=20 > >Using A-I with a URN you just have to go find, or define, a suitable=20 > >family of URNs to denote the things you want to convey. >=20 > Are there any objections, comments from the group to the use=20 > of the Alert-Info header to convey additional information=20 > about the call-waiting service? >=20 > Greetings, > Denis Alexeitsev >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 24 15:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOeYA-0003hV-55; Fri, 24 Aug 2007 15:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOeY9-0003hQ-KU for bliss@ietf.org; Fri, 24 Aug 2007 15:10:29 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IOeY8-0003C3-ES for bliss@ietf.org; Fri, 24 Aug 2007 15:10:29 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2007 15:10:28 -0400 X-IronPort-AV: i="4.19,305,1183348800"; d="scan'208"; a="129879055:sNHT50867440" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7OJASbU010342; Fri, 24 Aug 2007 15:10:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7OJANQW024672; Fri, 24 Aug 2007 19:10:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 15:10:16 -0400 Received: from [161.44.182.191] ([161.44.182.191]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 15:10:15 -0400 Message-ID: <46CF2D18.1020508@cisco.com> Date: Fri, 24 Aug 2007 15:10:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] RE: Use of Warning: for Call-Waiting References: <46CC7830.6030504@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA43711654FAB5@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711654FAB5@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Aug 2007 19:10:15.0920 (UTC) FILETIME=[6774E700:01C7E682] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1704; t=1187982628; x=1188846628; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20RE=3A=20Use=20of=20Warning=3A=20for=20Call- Waiting |Sender:=20 |To:=20Brian=20Stucker=20; bh=YzTPlrHM8ONQQ31noDZN3WH4YjznSE5z/UWoAmcK5f0=; b=LFYnEpWR+pRcJ0JcXKmpVmK+oI96y84RjNYHwNJWkxacJ8s6HiWOtUmfogd1kl1hu/k/8dPy cjs8jIBECx06oDCnyhz1sGd1+0NZXD8uaMC6R1jBzk1oAxBfZa/4po3y; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Brian Stucker wrote: > No. I think it's probably the best fit without adding new headers to > make it happen. The trick will all be in the urn definition though. > > I would strongly oppose something like http://localhost/tone/cwt1.wav or > similar being proposed as the value. I've done this myself in a past > life and it was a stupid thing to do in retrospect for a number of > reasons. I agree. That sort of usage is *evil*. Paul > Regards, > Brian > >> -----Original Message----- >> From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net] >> Sent: Thursday, August 23, 2007 4:35 AM >> To: pkyzivat@cisco.com; Stucker, Brian (RICH1:AR00) >> Cc: john.elwell@siemens.com; bliss@ietf.org >> Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting >> >> Thanks for the proposal. >> >>> Based on what I have heard so far I do think that Alert-Info is the >> best >>> fit. I have proposed before, in other fora, that Alert-Info be used >> with >>> a URN. It is then up to the recipient to understand the >> meaning of the >>> URN - there are no games with trying to reference local files on the >>> device, or forcing network access. >>> Certainly Alert-Info may be stripped in some environments, but as >>> described, this should not be a problem in the environments >> where this >>> is desired. >>> Using A-I with a URN you just have to go find, or define, a suitable >>> family of URNs to denote the things you want to convey. >> Are there any objections, comments from the group to the use >> of the Alert-Info header to convey additional information >> about the call-waiting service? >> >> Greetings, >> Denis Alexeitsev >> >> > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Sat Aug 25 23:04:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IP8QU-00020e-M0; Sat, 25 Aug 2007 23:04:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IP8QT-0001uX-Lk for bliss@ietf.org; Sat, 25 Aug 2007 23:04:33 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IP8QT-0007ge-85 for bliss@ietf.org; Sat, 25 Aug 2007 23:04:33 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc12) with ESMTP id <20070826030432m1200dglihe>; Sun, 26 Aug 2007 03:04:32 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7Q34VFg027864 for ; Sat, 25 Aug 2007 23:04:31 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7Q34V3R027860; Sat, 25 Aug 2007 23:04:31 -0400 Date: Sat, 25 Aug 2007 23:04:31 -0400 Message-Id: <200708260304.l7Q34V3R027860@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: (D.Alexeitsev@t-com.net) Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Alexeitsev, D" In several use cases there is a need to provide additional information about the status of the call or the activation of some additional services. "... a desire to provide additional information ..." For example in GSM and ISDN networks a common service is to provide calling party a reminder that the call diversion is activated for his line (A-party). This should not be mistake with the idication that the call diversion is taking place at the (B-Party). Another example is an indication for the A-Party, that the call-waiting procedure is taking place on the B-Party side. This indications are transmitted during call-establishment phase. A proposal is to reuse the Warning: header by extanding the warn-code with the values reflecting the described cases. The spare volumes of warn codes at the moment are 340-369 and 390-399, so the following new warn codes can be defined: Warning: 341 isi.edu "Call is a waiting call" Warning: 342 isi.edu "Diversion activated" I don't think this is a good idea. In regard to telling the caller that his call is being diverted, the 181 response seems to be already defined. In the case of call waiting, if the called party is being alerted now, then 180 is a good response. If the called party is not being alerted right now, but is expected to be alerted in the future, 182 has been defined for this purpose. In regard to indicating in some way to the caller that he has call forwarding engaged for his address, this should not be encoded within a dialog he makes to another party, because it is not a fact *about that dialog*. Instead, the mechanism by which he activates call forwarding should include a mechanism by which his UA can know whether call forwarding is activated, and inform the user of that status. But since no such mechanism has been standardized, we are not in a position to discuss it. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 27 16:08:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPksj-0005JC-MR; Mon, 27 Aug 2007 16:08:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPksi-0005J6-Fq for bliss@ietf.org; Mon, 27 Aug 2007 16:08:16 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPksh-0008TM-Q7 for bliss@ietf.org; Mon, 27 Aug 2007 16:08:16 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc15) with ESMTP id <20070827200814m1500t99mie>; Mon, 27 Aug 2007 20:08:14 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7RK8D4p018724 for ; Mon, 27 Aug 2007 16:08:13 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7RK8DT0018720; Mon, 27 Aug 2007 16:08:13 -0400 Date: Mon, 27 Aug 2007 16:08:13 -0400 Message-Id: <200708272008.l7RK8DT0018720@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> (bstucker@nortel.com) Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Brian Stucker" > In the case of call waiting, if the called party is being > alerted now, then 180 is a good response. If the called > party is not being alerted right now, but is expected to be > alerted in the future, 182 has been defined for this purpose. True. I agree wrt 180, but if there's a delay, sending a 182 will typically not trigger ringback at the originator to start. The "example" in RFC-3960, section 3.2 is the model most UAs use to generate local ringback, so a 182 would typically cause nothing to be heard at the originator, they potentially freak out thinking the call died, and potentially hangup as a result. That's true, but that's also the point of it. If the called UA (or service provider) wants the calling UA to play ringback, it sends 180. If it wants to indicate that the call is being forwarded but *not* to play ringback, it sends 182. > In regard to indicating in some way to the caller that he has > call forwarding engaged for his address, this should not be > encoded within a dialog he makes to another party, because it > is not a fact *about that dialog*. Instead, the mechanism by > which he activates call forwarding should include a mechanism > by which his UA can know whether call forwarding is > activated, and inform the user of that status. But since no > such mechanism has been standardized, we are not in a > position to discuss it. The problem here is with gateway-to-gateway signaling. The SIP UA for the calling party is a gateway and not an end-device. I completely agree that the best way of handling this at the endpoint is through some other mechanism (RFC-3265 springs to mind along with a notification of a change in configuration data for the subscriber). Given that, and the very likely problem that something will eventually get specified regardless of the advice of those on this mailing list, I'd prefer that it at least be something that has the least amount of impact to the way SIP works naturally. This automatically introduces some complexities, however. If the SIP UA is a gateway, then how is the gateway going to set up the call forwarding that we want to report back to the user? The special dial tone used to indicate to the caller that call forwarding is in effect for this UA and the user of special dial codes to set up call forwarding are two parallel responses to the poverty of the POTS user interface. In the best case, a native SIP UA has a special interface and mechanism to control call forwarding, and to indicate that call forwarding is active. In the next case, a gateway intercepts appropriate dial codes from a black phone and provides a special dial tone. The gateway is translating from a more orthogonal SIP interface to call forwarding to the more impoverished black phone interface. In the worst case, the gateway is completely unaware of call forwarding. In the outgoing direction, we can probably have the proxy recognize and divert special dial codes for call forwarding. But the reverse channel is harder to manipulate. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon Aug 27 20:48:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPpFy-0007Np-S7; Mon, 27 Aug 2007 20:48:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPpFx-0007Nf-Gr for bliss@ietf.org; Mon, 27 Aug 2007 20:48:33 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPpFw-0002jV-Al for bliss@ietf.org; Mon, 27 Aug 2007 20:48:33 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7S0mSf01544; Tue, 28 Aug 2007 00:48:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [BLISS] Use of Warning: header totransportadditionalstatusindications Date: Mon, 27 Aug 2007 19:47:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF11C73BEA@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [BLISS] Use of Warning: header totransportadditionalstatusindications Thread-Index: Acfj9sfC94CZeCjURg2djBsjhXE73wA0x5vgARBulZA= References: <46CAE496.409@cisco.com> From: "Francois Audet" To: "Alexeitsev, D" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org It seems to me that what you are trying to replicate is an indication of "call diversion/ forwarding" being currently activated. In the current PSTN model, because of device limitations, this is often a tone when you pick up the handset (so it is not a real asynchronous notification). If you are lucky enough to have a phone with a display, it can be a visual indication (in which case it is anynchronous). The 182 sugested by others is NOT appropriate for what you are looking for. The 182 tells the caller when making a call that the call is being diverted. You are looking for an indication for a User that his own device has diversion activated, and that it will therefore not be able to receive calls. The problem with this feature is that it doesn't really match how things work in SIP, where instead of simple "Call Forwarding =3D=3D ON | OFF", you normally have a set of routing rules applied to you. Sometimes, it is done through a REGISTER message, sometimes it's done with configuration on the proxy (e.g., scripts allowing routing calls in parallel or in sequence to other AORs, including PSTN numbers for example). In other words, forking and retargeting don't match that well to=20 "call forwarding indication". When you send a REGISTER for example, the Registrar will tell you you current active AOR contact bindings. In a way, that tells you your current "forwarding"=20 settings to other devices that share your AOR. It does not tell you however if you are set-up for retargeting to other devices. If this feature you are looking for is to be useful, I don't believe it is sufficient to be a PSTN "call forwarding" indication equivalent. It would have to be a way (probably through a subscription package) to query your current retargeting settings. So some document describing the routing policy applies to you AOR. I do think that it is a useful feature, but only if it is complete. > -----Original Message----- > From: Alexeitsev, D [mailto:D.Alexeitsev@t-com.net]=20 > Sent: Wednesday, August 22, 2007 07:42 > To: pkyzivat@cisco.com > Cc: bliss@ietf.org > Subject: AW: AW: [BLISS] Use of Warning: header=20 > totransportadditionalstatusindications >=20 > Comments below >=20 > >So, if you forget that you enabled forwarding, and you don't get any=20 > >calls for a long time, you will only discover the condition if you > >*make* a call??? >=20 > Correct >=20 > >That is not a service that I would be trying hard to emulate. >=20 > I would be happy to discuss a proposal on how to make the=20 > service better without making interworking impossible. >=20 > Greetings, > Denis Alexeitsev >=20 >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 28 04:50:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPwmi-0006aG-VO; Tue, 28 Aug 2007 04:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPwmi-0006aB-0s for bliss@ietf.org; Tue, 28 Aug 2007 04:50:52 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPwmg-0004bn-NQ for bliss@ietf.org; Tue, 28 Aug 2007 04:50:52 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7S8ol519352; Tue, 28 Aug 2007 08:50:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transport additional status indications Date: Tue, 28 Aug 2007 03:50:44 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> In-Reply-To: <200708272008.l7RK8DT0018720@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additional status indications Thread-Index: Acfo5gcSX7+rIihVSHW/fbIJMBaZowAKRT/A References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> From: "Brian Stucker" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: Monday, August 27, 2007 11:08 PM > To: bliss@ietf.org > Subject: Re: [BLISS] Use of Warning: header to transport=20 > additional status indications >=20 > From: "Brian Stucker" >=20 > > In the case of call waiting, if the called party is being=20 > > alerted now, then 180 is a good response. If the called=20 > > party is not being alerted right now, but is expected to be=20 > > alerted in the future, 182 has been defined for this purpose. >=20 > True. I agree wrt 180, but if there's a delay, sending a 182 will > typically not trigger ringback at the originator to start.=20 > The "example" > in RFC-3960, section 3.2 is the model most UAs use to=20 > generate local > ringback, so a 182 would typically cause nothing to be heard at the > originator, they potentially freak out thinking the call died, and > potentially hangup as a result. >=20 > That's true, but that's also the point of it. If the called=20 > UA (or service provider) wants the calling UA to play=20 > ringback, it sends 180. If it wants to indicate that the=20 > call is being forwarded but > *not* to play ringback, it sends 182. So I call you, you're already on a call so my call is waiting, therefore you send me a 182. My phone triggers local ringback when I get a 180 (which I have not) so as I'm waiting on you to switch calls, I hear silence. People won't tolerate that and will hang up thinking the call failed. That's why we have to provide comfort tones. Regardless of the protocol used there's still a human being using the phone. >=20 > > In regard to indicating in some way to the caller that he has=20 > > call forwarding engaged for his address, this should not be=20 > > encoded within a dialog he makes to another party, because it=20 > > is not a fact *about that dialog*. Instead, the mechanism by=20 > > which he activates call forwarding should include a mechanism=20 > > by which his UA can know whether call forwarding is=20 > > activated, and inform the user of that status. But since no=20 > > such mechanism has been standardized, we are not in a=20 > > position to discuss it. >=20 > The problem here is with gateway-to-gateway signaling. The=20 > SIP UA for > the calling party is a gateway and not an end-device. I=20 > completely agree > that the best way of handling this at the endpoint is=20 > through some other > mechanism (RFC-3265 springs to mind along with a notification of a > change in configuration data for the subscriber). Given=20 > that, and the > very likely problem that something will eventually get specified > regardless of the advice of those on this mailing list,=20 > I'd prefer that > it at least be something that has the least amount of=20 > impact to the way > SIP works naturally. >=20 > This automatically introduces some complexities, however. If=20 > the SIP UA is a gateway, then how is the gateway going to set=20 > up the call forwarding that we want to report back to the=20 > user? The special dial tone used to indicate to the caller=20 > that call forwarding is in effect for this UA and the user of=20 > special dial codes to set up call forwarding are two parallel=20 > responses to the poverty of the POTS user interface. I don't think this automatically introduces some complexities, I think it *is* the complexity. I don't believe this thread was trying to address how you setup call forwarding. It's talking about how you tell the user that they have call forwarding is active when dealing with a SIP UA that is not able to subscribe to configuration event packages. I believe everyone can envision a rough method of subscribing to an event package to be told when their call fowarding is active.=20 I must admit that I thought that this POTS feature wasn't very useful, but the more I think about it, being reminded when I make a call that people may or may not be able to call me back at the number I'm using (because the phone is forwarded) is pretty useful.=20 Being alerted when you make a call has nothing to do with the poverty of the POTS user interface because the phone itself could be reminding me that it has forwarded activated: the phone could be configured locally to generate a 302 response to forward my calls. Further, may people make calls today without ever looking at any sort of UI on their phone: think voice-activated dialing via a bluetooth headset. The question here is, given that there is no resource in the network that the phone can asynchronously determine that call forwarding is active, how else can the user be told that their calls are being forwarded?=20 >=20 > In the best case, a native SIP UA has a special interface and=20 > mechanism to control call forwarding, and to indicate that=20 > call forwarding is active. We're only talking about indicating that it's active here, not configuring it to be enabled or disabled. You're making the assumption that the network element that is providing call forwarding is a SIP device. It could simply be that call forwarding is being provided by a non-SIP PSTN element in the network for the user who is connected in via a SIP to ISUP gateway. In this case it'll be the SIP device that is at a disadvantage. Devices connecting via ISUP will hear the tone, but unless we can agree on a way to convey that tone to a SIP device (again, there's no resource here to subscribe to) in this case, the SIP device will not. So this isn't necessarily the best case. >=20 > In the next case, a gateway intercepts appropriate dial codes=20 > from a black phone and provides a special dial tone. The=20 > gateway is translating from a more orthogonal SIP interface=20 > to call forwarding to the more impoverished black phone interface. Turn that model around such that the gateway is translating from a PSTN network to a 'more orthogonal SIP interface'. >=20 > In the worst case, the gateway is completely unaware of call=20 > forwarding. In the outgoing direction, we can probably have=20 > the proxy recognize and divert special dial codes for call=20 > forwarding. But the reverse channel is harder to manipulate. I don't follow what you're trying to describe here. >=20 > Dale >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 28 09:28:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ17T-0003kX-R9; Tue, 28 Aug 2007 09:28:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ17T-0003kR-25 for bliss@ietf.org; Tue, 28 Aug 2007 09:28:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQ17S-0007zv-2V for bliss@ietf.org; Tue, 28 Aug 2007 09:28:34 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Aug 2007 09:28:34 -0400 X-IronPort-AV: i="4.19,316,1183348800"; d="scan'208"; a="130181800:sNHT64855092" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7SDSXUI024517; Tue, 28 Aug 2007 09:28:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7SDRkDh029004; Tue, 28 Aug 2007 13:28:29 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:28:12 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 09:28:12 -0400 Message-ID: <46D422EE.1080002@cisco.com> Date: Tue, 28 Aug 2007 09:28:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Aug 2007 13:28:12.0410 (UTC) FILETIME=[4824CDA0:01C7E977] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9206; t=1188307713; x=1189171713; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Use=20of=20Warning=3A=20header=20to=20trans port=20additional=20status=0A=20indications |Sender:=20 |To:=20Brian=20Stucker=20; bh=htatitlr3UKc3ML4/7zfTr6L05hjlJFfqcBOewQgBLU=; b=bpA8QnqDk67Xc7SSleQ37GpgF8fTlA7QfmU4HmMDwbKbflpCSHNOi7KfjC6MtBHWf8/svpih s7yNhG8sKSTePTfutvnWXLlU7c9HzAGhJ0hs7Q3OjnrdlGq4tlAqqsE8; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Brian Stucker wrote: > > >> -----Original Message----- >> From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net] >> Sent: Monday, August 27, 2007 11:08 PM >> To: bliss@ietf.org >> Subject: Re: [BLISS] Use of Warning: header to transport >> additional status indications >> >> From: "Brian Stucker" >> >> > In the case of call waiting, if the called party is being >> > alerted now, then 180 is a good response. If the called >> > party is not being alerted right now, but is expected to be >> > alerted in the future, 182 has been defined for this purpose. >> >> True. I agree wrt 180, but if there's a delay, sending a 182 will >> typically not trigger ringback at the originator to start. >> The "example" >> in RFC-3960, section 3.2 is the model most UAs use to >> generate local >> ringback, so a 182 would typically cause nothing to be heard at the >> originator, they potentially freak out thinking the call died, and >> potentially hangup as a result. >> >> That's true, but that's also the point of it. If the called >> UA (or service provider) wants the calling UA to play >> ringback, it sends 180. If it wants to indicate that the >> call is being forwarded but >> *not* to play ringback, it sends 182. > > So I call you, you're already on a call so my call is waiting, therefore > you send me a 182. My phone triggers local ringback when I get a 180 > (which I have not) so as I'm waiting on you to switch calls, I hear > silence. People won't tolerate that and will hang up thinking the call > failed. That's why we have to provide comfort tones. Regardless of the > protocol used there's still a human being using the phone. I agree with Brian wrt the user experience. I've proposed use of Alert-Info with a URN that identifies semantically the desired sort of alerting. IMO that is an appropriate solution. The below is something entirely different. It is quite confusing to be discussing them in the same thread. Nevertheless... >> > In regard to indicating in some way to the caller that he has >> > call forwarding engaged for his address, this should not be >> > encoded within a dialog he makes to another party, because it >> > is not a fact *about that dialog*. Instead, the mechanism by >> > which he activates call forwarding should include a mechanism >> > by which his UA can know whether call forwarding is >> > activated, and inform the user of that status. But since no >> > such mechanism has been standardized, we are not in a >> > position to discuss it. >> >> The problem here is with gateway-to-gateway signaling. The >> SIP UA for >> the calling party is a gateway and not an end-device. I >> completely agree >> that the best way of handling this at the endpoint is >> through some other >> mechanism (RFC-3265 springs to mind along with a notification of a >> change in configuration data for the subscriber). Given >> that, and the >> very likely problem that something will eventually get specified >> regardless of the advice of those on this mailing list, >> I'd prefer that >> it at least be something that has the least amount of >> impact to the way >> SIP works naturally. IMO it is in general a bad idea to introduce mechanisms that are specific to GW-GW calling. In general you can't know in advance that there is a GW-GW situation, and in general for whatever "feature" is enabled that way you will need to define some other mechanism when one or both of the parties aren't GWs. GW-GW mechanisms are useful when SIP is only being used to tunnel some other protocol. While that is something people do with sip, I don't think that is something most of us are interested in spending our time on. >> This automatically introduces some complexities, however. If >> the SIP UA is a gateway, then how is the gateway going to set >> up the call forwarding that we want to report back to the >> user? The special dial tone used to indicate to the caller >> that call forwarding is in effect for this UA and the user of >> special dial codes to set up call forwarding are two parallel >> responses to the poverty of the POTS user interface. > > I don't think this automatically introduces some complexities, I think > it *is* the complexity. I don't believe this thread was trying to > address how you setup call forwarding. It's talking about how you tell > the user that they have call forwarding is active when dealing with a > SIP UA that is not able to subscribe to configuration event packages. I > believe everyone can envision a rough method of subscribing to an event > package to be told when their call fowarding is active. > > I must admit that I thought that this POTS feature wasn't very useful, > but the more I think about it, being reminded when I make a call that > people may or may not be able to call me back at the number I'm using > (because the phone is forwarded) is pretty useful. It may indeed be useful to be informed about the status of some remote agent working on your behalf. And I do believe this is about that aspect - things working on your behalf, and under your control (at least in some limited way). > Being alerted when you make a call has nothing to do with the poverty of > the POTS user interface Its the poverty of the UI that leads to alerting when you pick up the phone. Its the stupidity of the PSTN UA and the communication path between it and the other components acting on your behalf that prevent ongoing monitoring and display of the status and instead lead to checking it only when making a call. > because the phone itself could be reminding me > that it has forwarded activated: the phone could be configured locally > to generate a 302 response to forward my calls. Further, may people make > calls today without ever looking at any sort of UI on their phone: think > voice-activated dialing via a bluetooth headset. Clearly there are a variety of UIs that might be involved. And they may limit how and when status may be conveyed to the user. But we should distinguish that from the signaling. > The question here is, given that there is no resource in the network > that the phone can asynchronously determine that call forwarding is > active, how else can the user be told that their calls are being > forwarded? There isn't? Or is there just no resource that is willing to hold a subscription? And why is that? This is between *my* phone and *my* call agent. There is some dedicated resource in there. To be a viable system the call agent must have knowledge of whether my phone is connected or not, so there is probably a sip registrar involved even if the primary call processing isn't done in sip. So I think there is something that could service a subscription. How it handles the other side of the signaling is its business. When a subscription is active it could poll from time to time by initiating fake calls to an address that won't answer. Or whatever works. But it can turn that into something appropriate for the sip side. Paul >> In the best case, a native SIP UA has a special interface and >> mechanism to control call forwarding, and to indicate that >> call forwarding is active. > > We're only talking about indicating that it's active here, not > configuring it to be enabled or disabled. You're making the assumption > that the network element that is providing call forwarding is a SIP > device. It could simply be that call forwarding is being provided by a > non-SIP PSTN element in the network for the user who is connected in via > a SIP to ISUP gateway. In this case it'll be the SIP device that is at a > disadvantage. Devices connecting via ISUP will hear the tone, but unless > we can agree on a way to convey that tone to a SIP device (again, > there's no resource here to subscribe to) in this case, the SIP device > will not. So this isn't necessarily the best case. > >> In the next case, a gateway intercepts appropriate dial codes >> from a black phone and provides a special dial tone. The >> gateway is translating from a more orthogonal SIP interface >> to call forwarding to the more impoverished black phone interface. > > Turn that model around such that the gateway is translating from a PSTN > network to a 'more orthogonal SIP interface'. > >> In the worst case, the gateway is completely unaware of call >> forwarding. In the outgoing direction, we can probably have >> the proxy recognize and divert special dial codes for call >> forwarding. But the reverse channel is harder to manipulate. > > I don't follow what you're trying to describe here. > >> Dale >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue Aug 28 09:43:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ1M4-0007tM-7N; Tue, 28 Aug 2007 09:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ1M3-0007tH-8A for bliss@ietf.org; Tue, 28 Aug 2007 09:43:39 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ1M2-00026n-1H for bliss@ietf.org; Tue, 28 Aug 2007 09:43:39 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7SDhTe14165; Tue, 28 Aug 2007 13:43:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transport additional status indications Date: Tue, 28 Aug 2007 08:43:08 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711665F762@zrc2hxm2.corp.nortel.com> In-Reply-To: <46D422EE.1080002@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additional status indications Thread-Index: Acfpd1eoDVCdvyiJRlaiPLEqTfxcYgAAF6Ow References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <46D422EE.1080002@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 [snip] >=20 > IMO it is in general a bad idea to introduce mechanisms that=20 > are specific to GW-GW calling. In general you can't know in=20 > advance that there is a GW-GW situation, and in general for=20 > whatever "feature" is enabled that way you will need to=20 > define some other mechanism when one or both of the parties=20 > aren't GWs. >=20 > GW-GW mechanisms are useful when SIP is only being used to=20 > tunnel some other protocol. While that is something people do=20 > with sip, I don't think that is something most of us are=20 > interested in spending our time on. >=20 True enough, let's deprecate SIP-I immediately. I don't think anyone is asking us to spend any time on tunneling protocols. If I recall correctly, Denis was simply asking us what the best way was to convey a service indication during an INVITE transaction to trigger a notification of some sort at the phone. Stick your head in the sand, and wait a few months for the eventual spec to be written that will handle this from other SDOs and then deploy an SBC to fix the issue when your products are asked to interwork with the other solution and customers complain that you don't support their feature set. It's a well-trodden path... So well trodden in fact, that we are now corresponding on this email list as a result. [SNIP] > > Being alerted when you make a call has nothing to do with=20 > the poverty=20 > > of the POTS user interface >=20 > Its the poverty of the UI that leads to alerting when you=20 > pick up the phone. >=20 > Its the stupidity of the PSTN UA and the communication path=20 > between it and the other components acting on your behalf=20 > that prevent ongoing monitoring and display of the status and=20 > instead lead to checking it only when making a call. Forget about the PSTN UA. Take the case where it's a SIP UA talking into a PSTN network that is hosting your services. You can either use early media to convey a tone to the SIP UA (the bad-old PSTN way) or, if the SIP GW is aware enough to do so, it could give the SIP UA an explicit note as to what it is being alerted to. [SNIP] > > The question here is, given that there is no resource in=20 > the network=20 > > that the phone can asynchronously determine that call forwarding is=20 > > active, how else can the user be told that their calls are being=20 > > forwarded? >=20 > There isn't? Or is there just no resource that is willing to=20 > hold a subscription? And why is that? This is between *my*=20 > phone and *my* call agent. There is some dedicated resource=20 > in there. To be a viable system the call agent must have=20 > knowledge of whether my phone is connected or not, so there=20 > is probably a sip registrar involved even if the primary call=20 > processing isn't done in sip. So I think there is something=20 > that could service a subscription. How it handles the other=20 > side of the signaling is its business. When a subscription is=20 > active it could poll from time to time by initiating fake=20 > calls to an address that won't answer. Or whatever works. But=20 > it can turn that into something appropriate for the sip side. Huh? This is about getting service parity via a SIP UA connected to a network where the service is not hosted by a SIP proxy . How do you get a subscription to interwork with another protocol that does not support the notion of subscriptions? What's the difference between sending a subscribe and getting the notifications at a different time, and only getting them when a call is made? And if that's true, why would you require that the information be conveyed using a notify if there's always an INVITE transaction open at that given moment? Regards, Brian _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 29 09:28:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQNb6-0007fs-5M; Wed, 29 Aug 2007 09:28:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQNb5-0007XP-0d for bliss@ietf.org; Wed, 29 Aug 2007 09:28:39 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQNb4-0000u2-8G for bliss@ietf.org; Wed, 29 Aug 2007 09:28:38 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Aug 2007 09:28:38 -0400 X-IronPort-AV: i="4.19,321,1183348800"; d="scan'208"; a="130293444:sNHT75890098" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7TDSbXc024468; Wed, 29 Aug 2007 09:28:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7TDSTQS000375; Wed, 29 Aug 2007 13:28:29 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 09:28:15 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 09:28:15 -0400 Message-ID: <46D57471.1080204@cisco.com> Date: Wed, 29 Aug 2007 09:28:17 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Stucker Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <46D422EE.1080002@cisco.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F762@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43711665F762@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 13:28:15.0483 (UTC) FILETIME=[746374B0:01C7EA40] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6235; t=1188394117; x=1189258117; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Use=20of=20Warning=3A=20header=20to=20trans port=20additional=20status=0A=20indications |Sender:=20 |To:=20Brian=20Stucker=20; bh=gllV+sUyqP290TPkY+JFjEQlyl17s+yul8GhGDczVgA=; b=WN5jpv91lbFmde22irNZ0EafTBCqqr43IjpAOXyhr2SRG1LJ+CMzc4/OwXO/trKvVtQBmm6x G1XICNNh3s4g1JwFuB9RdVwGcY2Zkr6SQarearncRk99NJM8fXK/qG/x; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Brian Stucker wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > [snip] > >> IMO it is in general a bad idea to introduce mechanisms that >> are specific to GW-GW calling. In general you can't know in >> advance that there is a GW-GW situation, and in general for >> whatever "feature" is enabled that way you will need to >> define some other mechanism when one or both of the parties >> aren't GWs. >> >> GW-GW mechanisms are useful when SIP is only being used to >> tunnel some other protocol. While that is something people do >> with sip, I don't think that is something most of us are >> interested in spending our time on. >> > > True enough, let's deprecate SIP-I immediately. :-) All I was saying is that such usage hasn't been a primary focus of effort for awhile. The work was done, and is in use, and I'm not suggesting it be deprecated. > I don't think anyone is > asking us to spend any time on tunneling protocols. If I recall > correctly, Denis was simply asking us what the best way was to convey a > service indication during an INVITE transaction to trigger a > notification of some sort at the phone. I was getting the feeling the places where this would be useful are only tunneling. If thats not true, then the story is different. > Stick your head in the sand, and wait a few months for the eventual spec > to be written that will handle this from other SDOs and then deploy an > SBC to fix the issue when your products are asked to interwork with the > other solution and customers complain that you don't support their > feature set. It's a well-trodden path... So well trodden in fact, that > we are now corresponding on this email list as a result. My point is to find a way to have a common mechanism for both sip-sip communication and sip-gw communication scenarios. Having different solutions for the sip parts of these two cases is at least undesirable. I think most of us would agree that in a sip-sip scenario we would not want to restrict the solution to conveying this indication at the time of call initiation. If there is a more general solution, and a way can be found to make it work with GWs as well, that would be better than the proposed indication during call initiation. > [SNIP] > >>> Being alerted when you make a call has nothing to do with >> the poverty >>> of the POTS user interface >> Its the poverty of the UI that leads to alerting when you >> pick up the phone. >> >> Its the stupidity of the PSTN UA and the communication path >> between it and the other components acting on your behalf >> that prevent ongoing monitoring and display of the status and >> instead lead to checking it only when making a call. > > Forget about the PSTN UA. Take the case where it's a SIP UA talking into > a PSTN network that is hosting your services. Can you be more explicit about the topology you are talking about? Are you assuming a GW with configured knowledge of particular sip phones that are mapped onto PSTN lines? Or are you talking about sip phones that register with a sip registrar, and the proxy/registrar delegates all calls through a GW? Or what? > You can either use early > media to convey a tone to the SIP UA (the bad-old PSTN way) or, if the > SIP GW is aware enough to do so, it could give the SIP UA an explicit > note as to what it is being alerted to. As long as there is either a registrar/proxy that has state for each phone, or a GW with configured knowledge of each, then that component could also terminate subscriptions to an event package. It could generate notifications based on occasionally polling the PSTN side by making a "fake" call, as well as observing the indications on the PSTN side for any actual calls that are originated. It could also monitor the dialtone on the PSTN side when that is used to convey the indication. None of the idiosyncrasies of the PSTN signaling need be carried over to the sip signaling. > [SNIP] > >>> The question here is, given that there is no resource in >> the network >>> that the phone can asynchronously determine that call forwarding is >>> active, how else can the user be told that their calls are being >>> forwarded? >> There isn't? Or is there just no resource that is willing to >> hold a subscription? And why is that? This is between *my* >> phone and *my* call agent. There is some dedicated resource >> in there. To be a viable system the call agent must have >> knowledge of whether my phone is connected or not, so there >> is probably a sip registrar involved even if the primary call >> processing isn't done in sip. So I think there is something >> that could service a subscription. How it handles the other >> side of the signaling is its business. When a subscription is >> active it could poll from time to time by initiating fake >> calls to an address that won't answer. Or whatever works. But >> it can turn that into something appropriate for the sip side. > > Huh? This is about getting service parity via a SIP UA connected to a > network where the service is not hosted by a SIP proxy . How do you get > a subscription to interwork with another protocol that does not support > the notion of subscriptions? See above? > What's the difference between sending a > subscribe and getting the notifications at a different time, and only > getting them when a call is made? When the services are provided in a network that only provides the indications at time of a call then that may be the only time that notifications are received. But at least that limitation is then governed by the poverty of the service provider - not the sip machinery. If you upgrade to a different service provider you can get better service. And as I noted above, a GW implementing the event package can overcome some of these limitations by polling. Paul > And if that's true, why would you > require that the information be conveyed using a notify if there's > always an INVITE transaction open at that given moment? > > Regards, > Brian > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 29 14:47:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSZt-0008Cn-Ej; Wed, 29 Aug 2007 14:47:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSZp-0008Ce-IA for bliss@ietf.org; Wed, 29 Aug 2007 14:47:41 -0400 Received: from alnrmhc16.comcast.net ([204.127.225.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQSZo-00022D-CV for bliss@ietf.org; Wed, 29 Aug 2007 14:47:41 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070829184739b1600qn65ae>; Wed, 29 Aug 2007 18:47:39 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7TIiw4p028630 for ; Wed, 29 Aug 2007 14:44:58 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7TIiwEa028626; Wed, 29 Aug 2007 14:44:58 -0400 Date: Wed, 29 Aug 2007 14:44:58 -0400 Message-Id: <200708291844.l7TIiwEa028626@dragon.ariadne.com> From: Dale.Worley@comcast.net To: bliss@ietf.org In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> (bstucker@nortel.com) Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Brian Stucker" So I call you, you're already on a call so my call is waiting, therefore you send me a 182. My phone triggers local ringback when I get a 180 (which I have not) so as I'm waiting on you to switch calls, I hear silence. People won't tolerate that and will hang up thinking the call failed. That's why we have to provide comfort tones. Regardless of the protocol used there's still a human being using the phone. You're quite correct that the user receives a deficient experience. But I think you're mis-identifying the *cause* of the deficient experience. From a SIP point of view, the called end is reporting status quite correctly and usefully -- 182 means "you're being queued and a user has not yet been notified". The problem, IMHO, is that when the calling UA receives a 182 that it does not relay that information to the user in some manner. It thus fails to transport the status information that it has receives to the user. What the UA needs to do is to provide some sort of comfort tone or ringback when it receives such status messages, not just for 180. (IIRC some PSTN systems will provide a tone when a call is forwarded; this would be a natural report for receiving a 181.) Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 29 14:49:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSbj-0000Ie-Fd; Wed, 29 Aug 2007 14:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSbh-0000GZ-Q3 for bliss@ietf.org; Wed, 29 Aug 2007 14:49:39 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQSbg-0002An-Iv for bliss@ietf.org; Wed, 29 Aug 2007 14:49:37 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc14) with ESMTP id <20070829184935m1400kjfure>; Wed, 29 Aug 2007 18:49:35 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7TImE4p028872 for ; Wed, 29 Aug 2007 14:48:14 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7TImEEK028868; Wed, 29 Aug 2007 14:48:14 -0400 Date: Wed, 29 Aug 2007 14:48:14 -0400 Message-Id: <200708291848.l7TImEEK028868@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <46D422EE.1080002@cisco.com> (pkyzivat@cisco.com) Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <46D422EE.1080002@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: Paul Kyzivat I agree with Brian wrt the user experience. I've proposed use of Alert-Info with a URN that identifies semantically the desired sort of alerting. IMO that is an appropriate solution. Why would we need a URN to carry the semantics when we have the response code? Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 29 15:05:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSqZ-0007Iy-0O; Wed, 29 Aug 2007 15:04:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQSqW-00074E-Cj for bliss@ietf.org; Wed, 29 Aug 2007 15:04:56 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQSqV-00054O-Tc for bliss@ietf.org; Wed, 29 Aug 2007 15:04:56 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20070829190454m13003gfsoe>; Wed, 29 Aug 2007 19:04:54 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7TJ3X4p029991 for ; Wed, 29 Aug 2007 15:03:33 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7TJ3XAx029987; Wed, 29 Aug 2007 15:03:33 -0400 Date: Wed, 29 Aug 2007 15:03:33 -0400 Message-Id: <200708291903.l7TJ3XAx029987@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> (bstucker@nortel.com) Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Brian Stucker" The question here is, given that there is no resource in the network that the phone can asynchronously determine that call forwarding is active, how else can the user be told that their calls are being forwarded? Why doesn't it subscribe to the resource that is handling and implementing the call forwarding? > In the next case, a gateway intercepts appropriate dial codes > from a black phone and provides a special dial tone. The > gateway is translating from a more orthogonal SIP interface > to call forwarding to the more impoverished black phone interface. Turn that model around such that the gateway is translating from a PSTN network to a 'more orthogonal SIP interface'. OK, I think I see what you're getting at -- You have a SIP phone going through a SIP network to a gateway to the PSTN, which *PSTN* is doing the call forwarding. Ugh. It would have helped if you'd stated that at the beginning of the discussion. Normally we talk about SIP networks here. In this sort of situation, I would expect the SIP-to-PSTN gateway to provide the resource to which the SIP UA subscribes in order to discover the call forwarding status for the AOR. The gateway is already translating all other aspects of the attachment of the UA to its real home switch down in the PSTN. The next question is how does the gateway discover the call forwarding status? There are probably as many answers to that as there are call-forwarding-indication systems. I expect that ISDN or SS7 provides some direct way of obtaining call-forwarding status without having to initiate a call. But if we were truly stuck and the only way the PSTN would report call-forwarding status was via the dial tone when the line went off-hook, the gateway could monitor the dial tone at the start of every call that it passed through, and by occasionally taking the line off-hook when the line was otherwise idle. > In the worst case, the gateway is completely unaware of call > forwarding. In the outgoing direction, we can probably have > the proxy recognize and divert special dial codes for call > forwarding. But the reverse channel is harder to manipulate. I don't follow what you're trying to describe here. I was talking about gateways for analog phones hanging off SIP networks, which is what you seemed to be talking about. Phones like that have no other way to indicate call-forwarding status than dial tones and similar status tones. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed Aug 29 16:23:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQU46-0007yI-AY; Wed, 29 Aug 2007 16:23:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQU3z-0007vl-Ov for bliss@ietf.org; Wed, 29 Aug 2007 16:22:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQU3x-00089R-RV for bliss@ietf.org; Wed, 29 Aug 2007 16:22:55 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Aug 2007 16:22:54 -0400 X-IronPort-AV: i="4.19,323,1183348800"; d="scan'208"; a="69464750:sNHT50689298" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7TKMroV023976; Wed, 29 Aug 2007 16:22:53 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7TKMhQs008490; Wed, 29 Aug 2007 20:22:53 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 16:22:45 -0400 Received: from [161.44.174.118] ([161.44.174.118]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Aug 2007 16:22:44 -0400 Message-ID: <46D5D592.4070805@cisco.com> Date: Wed, 29 Aug 2007 16:22:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <46D422EE.1080002@cisco.com> <200708291848.l7TImEEK028868@dragon.ariadne.com> In-Reply-To: <200708291848.l7TImEEK028868@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Aug 2007 20:22:44.0907 (UTC) FILETIME=[5BB867B0:01C7EA7A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1172; t=1188418973; x=1189282973; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Use=20of=20Warning=3A=20header=20to=20trans port=20additional=20status=0A=20indications |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=wUU2LDulkiWzqRJGXv4rU1haCerF6cNccBY4xpfDL6A=; b=qu1QxuZ3+athZQ/6ppzfegmIOS4JuDQNOsqrhxKufHf6NQ3W+jEI6OZeL8VWLZNsRiOCQac4 ZnX7Ra74RoIGov9POMphE5IniPWhvAUgBWH9/R8Hmtu34Vbh81nAh6uO; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Dale.Worley@comcast.net wrote: > From: Paul Kyzivat > > I agree with Brian wrt the user experience. > I've proposed use of Alert-Info with a URN that identifies semantically > the desired sort of alerting. IMO that is an appropriate solution. > > Why would we need a URN to carry the semantics when we have the > response code? If there is a response code that conveys the proper semantics then I agree. I believe the case we are discussing is call waiting. Maybe there are other cases, but AFAIK in the call waiting case the called user *is* alerted, and so 182 is probably the wrong response. I gather that in addition to informing the caller that the callee has been alerted, there is a desire to indicate that the callee is in some state where answering response may be delayed longer than "normal". I am personally far from convinced that there is any information here that ought to be conveyed. But if I assume that there is reason to inform the caller of this, I have proposed the use of A-I to convey it. It is a reasonable mechanism for "alerting the caller" in a particular way. Paul _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 02:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQddE-0003Y0-T7; Thu, 30 Aug 2007 02:35:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQddD-0003U8-DM for bliss@ietf.org; Thu, 30 Aug 2007 02:35:55 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQddC-00049C-U2 for bliss@ietf.org; Thu, 30 Aug 2007 02:35:55 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7U6Zoi15194; Thu, 30 Aug 2007 06:35:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transport additional status indications Date: Thu, 30 Aug 2007 01:35:46 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116741D88@zrc2hxm2.corp.nortel.com> In-Reply-To: <46D5D592.4070805@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additional status indications Thread-Index: Acfqemu9RA3IeWnRQhinGimxRh45RgAVXd8w References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <46D422EE.1080002@cisco.com> <200708291848.l7TImEEK028868@dragon.ariadne.com> <46D5D592.4070805@cisco.com> From: "Brian Stucker" To: "Paul Kyzivat" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Dale.Worley@comcast.net wrote: > > From: Paul Kyzivat > >=20 > > I agree with Brian wrt the user experience. > > I've proposed use of Alert-Info with a URN that=20 > identifies semantically=20 > > the desired sort of alerting. IMO that is an appropriate=20 > solution. > >=20 > > Why would we need a URN to carry the semantics when we have the=20 > > response code? >=20 > If there is a response code that conveys the proper semantics=20 > then I agree. >=20 > I believe the case we are discussing is call waiting. Maybe=20 > there are other cases, but AFAIK in the call waiting case the=20 > called user *is* alerted, and so 182 is probably the wrong=20 > response. I gather that in addition to informing the caller=20 > that the callee has been alerted, there is a desire to=20 > indicate that the callee is in some state where answering=20 > response may be delayed longer than "normal". >=20 > I am personally far from convinced that there is any=20 > information here that ought to be conveyed. But if I assume=20 > that there is reason to inform the caller of this, I have=20 > proposed the use of A-I to convey it.=20 > It is a reasonable mechanism for "alerting the caller" in a=20 > particular way. >=20 I agree. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 02:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQdyV-0008Lb-BX; Thu, 30 Aug 2007 02:57:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQdyT-0008HE-N4 for bliss@ietf.org; Thu, 30 Aug 2007 02:57:53 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQdyT-0004d2-2h for bliss@ietf.org; Thu, 30 Aug 2007 02:57:53 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7U6vns12802; Thu, 30 Aug 2007 06:57:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transport additional status indications Date: Thu, 30 Aug 2007 01:57:48 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116741D93@zrc2hxm2.corp.nortel.com> In-Reply-To: <200708291903.l7TJ3XAx029987@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additional status indications Thread-Index: Acfqb4Jy/bTU2BT4TfSFCqHuuCLwrQAXQzfQ References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <200708291903.l7TJ3XAx029987@dragon.ariadne.com> From: "Brian Stucker" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: D.Alexeitsev@t-com.net X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: Wednesday, August 29, 2007 10:04 PM > To: bliss@ietf.org > Subject: Re: [BLISS] Use of Warning: header to transport=20 > additional status indications >=20 > From: "Brian Stucker" >=20 > The question here is, given that there is no resource in=20 > the network > that the phone can asynchronously determine that call forwarding is > active, how else can the user be told that their calls are being > forwarded?=20 >=20 > Why doesn't it subscribe to the resource that is handling and=20 > implementing the call forwarding? Because the resource handling call forwarding may be a big brown box that will never be upgraded to support SIP endpoints natively, but you'd still like to use SIP endpoints. >=20 > > In the next case, a gateway intercepts appropriate dial codes=20 > > from a black phone and provides a special dial tone. The=20 > > gateway is translating from a more orthogonal SIP interface=20 > > to call forwarding to the more impoverished black phone=20 > interface. >=20 > Turn that model around such that the gateway is=20 > translating from a PSTN > network to a 'more orthogonal SIP interface'. >=20 > OK, I think I see what you're getting at -- You have a SIP=20 > phone going through a SIP network to a gateway to the PSTN,=20 > which *PSTN* is doing the call forwarding. Ugh. Yep. Nasty from a SIP point of view, but the alternative is no SIP endpoint at all. >=20 > It would have helped if you'd stated that at the beginning of=20 > the discussion. Normally we talk about SIP networks here. I didn't start the fire. This came from Denis (cc'ed). I'm just trying to facilitate a solution that is palatable to myself and the community to avoid hacks. >=20 > In this sort of situation, I would expect the SIP-to-PSTN=20 > gateway to provide the resource to which the SIP UA=20 > subscribes in order to discover the call forwarding status=20 > for the AOR. The gateway is already translating all other=20 > aspects of the attachment of the UA to its real home switch=20 > down in the PSTN. I don't think this is a reliable solution because the status of the call forwarding could change in the PSTN and the gateway would not know that such had changed until a call is made. This doesn't mean that you can't use subscribe/notify in any situation. I definitely think you can, but just that it's likely not realistic in this case. I don't know, but I have a strong suspicion that this is the case. >=20 > The next question is how does the gateway discover the call=20 > forwarding status? There are probably as many answers to=20 > that as there are call-forwarding-indication systems. I=20 > expect that ISDN or SS7 provides some direct way of obtaining=20 > call-forwarding status without having to initiate a call. =20 > But if we were truly stuck and the only way the PSTN would=20 > report call-forwarding status was via the dial tone when the=20 > line went off-hook, the gateway could monitor the dial tone=20 > at the start of every call that it passed through, and by=20 > occasionally taking the line off-hook when the line was=20 > otherwise idle. >=20 > > In the worst case, the gateway is completely unaware of call=20 > > forwarding. In the outgoing direction, we can probably have=20 > > the proxy recognize and divert special dial codes for call=20 > > forwarding. But the reverse channel is harder to manipulate. >=20 > I don't follow what you're trying to describe here. >=20 > I was talking about gateways for analog phones hanging off=20 > SIP networks, which is what you seemed to be talking about. =20 > Phones like that have no other way to indicate=20 > call-forwarding status than dial tones and similar status tones. Ok. Right. Both models should be covered by the same set of mechanisms. The difference I was trying to point out here is that folks were assuming that the thing doing call forwarding was SIP. It could be, but there are several cases: 1. SIP core doing the call forwarding, SIP endpoints: use subscribe/notify please. 2. SIP core doing the call forwarding, non-SIP endpoints: use alert-info and/or subscribe/notify? Unclear. Gateway would have to act as a persistient SIP UA for the non-SIP endpoint instead of a shared, on-demand, resource.=20 3. Non-SIP core doing the call forwarding, SIP endpoints: use alert-info and/or subscribe/notify? Unclear. Probably can't expect subscribe/notify to work because you'd have to upgrade too of the existing equipment out there. 4. Non-SIP core, non-SIP endpoints: Use SIP-I or something else if you have SIP in the middle in there somewhere. Regards, Brian _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 03:02:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQe39-00037P-Pb; Thu, 30 Aug 2007 03:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQe38-00037J-DC for bliss@ietf.org; Thu, 30 Aug 2007 03:02:42 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQe37-00010o-68 for bliss@ietf.org; Thu, 30 Aug 2007 03:02:42 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7U72bs15370; Thu, 30 Aug 2007 07:02:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transport additional status indications Date: Thu, 30 Aug 2007 02:02:37 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116741D94@zrc2hxm2.corp.nortel.com> In-Reply-To: <200708291844.l7TIiwEa028626@dragon.ariadne.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additional status indications Thread-Index: AcfqbTDOjthJ6oVrQjqy+gIH4PLC4QAZhHCA References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <200708291844.l7TIiwEa028626@dragon.ariadne.com> From: "Brian Stucker" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Dale.Worley@comcast.net [mailto:Dale.Worley@comcast.net]=20 > Sent: Wednesday, August 29, 2007 9:45 PM > To: bliss@ietf.org > Subject: Re: [BLISS] Use of Warning: header to transport=20 > additional status indications >=20 > From: "Brian Stucker" >=20 > So I call you, you're already on a call so my call is=20 > waiting, therefore > you send me a 182. My phone triggers local ringback when I=20 > get a 180 > (which I have not) so as I'm waiting on you to switch calls, I hear > silence. People won't tolerate that and will hang up=20 > thinking the call > failed. That's why we have to provide comfort tones.=20 > Regardless of the > protocol used there's still a human being using the phone. >=20 > You're quite correct that the user receives a deficient experience. > But I think you're mis-identifying the *cause* of the=20 > deficient experience. From a SIP point of view, the called=20 > end is reporting status quite correctly and usefully -- 182=20 > means "you're being queued and a user has not yet been=20 > notified". The problem, IMHO, is that when the calling UA=20 > receives a 182 that it does not relay that information to the=20 > user in some manner. It thus fails to transport the status=20 > information that it has receives to the user. What the UA=20 > needs to do is to provide some sort of comfort tone or=20 > ringback when it receives such status messages, not just for=20 > 180. (IIRC some PSTN systems will provide a tone when a call=20 > is forwarded; this would be a natural report for receiving a 181.) If we were having this discussion 7 years ago, I'd agree with you, and to a certain extent I agree with you now. However, this is pretty much the way UAs are told to work and are built to work (don't start ringback until 180) to avoid ghost-ringback problems which are equally confusing to people. There's too many SIP UAs out there that would need to be changed, and it's unclear that the change is safe. >=20 > Dale >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 09:28:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQk4J-0004dB-8g; Thu, 30 Aug 2007 09:28:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQk4H-0004cU-VM for bliss@ietf.org; Thu, 30 Aug 2007 09:28:17 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQk4G-0003xt-Br for bliss@ietf.org; Thu, 30 Aug 2007 09:28:17 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Thu, 30 Aug 2007 15:28:11 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Aug 2007 15:28:11 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] Use of Warning: header to transport additional statusindications Date: Thu, 30 Aug 2007 15:28:10 +0200 Message-Id: In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437116741D88@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additional statusindications Thread-Index: Acfqemu9RA3IeWnRQhinGimxRh45RgAVXd8wAA1VZzA= From: "Huelsemann, Martin" To: , , X-OriginalArrivalTime: 30 Aug 2007 13:28:11.0273 (UTC) FILETIME=[9C4ACF90:01C7EB09] X-Spam-Score: -1.0 (-) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi all, the notifications we are talking here about are more or less 'nice to = have' notifications. Probably not many people would subscribe to this = kind of information, to avoid signalling overload or processing power, = especially at their mobile devices. But if they receive these = notifications within messages they will receive anyway during the basic = call, they won't be angry but probably be contented about this = additional information.=20 Therefore I would also prefer a solution that avoids SUB/NOT. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Brian Stucker [mailto:bstucker@nortel.com]=20 > Gesendet: Donnerstag, 30. August 2007 08:36 > An: Paul Kyzivat; Dale.Worley@comcast.net > Cc: bliss@ietf.org > Betreff: RE: [BLISS] Use of Warning: header to transport=20 > additional statusindications >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > Dale.Worley@comcast.net wrote: > > > From: Paul Kyzivat > > >=20 > > > I agree with Brian wrt the user experience. > > > I've proposed use of Alert-Info with a URN that=20 > > identifies semantically=20 > > > the desired sort of alerting. IMO that is an appropriate=20 > > solution. > > >=20 > > > Why would we need a URN to carry the semantics when we have the=20 > > > response code? > >=20 > > If there is a response code that conveys the proper semantics=20 > > then I agree. > >=20 > > I believe the case we are discussing is call waiting. Maybe=20 > > there are other cases, but AFAIK in the call waiting case the=20 > > called user *is* alerted, and so 182 is probably the wrong=20 > > response. I gather that in addition to informing the caller=20 > > that the callee has been alerted, there is a desire to=20 > > indicate that the callee is in some state where answering=20 > > response may be delayed longer than "normal". > >=20 > > I am personally far from convinced that there is any=20 > > information here that ought to be conveyed. But if I assume=20 > > that there is reason to inform the caller of this, I have=20 > > proposed the use of A-I to convey it.=20 > > It is a reasonable mechanism for "alerting the caller" in a=20 > > particular way. > >=20 >=20 > I agree. >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 09:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQk4o-0004oM-4c; Thu, 30 Aug 2007 09:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQk4m-0004oH-Rh for bliss@ietf.org; Thu, 30 Aug 2007 09:28:48 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQk4l-0003yZ-8A for bliss@ietf.org; Thu, 30 Aug 2007 09:28:48 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Thu, 30 Aug 2007 15:28:46 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Aug 2007 15:28:45 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 30 Aug 2007 15:28:44 +0200 Message-Id: In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437116741D88@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call Waiting: Response code vs. Alert-Info Thread-Index: Acfqemu9RA3IeWnRQhinGimxRh45RgAVXd8wAA28xnA= From: "Huelsemann, Martin" To: , , X-OriginalArrivalTime: 30 Aug 2007 13:28:45.0507 (UTC) FILETIME=[B0B28130:01C7EB09] X-Spam-Score: -1.0 (-) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: bliss@ietf.org, "Alexeitsev, D" Subject: [BLISS] Call Waiting: Response code vs. Alert-Info X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org As the basic information is, that the call is presented to the callee, I = would also prefer the 180, with additional information in a regarding = Alert-Info header. 182 says you are queued, for me that means that your call isn't really = presented to the callee yet. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Brian Stucker [mailto:bstucker@nortel.com]=20 > Gesendet: Donnerstag, 30. August 2007 08:36 > An: Paul Kyzivat; Dale.Worley@comcast.net > Cc: bliss@ietf.org > Betreff: RE: [BLISS] Use of Warning: header to transport=20 > additional statusindications >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > Dale.Worley@comcast.net wrote: > > > From: Paul Kyzivat > > >=20 > > > I agree with Brian wrt the user experience. > > > I've proposed use of Alert-Info with a URN that=20 > > identifies semantically=20 > > > the desired sort of alerting. IMO that is an appropriate=20 > > solution. > > >=20 > > > Why would we need a URN to carry the semantics when we have the=20 > > > response code? > >=20 > > If there is a response code that conveys the proper semantics=20 > > then I agree. > >=20 > > I believe the case we are discussing is call waiting. Maybe=20 > > there are other cases, but AFAIK in the call waiting case the=20 > > called user *is* alerted, and so 182 is probably the wrong=20 > > response. I gather that in addition to informing the caller=20 > > that the callee has been alerted, there is a desire to=20 > > indicate that the callee is in some state where answering=20 > > response may be delayed longer than "normal". > >=20 > > I am personally far from convinced that there is any=20 > > information here that ought to be conveyed. But if I assume=20 > > that there is reason to inform the caller of this, I have=20 > > proposed the use of A-I to convey it.=20 > > It is a reasonable mechanism for "alerting the caller" in a=20 > > particular way. > >=20 >=20 > I agree. >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 09:47:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQkMO-0004eM-8B; Thu, 30 Aug 2007 09:47:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQkMN-0004eH-TG for bliss@ietf.org; Thu, 30 Aug 2007 09:46:59 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQkMN-0000sE-5q for bliss@ietf.org; Thu, 30 Aug 2007 09:46:59 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l7UDif513885; Thu, 30 Aug 2007 13:44:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transport additional statusindications Date: Thu, 30 Aug 2007 08:46:45 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437116741FD7@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additional statusindications Thread-Index: Acfqemu9RA3IeWnRQhinGimxRh45RgAVXd8wAA1VZzAAAakvwA== References: <6FC4416DDE56C44DA0AEE67BC7CA437116741D88@zrc2hxm2.corp.nortel.com> From: "Brian Stucker" To: "Huelsemann, Martin" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net]=20 > Sent: Thursday, August 30, 2007 4:28 PM > To: Stucker, Brian (RICH1:AR00); pkyzivat@cisco.com;=20 > Dale.Worley@comcast.net > Cc: bliss@ietf.org; Alexeitsev, D > Subject: AW: [BLISS] Use of Warning: header to transport=20 > additional statusindications >=20 > Hi all, >=20 > the notifications we are talking here about are more or less=20 > 'nice to have' notifications. Probably not many people would=20 > subscribe to this kind of information, to avoid signalling=20 > overload or processing power, especially at their mobile=20 > devices. But if they receive these notifications within=20 > messages they will receive anyway during the basic call, they=20 > won't be angry but probably be contented about this=20 > additional information.=20 >=20 > Therefore I would also prefer a solution that avoids SUB/NOT. Just so there's no confusion (since this was in reply to an email I = posted), I do not support a solution that *avoids* SUB/NOT, but am not = against solutions that include a way of conveying the information that = does not rely exclusively on SUB/NOT. I think the case is fairly clear = that SUB/NOT is the preferred way of conveying configuration information = from a SIP network to a SIP UA. Regards, Brian >=20 >=20 > Regards, Martin >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Brian Stucker [mailto:bstucker@nortel.com] > > Gesendet: Donnerstag, 30. August 2007 08:36 > > An: Paul Kyzivat; Dale.Worley@comcast.net > > Cc: bliss@ietf.org > > Betreff: RE: [BLISS] Use of Warning: header to transport additional=20 > > statusindications > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > > Dale.Worley@comcast.net wrote: > > > > From: Paul Kyzivat > > > >=20 > > > > I agree with Brian wrt the user experience. > > > > I've proposed use of Alert-Info with a URN that > > > identifies semantically > > > > the desired sort of alerting. IMO that is an appropriate > > > solution. > > > >=20 > > > > Why would we need a URN to carry the semantics when we have the=20 > > > > response code? > > >=20 > > > If there is a response code that conveys the proper=20 > semantics then I=20 > > > agree. > > >=20 > > > I believe the case we are discussing is call waiting. Maybe there=20 > > > are other cases, but AFAIK in the call waiting case the=20 > called user=20 > > > *is* alerted, and so 182 is probably the wrong response. I gather=20 > > > that in addition to informing the caller that the callee has been=20 > > > alerted, there is a desire to indicate that the callee is in some=20 > > > state where answering response may be delayed longer than=20 > "normal". > > >=20 > > > I am personally far from convinced that there is any information=20 > > > here that ought to be conveyed. But if I assume that=20 > there is reason=20 > > > to inform the caller of this, I have proposed the use of A-I to=20 > > > convey it. > > > It is a reasonable mechanism for "alerting the caller" in a=20 > > > particular way. > > >=20 > >=20 > > I agree. > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 10:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQkni-0006Sa-IM; Thu, 30 Aug 2007 10:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQknh-0006SU-La for bliss@ietf.org; Thu, 30 Aug 2007 10:15:13 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQkng-000536-Fr for bliss@ietf.org; Thu, 30 Aug 2007 10:15:13 -0400 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l7UEF7C08595; Thu, 30 Aug 2007 14:15:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Use of Warning: header to transport additional statusindications Date: Thu, 30 Aug 2007 09:14:59 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371167420E1@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437116741FD7@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additional statusindications Thread-Index: Acfqemu9RA3IeWnRQhinGimxRh45RgAVXd8wAA1VZzAAAakvwAABC0PQ References: <6FC4416DDE56C44DA0AEE67BC7CA437116741D88@zrc2hxm2.corp.nortel.com> <6FC4416DDE56C44DA0AEE67BC7CA437116741FD7@zrc2hxm2.corp.nortel.com> From: "Brian Stucker" To: "Brian Stucker" , "Huelsemann, Martin" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org =20 > -----Original Message----- > From: Stucker, Brian (RICH1:AR00)=20 > Sent: Thursday, August 30, 2007 4:47 PM > To: Huelsemann, Martin; pkyzivat@cisco.com; Dale.Worley@comcast.net > Cc: bliss@ietf.org; Alexeitsev, D > Subject: RE: [BLISS] Use of Warning: header to transport=20 > additional statusindications >=20 > =20 >=20 > > -----Original Message----- > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > Sent: Thursday, August 30, 2007 4:28 PM > > To: Stucker, Brian (RICH1:AR00); pkyzivat@cisco.com;=20 > > Dale.Worley@comcast.net > > Cc: bliss@ietf.org; Alexeitsev, D > > Subject: AW: [BLISS] Use of Warning: header to transport additional=20 > > statusindications > >=20 > > Hi all, > >=20 > > the notifications we are talking here about are more or=20 > less 'nice to=20 > > have' notifications. Probably not many people would=20 > subscribe to this=20 > > kind of information, to avoid signalling overload or=20 > processing power,=20 > > especially at their mobile devices. But if they receive these=20 > > notifications within messages they will receive anyway during the=20 > > basic call, they won't be angry but probably be contented=20 > about this=20 > > additional information. > >=20 > > Therefore I would also prefer a solution that avoids SUB/NOT. >=20 > Just so there's no confusion (since this was in reply to an=20 > email I posted), I do not support a solution that *avoids*=20 > SUB/NOT, but am not against solutions that include a way of=20 > conveying the information that does not rely exclusively on=20 > SUB/NOT. I think the case is fairly clear that SUB/NOT is the=20 > preferred way of conveying configuration information from a=20 > SIP network to a SIP UA. Correction/clarification... SUB/NOT is the preferred way to convey a change has occurred in configuration information. >=20 > Regards, > Brian >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 17:32:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQrdA-0005QH-DU; Thu, 30 Aug 2007 17:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQrd9-0005Q4-H4 for bliss@ietf.org; Thu, 30 Aug 2007 17:32:47 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQrd8-0007j0-8g for bliss@ietf.org; Thu, 30 Aug 2007 17:32:47 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20070830213245m13003ldpke>; Thu, 30 Aug 2007 21:32:45 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7ULWi4p016426 for ; Thu, 30 Aug 2007 17:32:44 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7ULWh7f016422; Thu, 30 Aug 2007 17:32:44 -0400 Date: Thu, 30 Aug 2007 17:32:44 -0400 Message-Id: <200708302132.l7ULWh7f016422@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437116741D94@zrc2hxm2.corp.nortel.com> (bstucker@nortel.com) Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <200708291844.l7TIiwEa028626@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA437116741D94@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Brian Stucker" > You're quite correct that the user receives a deficient experience. > But I think you're mis-identifying the *cause* of the > deficient experience. From a SIP point of view, the called > end is reporting status quite correctly and usefully -- 182 > means "you're being queued and a user has not yet been > notified". The problem, IMHO, is that when the calling UA > receives a 182 that it does not relay that information to the > user in some manner. It thus fails to transport the status > information that it has receives to the user. What the UA > needs to do is to provide some sort of comfort tone or > ringback when it receives such status messages, not just for > 180. (IIRC some PSTN systems will provide a tone when a call > is forwarded; this would be a natural report for receiving a 181.) If we were having this discussion 7 years ago, I'd agree with you, and to a certain extent I agree with you now. However, this is pretty much the way UAs are told to work and are built to work (don't start ringback until 180) to avoid ghost-ringback problems which are equally confusing to people. There's too many SIP UAs out there that would need to be changed, and it's unclear that the change is safe. Well, yes, you wouldn't want to give the user ringback unless a 180 was received, because ringback *means* the same thing as a 180. But if the phone receives other call-progress messages, it should provide corresponding other indicators to the caller. As for "too many SIP UAs out there that would need to be changed", every SIP UA I've ever seen gets its software updated multiple times per year... In regard to the sub-problem of "ringing for call waiting", I think Paul has described it well, because no existing 18x message has the right semantics -- the user is being notified, but we have reason to expect the user to answer more slowly than normal. Though I suppose we should check whether the users really do answer more slowly -- the user is occupied, yes, but he's also right there at the phone. A good test would be "Do networks give the call more time to ring during call waiting before forwarding to voicemail?" If the telcos have never found need to allow more time, then they've probably determined that people answer call waiting calls as fast as ordinary calls. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 17:37:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQri8-0003y2-9v; Thu, 30 Aug 2007 17:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQri3-0003xh-IU for bliss@ietf.org; Thu, 30 Aug 2007 17:37:51 -0400 Received: from rwcrmhc13.comcast.net ([216.148.227.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQri2-0007od-BN for bliss@ietf.org; Thu, 30 Aug 2007 17:37:51 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (rwcrmhc13) with ESMTP id <20070830213749m13003jguue>; Thu, 30 Aug 2007 21:37:49 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7ULbm4p016788 for ; Thu, 30 Aug 2007 17:37:48 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7ULbmMS016784; Thu, 30 Aug 2007 17:37:48 -0400 Date: Thu, 30 Aug 2007 17:37:48 -0400 Message-Id: <200708302137.l7ULbmMS016784@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA437116741D93@zrc2hxm2.corp.nortel.com> (bstucker@nortel.com) Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <200708291903.l7TJ3XAx029987@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA437116741D93@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Brian Stucker" > In this sort of situation, I would expect the SIP-to-PSTN > gateway to provide the resource to which the SIP UA > subscribes in order to discover the call forwarding status > for the AOR. The gateway is already translating all other > aspects of the attachment of the UA to its real home switch > down in the PSTN. I don't think this is a reliable solution because the status of the call forwarding could change in the PSTN and the gateway would not know that such had changed until a call is made. This doesn't mean that you can't use subscribe/notify in any situation. I definitely think you can, but just that it's likely not realistic in this case. I don't know, but I have a strong suspicion that this is the case. There's something here that I am overlooking... Let me propose that the gateway provide an event package that reports the call-forwarding status that it obtains by some undefined means, and that we understand that the event package status may lag behind the real call-forwarding status by some period of time. In that case, the data is reliable, but it may be slow. Indeed, it's no slower than reporting the status using a special dial tone or ring tone, which is the PSTN technique we're comparing with. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Thu Aug 30 20:36:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQuUa-0004SP-1W; Thu, 30 Aug 2007 20:36:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQuUY-0004SI-Kt for bliss@ietf.org; Thu, 30 Aug 2007 20:36:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQuUX-0002lv-Dt for bliss@ietf.org; Thu, 30 Aug 2007 20:36:06 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Aug 2007 20:36:04 -0400 X-IronPort-AV: i="4.19,328,1183348800"; d="scan'208"; a="69669237:sNHT51459348" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7V0a5f7017921; Thu, 30 Aug 2007 20:36:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7V0a5Ln011174; Fri, 31 Aug 2007 00:36:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 20:36:04 -0400 Received: from [10.86.241.81] ([10.86.241.81]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Aug 2007 20:36:04 -0400 Message-ID: <46D76274.8010707@cisco.com> Date: Thu, 30 Aug 2007 20:36:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dale.Worley@comcast.net Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <200708291903.l7TJ3XAx029987@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA437116741D93@zrc2hxm2.corp.nortel.com> <200708302137.l7ULbmMS016784@dragon.ariadne.com> In-Reply-To: <200708302137.l7ULbmMS016784@dragon.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2007 00:36:04.0587 (UTC) FILETIME=[E9D943B0:01C7EB66] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2005; t=1188520565; x=1189384565; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Use=20of=20Warning=3A=20header=20to=20trans port=20additional=20status=0A=20indications |Sender:=20 |To:=20Dale.Worley@comcast.net; bh=HLcNWBwMV6yEmD19BdMEF/bUy+RUCcCooyrjBdM2WS8=; b=PaK3T7DOLXjaUorecu3oPYrRYx4ORnkYsUaVAd7FE8NW7DeEznIzlMWWfrR/cD+20uujSOo+ OexqR6JmfQyAR8ZbTnG7h9z59GI4aTmg1x2uwXCbJF9JxitbkHv+IEsl; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org This is what I had in mind as well. I know there is resistance to having event packages for every little thing like this. A solution that has been discussed elsewhere is to couple this with the config event package. There is already the notion of per-aor config obtained that way. IMO the forwarding status is a pretty plausible piece of config information about the AOR, so this fits pretty well. Paul Dale.Worley@comcast.net wrote: > From: "Brian Stucker" > > > In this sort of situation, I would expect the SIP-to-PSTN > > gateway to provide the resource to which the SIP UA > > subscribes in order to discover the call forwarding status > > for the AOR. The gateway is already translating all other > > aspects of the attachment of the UA to its real home switch > > down in the PSTN. > > I don't think this is a reliable solution because the status of the call > forwarding could change in the PSTN and the gateway would not know that > such had changed until a call is made. This doesn't mean that you can't > use subscribe/notify in any situation. I definitely think you can, but > just that it's likely not realistic in this case. I don't know, but I > have a strong suspicion that this is the case. > > There's something here that I am overlooking... Let me propose that > the gateway provide an event package that reports the call-forwarding > status that it obtains by some undefined means, and that we understand > that the event package status may lag behind the real call-forwarding > status by some period of time. In that case, the data is reliable, > but it may be slow. Indeed, it's no slower than reporting the status > using a special dial tone or ring tone, which is the PSTN technique > we're comparing with. > > Dale > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 31 04:13:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR1dX-0000CO-U8; Fri, 31 Aug 2007 04:13:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR1dW-0000BL-Ou for bliss@ietf.org; Fri, 31 Aug 2007 04:13:50 -0400 Received: from mailgate.siemenscomms.co.uk ([195.171.110.225] helo=bemg01.siemenscomms.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR1dW-0003tH-1Q for bliss@ietf.org; Fri, 31 Aug 2007 04:13:50 -0400 Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0JNM00L8GPIJDH@siemenscomms.co.uk> for bliss@ietf.org; Fri, 31 Aug 2007 09:13:31 +0100 (BST) Date: Fri, 31 Aug 2007 09:13:42 +0100 From: "Elwell, John" Subject: RE: [BLISS] Call Waiting: Response code vs. Alert-Info In-reply-to: To: "Huelsemann, Martin" , bstucker@nortel.com, pkyzivat@cisco.com, Dale.Worley@comcast.net Message-id: <0D5F89FAC29E2C41B98A6A762007F5D02CF224@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [BLISS] Call Waiting: Response code vs. Alert-Info Thread-Index: Acfqemu9RA3IeWnRQhinGimxRh45RgAVXd8wAA28xnAAJ+ZosA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <6FC4416DDE56C44DA0AEE67BC7CA437116741D88@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Martin, I am fine with this distinction. However, going back to much earlier in = this thread, I seem to recall some mention of call waiting being = implemented at a proxy and not at the UAS, and in this case the user = would not be aware of the waiting call. Or have I misunderstood = something? I am not advocating proxy involvement - but I do seem to = recall something. John=20 > -----Original Message----- > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net]=20 > Sent: 30 August 2007 14:29 > To: bstucker@nortel.com; pkyzivat@cisco.com; Dale.Worley@comcast.net > Cc: bliss@ietf.org; Alexeitsev, D > Subject: [BLISS] Call Waiting: Response code vs. Alert-Info >=20 > As the basic information is, that the call is presented to=20 > the callee, I would also prefer the 180, with additional=20 > information in a regarding Alert-Info header. >=20 > 182 says you are queued, for me that means that your call=20 > isn't really presented to the callee yet. >=20 >=20 > Regards, Martin >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Brian Stucker [mailto:bstucker@nortel.com]=20 > > Gesendet: Donnerstag, 30. August 2007 08:36 > > An: Paul Kyzivat; Dale.Worley@comcast.net > > Cc: bliss@ietf.org > > Betreff: RE: [BLISS] Use of Warning: header to transport=20 > > additional statusindications > >=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > > Dale.Worley@comcast.net wrote: > > > > From: Paul Kyzivat > > > >=20 > > > > I agree with Brian wrt the user experience. > > > > I've proposed use of Alert-Info with a URN that=20 > > > identifies semantically=20 > > > > the desired sort of alerting. IMO that is an appropriate=20 > > > solution. > > > >=20 > > > > Why would we need a URN to carry the semantics when we have the=20 > > > > response code? > > >=20 > > > If there is a response code that conveys the proper semantics=20 > > > then I agree. > > >=20 > > > I believe the case we are discussing is call waiting. Maybe=20 > > > there are other cases, but AFAIK in the call waiting case the=20 > > > called user *is* alerted, and so 182 is probably the wrong=20 > > > response. I gather that in addition to informing the caller=20 > > > that the callee has been alerted, there is a desire to=20 > > > indicate that the callee is in some state where answering=20 > > > response may be delayed longer than "normal". > > >=20 > > > I am personally far from convinced that there is any=20 > > > information here that ought to be conveyed. But if I assume=20 > > > that there is reason to inform the caller of this, I have=20 > > > proposed the use of A-I to convey it.=20 > > > It is a reasonable mechanism for "alerting the caller" in a=20 > > > particular way. > > >=20 > >=20 > > I agree. > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 31 05:18:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR2e4-00038w-QP; Fri, 31 Aug 2007 05:18:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR2e2-00037G-Na for bliss@ietf.org; Fri, 31 Aug 2007 05:18:26 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR2e2-0005Yi-2c for bliss@ietf.org; Fri, 31 Aug 2007 05:18:26 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Fri, 31 Aug 2007 11:18:24 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Aug 2007 11:18:21 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] Use of Warning: header to transport additionalstatusindications Date: Fri, 31 Aug 2007 11:18:19 +0200 Message-Id: In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA4371167420E1@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Use of Warning: header to transport additionalstatusindications Thread-Index: Acfqemu9RA3IeWnRQhinGimxRh45RgAVXd8wAA1VZzAAAakvwAABC0PQACdswEA= From: "Huelsemann, Martin" To: , , X-OriginalArrivalTime: 31 Aug 2007 09:18:21.0688 (UTC) FILETIME=[E0376780:01C7EBAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Yes of course, if there are state changes you have to use SUB/NOT to = receive notifications about this, no doubt about that.=20 But in our use-case there has been no change in the state of your = call-diversion activation, it's just a reminder (or warning?) that the = diversion is still active, and it will be active until you deactivate it = again. BR, Martin > -----Urspr=FCngliche Nachricht----- > Von: Brian Stucker [mailto:bstucker@nortel.com]=20 > Gesendet: Donnerstag, 30. August 2007 16:15 > An: Brian Stucker; H=FClsemann, Martin; pkyzivat@cisco.com;=20 > Dale.Worley@comcast.net > Cc: bliss@ietf.org; Alexeitsev, Denis > Betreff: RE: [BLISS] Use of Warning: header to transport=20 > additionalstatusindications >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Stucker, Brian (RICH1:AR00)=20 > > Sent: Thursday, August 30, 2007 4:47 PM > > To: Huelsemann, Martin; pkyzivat@cisco.com; Dale.Worley@comcast.net > > Cc: bliss@ietf.org; Alexeitsev, D > > Subject: RE: [BLISS] Use of Warning: header to transport=20 > > additional statusindications > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net] > > > Sent: Thursday, August 30, 2007 4:28 PM > > > To: Stucker, Brian (RICH1:AR00); pkyzivat@cisco.com;=20 > > > Dale.Worley@comcast.net > > > Cc: bliss@ietf.org; Alexeitsev, D > > > Subject: AW: [BLISS] Use of Warning: header to transport=20 > additional=20 > > > statusindications > > >=20 > > > Hi all, > > >=20 > > > the notifications we are talking here about are more or=20 > > less 'nice to=20 > > > have' notifications. Probably not many people would=20 > > subscribe to this=20 > > > kind of information, to avoid signalling overload or=20 > > processing power,=20 > > > especially at their mobile devices. But if they receive these=20 > > > notifications within messages they will receive anyway during the=20 > > > basic call, they won't be angry but probably be contented=20 > > about this=20 > > > additional information. > > >=20 > > > Therefore I would also prefer a solution that avoids SUB/NOT. > >=20 > > Just so there's no confusion (since this was in reply to an=20 > > email I posted), I do not support a solution that *avoids*=20 > > SUB/NOT, but am not against solutions that include a way of=20 > > conveying the information that does not rely exclusively on=20 > > SUB/NOT. I think the case is fairly clear that SUB/NOT is the=20 > > preferred way of conveying configuration information from a=20 > > SIP network to a SIP UA. >=20 > Correction/clarification... SUB/NOT is the preferred way to convey a > change has occurred in configuration information. >=20 > >=20 > > Regards, > > Brian > >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 31 05:55:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR3Do-0003L1-Pp; Fri, 31 Aug 2007 05:55:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR3Dn-0003Kv-HH for bliss@ietf.org; Fri, 31 Aug 2007 05:55:23 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR3Dm-0006Y5-O0 for bliss@ietf.org; Fri, 31 Aug 2007 05:55:23 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Fri, 31 Aug 2007 11:55:21 +0200 Received: from S4DE9JSAAHW.ost.t-com.de ([10.125.177.160]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Aug 2007 11:55:20 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [BLISS] Call Waiting: Response code vs. Alert-Info Date: Fri, 31 Aug 2007 11:55:20 +0200 Message-Id: In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D02CF224@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Call Waiting: Response code vs. Alert-Info Thread-Index: Acfqemu9RA3IeWnRQhinGimxRh45RgAVXd8wAA28xnAAJ+ZosAAByYYA From: "Huelsemann, Martin" To: , , , X-OriginalArrivalTime: 31 Aug 2007 09:55:20.0682 (UTC) FILETIME=[0AD704A0:01C7EBB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: bliss@ietf.org, "Alexeitsev, D" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi John, there are different scenarios for CW, implemented at a UAS or a proxy. = In both cases the call will be presenred to the callee and a CW = notification to the caller is needed. In the proxy case, also a CW indication to the callee is needed, = informing the callee about the fact that there are currently no = resources for this call. So the user can actively decide if he puts = another call on hold and accepts the new call, or if he doesn't accept = the new call. But that is another issue, I will start a thread to this, = too, but first I have to check what can be done with RFC 3312 = preconditions. Regards, Martin > -----Urspr=FCngliche Nachricht----- > Von: Elwell, John [mailto:john.elwell@siemens.com]=20 > Gesendet: Freitag, 31. August 2007 10:14 > An: H=FClsemann, Martin; bstucker@nortel.com;=20 > pkyzivat@cisco.com; Dale.Worley@comcast.net > Cc: bliss@ietf.org; Alexeitsev, Denis > Betreff: RE: [BLISS] Call Waiting: Response code vs. Alert-Info >=20 >=20 > Martin, >=20 > I am fine with this distinction. However, going back to much=20 > earlier in this thread, I seem to recall some mention of call=20 > waiting being implemented at a proxy and not at the UAS, and=20 > in this case the user would not be aware of the waiting call.=20 > Or have I misunderstood something? I am not advocating proxy=20 > involvement - but I do seem to recall something. >=20 > John=20 >=20 > > -----Original Message----- > > From: Huelsemann, Martin [mailto:Martin.Huelsemann@t-com.net]=20 > > Sent: 30 August 2007 14:29 > > To: bstucker@nortel.com; pkyzivat@cisco.com; Dale.Worley@comcast.net > > Cc: bliss@ietf.org; Alexeitsev, D > > Subject: [BLISS] Call Waiting: Response code vs. Alert-Info > >=20 > > As the basic information is, that the call is presented to=20 > > the callee, I would also prefer the 180, with additional=20 > > information in a regarding Alert-Info header. > >=20 > > 182 says you are queued, for me that means that your call=20 > > isn't really presented to the callee yet. > >=20 > >=20 > > Regards, Martin > >=20 > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Brian Stucker [mailto:bstucker@nortel.com]=20 > > > Gesendet: Donnerstag, 30. August 2007 08:36 > > > An: Paul Kyzivat; Dale.Worley@comcast.net > > > Cc: bliss@ietf.org > > > Betreff: RE: [BLISS] Use of Warning: header to transport=20 > > > additional statusindications > > >=20 > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > > > > Dale.Worley@comcast.net wrote: > > > > > From: Paul Kyzivat > > > > >=20 > > > > > I agree with Brian wrt the user experience. > > > > > I've proposed use of Alert-Info with a URN that=20 > > > > identifies semantically=20 > > > > > the desired sort of alerting. IMO that is an appropriate=20 > > > > solution. > > > > >=20 > > > > > Why would we need a URN to carry the semantics when=20 > we have the=20 > > > > > response code? > > > >=20 > > > > If there is a response code that conveys the proper semantics=20 > > > > then I agree. > > > >=20 > > > > I believe the case we are discussing is call waiting. Maybe=20 > > > > there are other cases, but AFAIK in the call waiting case the=20 > > > > called user *is* alerted, and so 182 is probably the wrong=20 > > > > response. I gather that in addition to informing the caller=20 > > > > that the callee has been alerted, there is a desire to=20 > > > > indicate that the callee is in some state where answering=20 > > > > response may be delayed longer than "normal". > > > >=20 > > > > I am personally far from convinced that there is any=20 > > > > information here that ought to be conveyed. But if I assume=20 > > > > that there is reason to inform the caller of this, I have=20 > > > > proposed the use of A-I to convey it.=20 > > > > It is a reasonable mechanism for "alerting the caller" in a=20 > > > > particular way. > > > >=20 > > >=20 > > > I agree. > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www1.ietf.org/mailman/listinfo/bliss > > >=20 > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www1.ietf.org/mailman/listinfo/bliss > >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri Aug 31 16:46:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRDO1-00035Y-QU; Fri, 31 Aug 2007 16:46:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRDO0-00030s-RU for bliss@ietf.org; Fri, 31 Aug 2007 16:46:36 -0400 Received: from alnrmhc13.comcast.net ([204.127.225.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRDNz-0002Za-M3 for bliss@ietf.org; Fri, 31 Aug 2007 16:46:36 -0400 Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc13) with ESMTP id <20070831204634b1300egtnbe>; Fri, 31 Aug 2007 20:46:34 +0000 Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l7VKkX4p021189 for ; Fri, 31 Aug 2007 16:46:33 -0400 Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l7VKkXR0021185; Fri, 31 Aug 2007 16:46:33 -0400 Date: Fri, 31 Aug 2007 16:46:33 -0400 Message-Id: <200708312046.l7VKkXR0021185@dragon.ariadne.com> To: bliss@ietf.org From: Dale.Worley@comcast.net In-reply-to: <6FC4416DDE56C44DA0AEE67BC7CA4371167ED652@zrc2hxm2.corp.nortel.com> (bstucker@nortel.com) Subject: Re: [BLISS] Use of Warning: header to transport additional status indications References: <200708260304.l7Q34V3R027860@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371165E27C2@zrc2hxm2.corp.nortel.com> <200708272008.l7RK8DT0018720@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA43711665F514@zrc2hxm2.corp.nortel.com> <200708291903.l7TJ3XAx029987@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA437116741D93@zrc2hxm2.corp.nortel.com> <200708302137.l7ULbmMS016784@dragon.ariadne.com> <6FC4416DDE56C44DA0AEE67BC7CA4371167ED652@zrc2hxm2.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org From: "Brian Stucker" Interesting way of putting it, but you've missed one thing: the indication is always present and in-sync with the status of the feature in the existing PSTN technique. Is that really so, though? My PSTN-provided voicemail uses a modified dial tone to indicate that I have new voicemail present. But there is a delay in reporting -- I can call the voicemail retrieval number, play and delete a new message, but if I hang up and immediately go off-hook again, the modified dial tone will remain. Is PSTN call-forwarding reporting actually always in-sync? Or is it just good enough that people are satisfied? It may not be in your case. Otherwise, I agree, yes, this would be equivalent. However, if people KNOW that they have call forwarding setup and don't get the indication as they expect, due to lag, that can be confusing to them and interpreted as unreliable. We can also use some tricks to improve the reporting time lag -- e.g., the gateway can be programmed to know the dial codes for activating and deactivating call forwarding, and can be careful to quickly get a refresh of the call-forwarding state after the end of a call that was dialed using one of those dial codes. I don't think that these problems are really that difficult that we must meticulously replicate what the PSTN already does. And we really should avoid architectural contortions of SIP; it's messy enough already. Dale _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss