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]
<mailto:[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]
<mailto:[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]
<mailto:[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
<http://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]
<mailto:[email protected]>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>> What are the Polycom models supports RFC 2543 Hold?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Kumaran T
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> sipx-dev mailing list
>>>>>>>>>>>> [email protected]
<mailto:[email protected]>
>>>>>>>>>>>> List Archive:
http://list.sipfoundry.org/archive/sipx-dev/
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> sipx-dev mailing list
>>>>>>>>>> [email protected]
<mailto:[email protected]>
>>>>>>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> sipx-dev mailing list
>>>>> [email protected]
<mailto:[email protected]>
>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/
>>>>>
>>>>
>>>>
>>>> --
>>>> ======================
>>>> Tony Graziano, Manager
>>>> Telephone: 434.984.8430 <tel:434.984.8430>
>>>> sip: [email protected]
<mailto:[email protected]>
>>>> Fax: 434.326.5325 <tel:434.326.5325>
>>>>
>>>> Email: [email protected]
<mailto:[email protected]>
>>>>
>>>> LAN/Telephony/Security and Control Systems Helpdesk:
>>>> Telephone: 434.984.8426 <tel:434.984.8426>
>>>> sip: [email protected]
<mailto:[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] <mailto:[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 <http://www.ezuce.com>
_______________________________________________
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/
