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

["Ranjit Avasarala" <[e-mail]>]

RE: [Sip] draft-ietf-sip-refer-02 - SHOULD strength when sending NOTIFYis it
a standard SIP message? like 200

Regards
Ranjit

  -----Original Message-----
  From: Sriram Parameswar [mailto:[e-mail]]
  Sent: Thursday, December 13, 2001 2:51 PM
  To: 'ranjitka'; 'Robert Sparks'; 'JF Rey'; sip
  Subject: RE: [Sip] draft-ietf-sip-refer-02 - SHOULD strength when sending
NOTIFY


  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: [phone]
  Interactive Multimedia Server (IMS) Fax: [phone]
  Nortel Networks, Richardson USA  Email: [e-mail]



  -----Original Message-----
  From: Ranjit Avasarala [mailto:[e-mail]]
  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:[e-mail]]
  Sent: Thursday, December 13, 2001 10:07 AM
  To: 'JF Rey'; [e-mail]
  Subject: RE: [Sip] draft-ietf-sip-refer-02 - SHOULD strength when
  sending NOTIFY



  inline

  > -----Original Message-----
  > From: JF Rey [mailto:[e-mail]]
  >
  > 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 [e-mail] for questions on current sip
  Use [e-mail] 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 [e-mail] for questions on current sip
  Use [e-mail] for new developments on the application of sip