Subject: Re: [siprec] #26: Do we need REQ-008 on failover?

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 07 Sep 2010 13:21:54 -0000

#26: Do we need REQ-008 on failover?
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |       Owner:  krehor@…        
     Type:  defect                              |      Status:  new             
 Priority:  minor                               |   Milestone:                  
Component:  Requirements                        |     Version:                  
 Severity:  -                                   |    Keywords:                  
------------------------------------------------+---------------------------

Comment(by john.elwell@…):

 There seems to have been no discussion on this, which has been around a
 couple of months. My proposal is to delete REQ-008.

 John

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/26#comment:1>
siprec <http://tools.ietf.org/siprec/>

---

From: "siprec issue tracker" <[email-masked]>
Date: Thu, 09 Sep 2010 07:25:52 -0000

Type:  defect                              |      Status:  assigned        
Changes (by krehor@…):

  * status:  new => assigned

Comment:

 >  was it intended to express more than what it appears to express at face
 value,
 >  e.g., a requirement to failover without loss of recorded data?

 I think there are two points:
 1) we should support failover from one SRS to another
 2) the Communication Session will not be impacted by moving a Recording
 Session from one SRS to another.

 This isn't stating there should be no loss of recorded data. That's a
 different requirement.

 > I would have thought most plausible mechanisms would not prevent this -
 > it would be up to the SRC, if suitably configured, to failover to a
 > different SRS. So is this requirement really needed?

 I think it's useful to specify requirements of the SRC as they relate to
 the SRS and Recording Session.

 However I believe this should be changed to a MUST requirement (from
 SHOULD).

 Ken

-- 
Ticket URL: <https://trac.tools.ietf.org/wg/siprec/trac/ticket/26#comment:2>
siprec <http://tools.ietf.org/siprec/>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 9 Sep 2010 10:08:07 +0200

Ken,

I have no objection to what you propose.

John (as individual) 

> -----Original Message-----
> From: siprec issue tracker [mailto:[email-masked]] 
> Sent: 09 September 2010 08:26
> To: [email-masked]; Elwell, John
> Cc: [email-masked]
> Subject: Re: [siprec] #26: Do we need REQ-008 on failover?
> 
>  Reporter:  john.elwell@...                       |       
> Owner:  krehor@...        
>      Type:  defect                              |      
> Status:  assigned        
>  Priority:  minor                               |   
> Milestone:                  
>  Severity:  -                                   |    
> Keywords:                  
> Changes (by krehor@...):
> Ticket URL: 
> <https://trac.tools.ietf.org/wg/siprec/trac/ticket/26#comment:2>

---

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 14 Sep 2010 01:13:29 -0000

Comment(by dave.smith@…):

 Probably we could simplify our first phase efforts and remove this
 requirement since once we specify the primary SIPREC req'ts, failures/HA
 could be handled as an extension of the existing req'ts, and the existing
 req'ts do not preclude it.
 Possibly a later phase of SIPREC could add input/standards for HA.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/siprec/trac/ticket/26#comment:3>
siprec <http://tools.ietf.org/siprec/>

---

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 28 Sep 2010 07:31:03 -0000

* status:  assigned => new

Comment:

 This form of HA could be considered fundamental to SIP anyway, so we could
 delete this requirement and defer to the next version.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/26#comment:4>
siprec <http://tools.ietf.org/siprec/>

---

From: "siprec issue tracker" <[email-masked]>
Date: Tue, 28 Sep 2010 07:50:07 -0000

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/26#comment:5>
siprec <http://tools.ietf.org/siprec/>