Subject: Re: [dispatch] [Sip] New version of "draft-avasasarala-dispatch-comm-diversion-info" draft submitted

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Wed, 9 Sep 2009 17:34:43 +0800

Hi Gilad
 
Thanks for reviewing the document. Here my comments with <Ranjit>
Regards 
Ranjit 

________________________________

From: Gilad Shaham [mailto:[email-masked]] 
Sent: Tuesday, August 18, 2009 5:50 AM
To: Avasarala Ranjit-A20990; [email-masked]; [email-masked]
Subject: RE: [Sip] New version
of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted

Hi,

See some comments

Page 5:

   "... For e.g. the subscriber wanted to diverted all incoming calls to
voice-mail,
   between 3.00 p.m. to 4.00 p.m.  Yet, by mistake she configures the
   time-duration as 3.00 to 4.00 p.m"

Some of the sentence needs restructuring and I also don't fully
understand the example. Is it AM-PM or wrong field was configured? 

<Ranjit> Agreed.  Will correct the sentence. 

Page 12:

What if time-range is missing? What should be the default? Sounds to me
the default should be the current time with no end date. 

<Ranjit> if time-range is missing, then notifications for all
communication diversions are sent. 

Page 14:

In Comm-div-info-selection-criteria there are several disable-*
subsections, yet their text describes these element gives the subscriber
option of adding information. Shouldn't this be for omitting information
or alternatively, call these elements "enable-*" or did I misunderstand
the purpose. 

<Ranjit>  E.g disable-originating-user-info -> this element gives the
subscriber the option of adding originating-user-info element to the
notification information. The default value is false which means that
the subscriber wants the originating-user-info element to be present as
part of the notification information. If the value is set to TRUE, then
originating-user-info element is removed from the notification
information document. 

Page 16:

             <user-name>Boss</originating-user-name>

Should be

             <user-name>Boss</user-name> 
<Ranjit> Corrected.

It might be also useful to see an example of periodic request. 

<Ranjit> Will see if I can add one. 

Page 21:

503 is there, but I don't see 500. Some implementations will avoid 503
and use 500 due to discussion related to this
http://tools.ietf.org/html/draft-hilt-sip-correction-503-01 (now
expired, but still affected some vendor decisions). I might be able to
think of some scenario that involves 502, but I assume this is a result
of the diversion implementation itself so maybe that's the context of
this discussion. 

<Ranjit> Will add 500 also. 

Thanks

Thanks

Gilad

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Avasarala Ranjit-A20990
Sent: Monday, August 17, 2009 10:07 AM
To: [email-masked]; [email-masked]
Subject: [Sip] New version
of"draft-avasasarala-dispatch-comm-diversion-info" draft submitted

Hi All 

We have submitted an updated version of
draft-avasasarala-dispatch-comm-diversion-info 

It can be accessed at:
http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-no
tification-01.txt
<http://www.ietf.org/internet-drafts/draft-avasarala-dispatch-comm-div-n
otification-01.txt> 

This draft proposes a SIP Event package for Communication Diversions
Notification Information and conforms to procedures and schema described
in 3GPP TS 24.604. 

Please review and comment

Regards 
Ranjit

---

From: "John-Luc Bakker" <[email-masked]>
Date: Fri, 11 Sep 2009 10:38:07 -0500

Hi Gilad,

> 503 is there, but I don't see 500. Some implementations will avoid 503
and use 500 due to 

> discussion related to this
expired,

>  but still affected some vendor decisions). I might be able to think
of some scenario that 

> involves 502, but I assume this is a result of the diversion
implementation itself so maybe 

> that's the context of this discussion.

The referenced expired draft mentions overload situations. 503

(Service Unavailable) response code is provided as a remedy for servers
under

Overload, the draft says.  

The 503 code in this document is to be interpreted as "subscriber not
reachable" (e.g. see RFC 4458).

Moreover, sending a NOTIFY with an XML document indicating a diversion
(re-directions or forwarding) 

of an incoming communication session request due to a server in a
overload situation, may even amplify 

the overload condition.

Regards,

            John-Luc

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gilad Shaham
Sent: Monday, August 17, 2009 7:20 PM
To: Avasarala Ranjit-A20990; [email-masked]; [email-masked]
Subject: Re: [Sip] New
versionof"draft-avasasarala-dispatch-comm-diversion-info" draft
submitted

Hi,

See some comments

Page 5:

Page 12:

Page 14:

Page 16:

Should be

Page 21:

Thanks

Gilad

Hi All 

It can be accessed at:

Regards 
Ranjit 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.