it's worth asking :-) On Wed, Jun 22, 2011 at 8:17 AM, Joegen Baclor <[email protected]> wrote:
> ** > I dont think thats even possibly tenable even if we pull everyone's hair > off. 0.0.0.0 reaching FS (the MoH) server, without any divine intervention > will not figure out where to send the cool guitar strum music. > > > On 06/22/2011 07:44 PM, Michael Picher wrote: > > Would it be easy to support it in FS instead of in sipXbridge? That way > multiple MoH standards can be used and the caller doesn't need to be coming > through sipXbridge... > > Mike > > On Wed, Jun 22, 2011 at 7:33 AM, Joegen Baclor <[email protected]> wrote: > >> congratulations :-) >> >> On 06/22/2011 07:24 PM, Venkateshwaran T wrote: >> > Hi Joegen, >> > I tried with removing the MOH uri for one user and enabled the RFC >> > 2543 at this time I can see c=IN IP4 0.0.0.0 in SDP >> > >> > Regards, >> > Kumaran T >> > >> > >> > Joegen Baclor wrote: >> >> >> >> I'll have seconds thoughts about this. Probably, the best way we can >> >> do about this is to correct the SDP in the sipx bridge and hope for >> >> the best. But we really cannot be sure if a UA sending 0.0.0.0 >> >> really means it (meaning I have both send and receive closed, don't >> >> even try) or go ahead and try sending, I'm going to accept it because >> >> I lied. I really meant a=recvonly and not a=inactive. >> >> >> >> >> >> On 06/22/2011 06:27 PM, Tony Graziano wrote: >> >>> This makes me think if we have a really funky requirement for support >> >>> moh (lots of old clunky cisco phones, for example)... >> >>> >> >>> phone group>line>registration >> >>> >> >>> where we can have a moh uri that essentially uses or allows 0.0.0.0, >> >>> which would possibly be a way to support phones that are crappy. I'm >> >>> not sure it is worth it, but I feel like FS can probably mimic it >> >>> somehow. >> >>> >> >>> On Wed, Jun 22, 2011 at 6:15 AM, Tony Graziano >> >>> <[email protected]> wrote: >> >>>> the phone has a moh uri, which can be deleted at the line level: >> >>>> >> >>>> Phone>Line>registration> >> >>>> >> >>>> musicOnHold.uri (Default: ~~mh~@sipdomain) >> >>>> >> >>>> On Wed, Jun 22, 2011 at 6:12 AM, >> >>>> Kumaran<[email protected]> wrote: >> >>>>> Hi Joegen, >> >>>>> We can disable in Feature->MOH->None.I'm I right? >> >>>>> >> >>>>> Regards, >> >>>>> Kumaran T >> >>>>> >> >>>>> Kumaran wrote: >> >>>>>> Joegen >> >>>>>> Can you please tell me how to disable the MOH? >> >>>>>> Thanks >> >>>>>> >> >>>>>> Joegen Baclor wrote: >> >>>>>>> What I am saying is you need to disable MoH for you to see >> >>>>>>> this. MoH >> >>>>>>> and 2543 hold cannot co-exist. >> >>>>>>> >> >>>>>>> On 06/22/2011 05:31 PM, Kumaran wrote: >> >>>>>>>> Hi Joegen, >> >>>>>>>> I tried on Polycom 550..I enabled for 2 users 200 and >> >>>>>>>> 123.Thats I >> >>>>>>>> posted which are Polycom models supported... >> >>>>>>>> 200 calls 123 >> >>>>>>>> 123 answer the call >> >>>>>>>> 200 Put on Hold and then Resume the call >> >>>>>>>> >> >>>>>>>> Regards, >> >>>>>>>> Kumaran T >> >>>>>>>> >> >>>>>>>> Joegen Baclor wrote: >> >>>>>>>>> You have configured moh in the polycom. As I've said in another >> >>>>>>>>> mail, 2543 hold is cont compatible with MoH. My bet is Polycom >> >>>>>>>>> ignores this flag if MoH is set. Tony? >> >>>>>>>>> >> >>>>>>>>> On 06/22/2011 05:17 PM, Kumaran wrote: >> >>>>>>>>>> Hi Tony, >> >>>>>>>>>> Please check my SipXproxy.log.By default,it will >> >>>>>>>>>> unchecked in >> >>>>>>>>>> Devices->Phones->Sip.So enabled it to check the SDP part >> whether >> >>>>>>>>>> its reflecting or not.But I never I find c=0.0.0.0 in SDP part >> >>>>>>>>>> after putting on HOLD.Its only showing IP address of the phone. >> >>>>>>>>>> >> >>>>>>>>>> Regards, >> >>>>>>>>>> Kumaran T >> >>>>>>>>>> >> >>>>>>>>>> Tony Graziano wrote: >> >>>>>>>>>>> all. >> >>>>>>>>>>> >> >>>>>>>>>>> SIP>protocol >> >>>>>>>>>>> >> >>>>>>>>>>> useRFC2543hold (Default: unchecked) >> >>>>>>>>>>> >> >>>>>>>>>>> If checked, use the obsolete c=0.0.0.0 RFC2543 technique, >> >>>>>>>>>>> otherwise, >> >>>>>>>>>>> use SDP media direction attributes (such as a=sendonly) per >> >>>>>>>>>>> RFC 3264 >> >>>>>>>>>>> when initiating hold. In either case, the phone processes >> >>>>>>>>>>> incoming >> >>>>>>>>>>> hold signaling in either format. >> >>>>>>>>>>> >> >>>>>>>>>>> However that is simply the interaction of the hold button, >> >>>>>>>>>>> and I >> >>>>>>>>>>> don't >> >>>>>>>>>>> think it substitutes the MOH uri for services within sipx, >> etc. >> >>>>>>>>>>> >> >>>>>>>>>>> On Wed, Jun 22, 2011 at 4:58 AM, Kumaran >> >>>>>>>>>>> <[email protected]> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> Hi All, >> >>>>>>>>>>>> What are the Polycom models supports RFC 2543 Hold? >> >>>>>>>>>>>> >> >>>>>>>>>>>> Regards, >> >>>>>>>>>>>> Kumaran T >> >>>>>>>>>>>> >> >>>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>>> sipx-dev mailing list >> >>>>>>>>>>>> [email protected] >> >>>>>>>>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> sipx-dev mailing list >> >>>>>>>>>> [email protected] >> >>>>>>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> >>>>>>>> >> >>>>>> >> >>>>> _______________________________________________ >> >>>>> sipx-dev mailing list >> >>>>> [email protected] >> >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> >>>>> >> >>>> >> >>>> >> >>>> -- >> >>>> ====================== >> >>>> Tony Graziano, Manager >> >>>> Telephone: 434.984.8430 >> >>>> sip: [email protected] >> >>>> Fax: 434.326.5325 >> >>>> >> >>>> Email: [email protected] >> >>>> >> >>>> LAN/Telephony/Security and Control Systems Helpdesk: >> >>>> Telephone: 434.984.8426 >> >>>> sip: [email protected] >> >>>> >> >>>> Helpdesk Contract Customers: >> >>>> http://support.myitdepartment.net >> >>>> Blog: >> >>>> http://blog.myitdepartment.net >> >>>> >> >>>> Linked-In Profile: >> >>>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >> >>>> >> >>> >> >>> >> > >> > >> >> _______________________________________________ >> sipx-dev mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> > > > > -- > Michael Picher > eZuce > Director of Technical Services > O.978-296-1005 X2015 > M.207-956-0262 > @mpicher <http://twitter.com/mpicher> > www.ezuce.com > > > _______________________________________________ > sipx-dev mailing [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > > -- Michael Picher eZuce Director of Technical Services O.978-296-1005 X2015 M.207-956-0262 @mpicher <http://twitter.com/mpicher> www.ezuce.com
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
