[Asterisk-Dev] chan_zap.c (DEBUG - CONSOLE STUFF)

[Jennifer Archer]

Every time I get a call... it reads

   Starting simple switch on 'Zap/1'
chan_zap.c:4743 ss_thread: Got event 2 (Ring/Answered)...
chan_zap.c:4743 ss_thread: Got event 2 (Ring/Answered)...
   Executing Answer("Zap/1-1", "") in new stack

WHY DOES IT PUT chan_zap.c:4743 (ring answered) crap twice!!!

Sincerely,


Steve McMahon
Digital DataBits Innovations
Salem, OR  97301
Office:   (503)371-6448 Ext. 2
Cellular: (503)881-6828
----- Original Message ----- 
From: "Dr. Rich Murphey" <Rich at WhiteOakLabs.com>
To: <asterisk-dev at lists.digium.com>
Sent: Saturday, May 15, 2004 11:32 AM
Subject: RE: [Asterisk-Dev] libsrtp


> Would Sipura interoperability be an appropriate practical goal for
> implementing these as Olle suggested?
>
> Are there any compatible soft phones or service providers to test against
> (for those without a Sipura)?
>
> Cheers,
> Rich
>
>
> > -----Original Message-----
> > From: asterisk-dev-admin at lists.digium.com [mailto:asterisk-dev-
> > admin at lists.digium.com] On Behalf Of Conroy, Lawrence (SMTP)
> > Sent: Saturday, May 15, 2004 1:04 PM
> > To: asterisk-dev at lists.digium.com
> > Subject: Re: [Asterisk-Dev] libsrtp
> >
> > Hi Folks,
> >    libsrtp for * is a GOOD idea, IMHO. Go for it!
> >
> > However, I'm a little puzzled with these comments.
> >
> > Yes, I am subscribed to MMUSIC, AVP & SIP/SIPPING Mailing Lists; I
> > don't get enough junk email.
> >
> > No, 802.1X is not an IETF protocol - it's an IEEE link layer protocol.
> >
> > Yes, SIP does use S/MIME - it's specified in RFC 3261 (for example, see
> > section 23 on page 201 et seq).
> > BTW, the S/MIME RFCs are listed in the references section at the end of
> > 3261.
> >
> > No, TCP doesn't really add latency, as this is used only for the SIP
> > exchanges (i.e. the signalling),
> >      NOT the (s)RTP used to carry the media. In practice, you often get
> > retransmits in SIP using UDP
> >      transport unless you're "close", so the extra syn/ack traffic to
> > set up TCP is insignificant.
> >      Remember also that the TCP connections can be re-used, so for
> > inter-PBX trunking it makes no odds.
> >
> > The SIP INVITE/200 exchange carries the SDP anyway, so a secured
> > exchange (via SIPS - i.e. TLS)
> > should be OK to carry the keys, hence SDPdescriptions. You have the
> > problem of mutual authentication
> > and encryption with TLS anyway; once that's dealt with, passing a
> > message key (or keys) is OK,
> > as it's done over a secured signalling channel.
> >
> > Note that the chat on the AVT list said that time-based re-keying (i.e.
> > multiple keys switched
> > automatically based on the timestamp blah in the RTP stream) is NOT
> > supported by srtp. Frankly,
> > I'd be surprised if anyone needed that any time soon - if encrypted
> > content is that sensitive,
> > then we're probably talking about IPsec anyway.
> >
> > One last point... srtp encrypts the content only.
> > The fact that there's a stream between the parties is still obvious to
> > an eavesdropper, even
> > if the signalling that set up the session is secure (and the content is
> > secure).
> > However, I think that the focus on content only means that the good
> > news is that standard
> > NAT mangling should still work with srtp, as the IP/UDP headers are
> > intact.
> >
> > all the best,
> >    Lawrence
> >
> >
> >
> > On 15 May 2004, at 4:26 pm, Duane wrote:
> > > Olle E. Johansson wrote:
> > >> Yes, but how did you relate EAP-TLS with SIPS?
> > >
> > > There is a reason people use UDP for telephony, by introducing TCP
> > > into the mix won't that introduce high amounts of latency?
> > >
> > > EAP-TLS is handled at the mac layer not at the TCP layer, IPSec also
> > > uses TLS but does so over UDP because of latency associated with using
> > > TCP...
> > >
> > > http://e164.org - Using Enum.164 to interconnect asterisk servers
> > >  As Fosters is to beer, so ...
> >
> > --
> >
> > Visit our website at www.roke.co.uk
> >
> > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury,
> > Bracknell,
> > Berkshire. RG12 8FZ
> >
> > The information contained in this e-mail and any attachments is
> > confidential to
> > Roke Manor Research Ltd and must not be passed to any third party
without
> > permission. This communication is for information only and shall not
> > create or
> > change any contractual relationship.
> >
> > _______________________________________________
> > Asterisk-Dev mailing list
> > Asterisk-Dev at lists.digium.com
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
>
>
>
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>