No, you don't need a sound card.
Do you have ztdummy loaded or zaptel device in your system?
Regards,
Gus
----- Original Message -----
From: "Chris Hariga" <contact@techselesta.com>
To: <asterisk-users@lists.digium.com>
Sent: Sunday, October 19, 2003 8:19 PM
Subject: [Asterisk-Users] Music on hold...
> Hi,
>
> I need a sound card and mpg123 for music on hold??? When I call Digium
> the guys toll me "is not necessary to have a sound card". My
music on
> hold doesn't work :((
>
> Best regards,
>
> Chris HARIGA
>
>
>
> -----Original Message-----
> From: asterisk-users-admin@lists.digium.com
> [mailto:asterisk-users-admin@lists.digium.com] On Behalf Of WipeOut
> Sent: Thursday, October 16, 2003 8:24 AM
> To: asterisk-users@lists.digium.com
> Subject: Re: [Asterisk-Users] SER vs STUND with Asterisk..
>
> Olle E. Johansson wrote:
>
> > WipeOut wrote:
> >
> >> Olle E. Johansson wrote:
> >>
> >>> WipeOut wrote:
> >>>
> >>>> Anyway, I decided to go and have a quick read through the
SER docs
> >>>> and in the section about NAT they say that the best way to
address
> >>>> NAT is to use STUN or uPNP..
> >>>
> >>>
> >>> STUN is helpful, but as I understand it analyzes the situation
and
> >>> reports
> >>> the configuration of a NAT. It doesn't help you keeping
the NAT
> >>> session open,
> >>> as SER module nathelper or the FWD/Jasomi solution.
> >>> Check here http://www.voip-info.org/wiki-SER+module+nathelper
> >>> It's ugly, but what it does is sending UDP packets from
the outside
> >>> to the
> >>> NAT to keep the ports open for incoming calls. NAT is an ugly
thing,
> >>> so it propably needs ugly solutions... ;-)
> >>
> >>
> >> Looking at that page you mentioned it still seems to me that the
> >> "nathelper" module for SER and adding nat=yes to the
sip.conf
> >> essentially do the same thing apart from the "NAT pings"
you
> >> mentioned below..
> >
> > Right. There's also more commands so that you can tweak SER into
doing
> > different kinds of SIP message mangling than the - still rather
> > undocumented -
> > nat=yes. My guess is that nat=yes changes the Contact to the actual IP
>
> > used
> > to contact Asterisk, not the IP given in the SIP headers. Right?
>
> Not sure about the intimate details of what nat=yes does exactly but it
> defiantely works, also have just found out (thanks to John Todd) the if
> you add "qualify=500" to your UA configuration in the sip.conf
then it
> essentially uses keep alives in the form of a OPTIONS request every 60
> seconds.. So by having nat= and qualify= removes the need to have SER
> and the nathelper module.. (No doubt there is more that SER can do and
> if you really need those features then go for it..)
>
> >
> >>> As I understand it, it works like this:
> >>> * Client on the inside of a NAT registers to an outside SIP
Proxy
> >>> * THe outside SIP Proxy keeps sending UDP packets ("NAT
PINGS") to
> the
> >>> client to keep the UDP session open in the NAT
> >>> * When someone calls, the session is open and the client
(UAC/S) may
> >>> answer...
> >>> * In addition to the solution for handling SIP this way,
there's a
> >>> need for an RTP media server to handle the RTP stream.
> >>
> >> I guess that if you use SER or STUN and Asterisk the RTP is still
> >> going to be an issue if the call is needing to go between two SIP
> >> UA's that are both behind NAT (UA---NAT--Internet--NAT--UA) so
the
> >> RTP streams are going to have to go via the central server (aka
> >> canreinvite=no in Asterisk).. So if NAT is in the picture you have
no
>
> >> choice but to load the server with all the traffic..
> >
> > Right. That's where the PortaOne RTP proxy - or Asterisk - come
in.
> > The RTP proxy in combination with SERs nathelper changes the SDP to
> > point to the RTP proxy in this case and informs the RTP proxy of the
> > session through a Unix pipe.
>
> Personally I think I would stick with Asterisk to handle all the RTP
> traffic, just by adding canreinvite=no to the sip.conf will cause all
> traffice between the endpoints to go via Asterisk.. The fewer systems
> that need to be tied together the better IMO.. If it can all be done
> with one then there is less to go wrong.. :)
>
> >
> >>>> So my question is would it not be better to couple STUND
> >>>> (Vovida.org) with Asterisk and then use nat=yes in the
sip.conf for
>
> >>>> UA's that do not support STUN, instead of using SER
which would be
> >>>> like learning Asterisk all over again and would require
you to
> >>>> learn how to use the SER config language to manage your
NAT
> >>>> transtaltions..
> >>>
> >>> Integrating a STUN server into ASterisk... I don't see the
point.
> >>> But if
> >>> you're talking about asterisk as a SIP client
(registrering to other
>
> >>> SIP
> >>> servers) supporting STUN to find out if it's behind a NAT
and how
> the
> >>> NAT works, yes, that's a good idea.
> >>
> >> I wasn't talking about intergrating STUN into asterisk, I was
> >> thinking more along the lines of using STUND in conjunction with
> >> Asterisk instead of SER and Asterisk.. :)
> >
> > Sorry, my misunderstanding. Are you thinking the way I did, with
> Asterisk
> > as a SIP client or are you thinking of supporting Asterisk's SIP
> clients,
> > the phones, with a STUND?
>
> I was thinking of the supporting the SIP clients (phones).. I think that
>
> it is the resposibility of the server to handle as much complexity as
> possible making it easier for the UA's to be configured.. So if you are
> trying to connect Asterisk(as a client) to a third party to route your
> calls I would say that it is their responsibility to handle NAT issues..
>
> Thats not to say that Asterisk can be made to help out as well..
>
> > We need to form a strategy of what can be done with Asterisk's SIP
> > channel
> > to better support NAT. One part is how Asterisk acts as a SIP client
> > (registering to FWD) and another part of the strategy must handle
> > Asterisk
> > being the SIP proxy.
>
> I think Asterisk as the proxy works quite well when used with NATed
> UA's.. with options like nat= canreinvite= reinvite= and qualify= you
> should be able to get most NATed phones to work.. As for Asterisk as a
> Client I havent really had a lot of experience with that so I am not
> really sure what is needed..
>
> > I think a lot of things can be added to channel_sip.c without doing
> the
> > channel_sip.c-ng++ rearchitecture. This said standing on thin ice
> since
> > I haven't got full insight into how channel_sip works, source-code
> wise.
>
> I can't really help there either.. I know squat about C coding.. and
the
>
> times I have looked at the source it really didn't really make a lot of
> sense..
>
> Later..
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
>