RE: [Sip] draft-ietf-sip-refer-02 - SHOULD strength when sending NOTIFY

"Sriram Parameswar" <sriramp@nortelnetworks.com> Thu, 13 December 2001 21:04 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29227 for <sip-archive@odin.ietf.org>; Thu, 13 Dec 2001 16:04:30 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19108 for sip-archive@odin.ietf.org; Thu, 13 Dec 2001 16:04:31 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18319; Thu, 13 Dec 2001 15:52:17 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18219 for <sip@optimus.ietf.org>; Thu, 13 Dec 2001 15:52:11 -0500 (EST)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29048 for <sip@ietf.org>; Thu, 13 Dec 2001 15:52:09 -0500 (EST)
Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBDKpXm00475; Thu, 13 Dec 2001 14:51:33 -0600 (CST)
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <YXCBY550>; Thu, 13 Dec 2001 14:50:22 -0600
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D41B42EC@zrc2c014.us.nortel.com>
From: Sriram Parameswar <sriramp@nortelnetworks.com>
To: 'ranjitka' <ranjitka@email.masconit.com>, 'Robert Sparks' <rsparks@dynamicsoft.com>, 'JF Rey' <jfr@post.com>, sip <sip@ietf.org>
Subject: RE: [Sip] draft-ietf-sip-refer-02 - SHOULD strength when sending NOTIFY
Date: Thu, 13 Dec 2001 14:50:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18417.D4E646E0"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

202 signifies that the Transferee has "Accepted" your REFER. It is not an
indication of success or failure - that will come in the NOTIFY.

HTH.

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com


-----Original Message-----
From: Ranjit Avasarala [mailto:ranjitka@email.masconit.com]
Sent: Thursday, December 13, 2001 12:54 PM
To: 'Robert Sparks'; 'JF Rey'; sip
Subject: RE: [Sip] draft-ietf-sip-refer-02 - SHOULD strength when
sending NOTIFY


what does 202 signify?


Regards
Ranjit 

-----Original Message-----
From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
Sent: Thursday, December 13, 2001 10:07 AM
To: 'JF Rey'; sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-refer-02 - SHOULD strength when
sending NOTIFY


inline

> -----Original Message-----
> From: JF Rey [mailto:jfr@post.com]
> 
> Hi,
> 
> I'm a bit confused about the way NOTIFY are used by the 
> "referee" party.
> 
> referer              referee
>  |====== SIP session ===|
>  |--------REFER-------> |
>  |<--------202--------- |----INVITE -->
>  |                      |<---180------
>         ... quite a long time ...
>  |<------NOTIFY ------  |<---200------ 
>  |----------200-------->|
>  |---------- BYE ------>|
> 
> draft-ietf-sip-refer-02 states :
> "3.5.3.1 Using NOTIFY
> Once it is known whether the reference succeeded or failed, 
> the UA receiving the REFER SHOULD notify the agent sending 
> the refer using the NOTIFY mechanism [...]"
> 
> All the example flows I've seen around use the NOTIFY 
> mechanism whenever a REFER is accepted. 
> 
> If I understand the "SHOULD" strength correctly, the referer 
> can't know whether the referee will send a NOTIFY. So it 
> can't know when to stop waiting for a NOTIFY and when to send 
> a BYE. I think that's quite awkward. 

The referer is going to have to be prepared to never receive
a NOTIFY whether that requirement is a MUST or a SHOULD. IIRC, the
proponents of SHOULD earlier argued that they had systems where
they knew the referer did not care about the result and didn't want
the referee/network to be burdened with an effectively useless 
NOTIFY. However - later in the message you caused me to realize
we need to realign with sip-events. See below.

> 
> Besides, I understand that nothing prevents a referee to send 
> NOTIFY on provisional responses (and not only on final 
> responses). But the way the sentence is written : "whether 
> the reference succeeded or failed" does not really take 
> provisional responses into account. No example in 
> draft-ietf-sip-cc-transfer-05.txt shows NOTIFY triggered by 
> 1xx. If the referee INVITEs a human, the referer may have a 
> very long time to wait before receiving a NOTIFY triggered by 
> the 200 response to the INVITE.

This clarification has already been requested and will be added
to the drafts. I don't understand how the last sentence relates
to the rest of the paragraph though. It is correct in the presence
or absence of NOTIFYs carrying progress information.

> 
> Do people implement REFER without the NOTIFY mechanism ?

I don't know. If someone does it would help if they speak up.

>
> If 
> we can't change the SHOULD strength, could we have a way for 
> the referee to indicate that it will send NOTIFY ? 

The current sip-events draft requires an immediate notify,
so I think this may be moot. I think we need to align to that
change in sip-events - and the SHOULD you object to effectively
goes away. However, when implementing, you still need to protect
yourself against a NOTIFY never arriving for robustness.

>Could the 
> wording in 3.5.3.1 include NOTIFY on provisional responses ?
Yes


RjS

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip