[Asterisk-Users] Music on hold...

[CW_ASN]

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 at techselesta.com>
To: <asterisk-users at 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 at lists.digium.com
> [mailto:asterisk-users-admin at lists.digium.com] On Behalf Of WipeOut
> Sent: Thursday, October 16, 2003 8:24 AM
> To: asterisk-users at 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 at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
>