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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of WipeOut > Sent: Thursday, October 16, 2003 8:24 AM > To: [EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
