Subject: RE: [AVT] RFC 3711 and High Availability

From: "Yuval Nissan" <[email-masked]>
Date: Mon, 22 Nov 2004 18:32:08 +0200

David,
Assuming you need to do this process on many channels at once (when for example one board crashes with hundreds of channels), I don't think this solution is feasible. What do you think?

Thanks
Yuval

-----Original Message-----
From: David R Oran [mailto:[email-masked]]
Sent: Monday, November 22, 2004 3:49 PM
To: Mark Baugher
Cc: [email-masked]; Yuval Nissan
Subject: Re: [AVT] RFC 3711 and High Availability

Assuming the control plane is still running, the simplest thing to do 
is initiate an offer-answer exchange in SDP through SIP or whatever 
your signaling protocol is. That way you can rebuild all the session 
state from scratch and avoid corner cases of stale state (e.g. codec 
payload type maps, keys, addresses, ports, etc.)

In other words - it may be simpler, faster and work better to start a 
new RTP session through offer-answer rather than trying to recover the 
old one.

Dave.

On Nov 21, 2004, at 4:26 PM, Mark Baugher wrote:

> Yuval
>   You mention the channel crashing and there seems to be two major 
> cases, either the destination or source addresses change or they 
> don't.  If they do change, then we effectively have a new session.  
> Often they won't change in an HA system, so I can't immediately 
> recognize any affects on the state of the end-systems.  s_l should be 
> easily recovered and ROC correctly updated unless there are more than 
> 2^15 packets lost.
>
>   In the case where a sender or a receiver fail, then I think it will 
> be hard to seamlessly handle a transition to another sender and 
> receiver unless the addresses remain the same and most of the 
> cryptographic context is recovered.  Commercial HA systems can do 
> this, at least in a hot-standby mode, can't they?
>
> Mark
> On Nov 21, 2004, at 12:18 AM, Yuval Nissan wrote:
>
>> Hello,
>>
>> I have question regarding SRTP and High Availability. This issue 
>> isn’t covered by RFC 3711:
>>
>> The question is if channel crashes, what are the parameters that need 
>> to be recovered by the new channel so that the conversation will 
>> continue (in both directions)?
>>
>> Also in this case it is assumed that we can’t know exactly the 
>> dynamic parameters of the channel. For example the current s_l which 
>> is updated every frame. This means that part of the parameters need 
>> to be estimated.
>>
>>  
>>
>> Thanks,
>>
>>  
>>
>> Yuval
>>
>>  AudioCodes
>>
>>   
>>
>>  
>>
>>  
>>
>> **********************************************************************
>> **************************************
>> This email and any files transmitted with it are confidential 
>> material.
>> They are intended solely for the use of the designated individual or 
>> entity to whom they are addressed.
>> If the reader of this message is not the intended recipient,
>> you are hereby notified that any dissemination,use,
>> distribution or copying of this communication is strictly prohibited 
>> and may be unlawful.
>>
>> If you have received this email in error please notify 
>> [email-masked] and permanently delete the e-mail and 
>> files.
>>
>>
>> **********************************************************************
>> *************************************
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

************************************************************************************************************
This email and any files transmitted with it are confidential material.
They are intended solely for the use of the designated individual or entity to whom they are addressed.
If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination,use,
distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please notify [email-masked] and permanently delete the e-mail and files.

***********************************************************************************************************

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: David R Oran <[email-masked]>
Date: Mon, 22 Nov 2004 13:51:04 -0500

Any solution that doesn't shadow all state will require at least one  
round trip per session. Offer-answer rebuilds the RTP state in one  
round trip. Note that to do true hot failover without a round trip, you  
would have to shadow all RTP state, including ports, addresses, ROC,  
and possibly sequence numbers as well. One way to do this is to send a  
copy of each packet to both machines. There are a number of ways to do  
this, all expensive. OTOH, that's what 1:1 redundancy is inherently:  
expensive.

Dave.

On Nov 22, 2004, at 11:32 AM, Yuval Nissan wrote:

>
> David,
> Assuming you need to do this process on many channels at once (when  
> for example one board crashes with hundreds of channels), I don't  
> think this solution is feasible. What do you think?
>
> Thanks
> Yuval
>
> [email-masked] and permanently delete the e-mail and files.
>
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Alan Clark" <[email-masked]>
Date: Tue, 23 Nov 2004 10:41:43 -0500

>From the flurry of discussion on RFC3711 it looks as if there is
considerable interest in SRTP implementation.  I'd like to add a request to
SRTP implementors with regard to manageability.

RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report block)
contain useful information for network monitoring, and are often used by
probes and analyzers to support problem diagnosis.  RFC3711 allows the
selective encryption of RTCP payloads and hence I would strongly recomment
that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR payloads as this
adversely impacts manageability.

Regards

Alan Clark
Telchemy