I set up hints and presence monitoring on some Polycom phones connected to an asterisk server with the expectation that the phones that are "watching" other extensions would be notified when the other extension sis ringing, in addition to the other statuses (on the phone, statuses set by the user on the phone, not registered, etc). I can see when the line is in use, and when it is not available, but when it is ringing the status on the "watching" phone shows the same status as when the extension sis in use, in other words, you can not tell that it is ringing. My goal was to have someone's assistant see that the boss's line was ringing and be able to pick it up. I assumed I would have to use the callgroup/pickupgroup to do so, although was optimistic that that the call pickup could be programmed into the line watching button during the "ringing" state. Show hints does in fact show the different statuses (idle, ringing, inuse). Is what I am trying to accomplish possible today with Polycom/Asterisk? If not what is the closest you can get? I have set this up in a test environment with asterisk 1.2.8 and Polycom SIP 1.6.6 If there is someone out there that has achieved the result I am looking for I will gladly pay for some training <- PM me (hope I don't upset the moderators:-)) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060601/be16fa13/attachment.htm
I set up hints and presence monitoring on some Polycom phones connected to an asterisk server with the expectation that the phones that are "watching" other extensions would be notified when the other extension sis ringing, in addition to the other statuses (on the phone, statuses set by the user on the phone, not registered, etc). I can see when the line is in use, and when it is not available, but when it is ringing the status on the "watching" phone shows the same status as when the extension sis in use, in other words, you can not tell that it is ringing. My goal was to have someone's assistant see that the boss's line was ringing and be able to pick it up. I assumed I would have to use the callgroup/pickupgroup to do so, although was optimistic that that the call pickup could be programmed into the line watching button during the "ringing" state. Show hints does in fact show the different statuses (idle, ringing, inuse). Is what I am trying to accomplish possible today with Polycom/Asterisk? If not what is the closest you can get? I have set this up in a test environment with asterisk 1.2.8 and Polycom SIP 1.6.6 If there is someone out there that has achieved the result I am looking for I will gladly pay for some training <- PM me (hope I don't upset the moderators:-)) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060601/b7d6c304/attachment.htm
I believe, that to be able to pick up a ringing line, you need to use shared appearances, and 'seize' the line. The polycom phones support it, but Asterisk does not yet. -----Original Message----- From: Damon Estep [mailto:damon@suburbanbroadband.net] Sent: Thursday, June 01, 2006 8:21 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: asterisk-biz@lists.digium.com Subject: [Asterisk-Users] Polycom-Asterisk hints/presence I set up hints and presence monitoring on some Polycom phones connected to an asterisk server with the expectation that the phones that are "watching" other extensions would be notified when the other extension sis ringing, in addition to the other statuses (on the phone, statuses set by the user on the phone, not registered, etc). I can see when the line is in use, and when it is not available, but when it is ringing the status on the "watching" phone shows the same status as when the extension sis in use, in other words, you can not tell that it is ringing. My goal was to have someone's assistant see that the boss's line was ringing and be able to pick it up. I assumed I would have to use the callgroup/pickupgroup to do so, although was optimistic that that the call pickup could be programmed into the line watching button during the "ringing" state. Show hints does in fact show the different statuses (idle, ringing, inuse). Is what I am trying to accomplish possible today with Polycom/Asterisk? If not what is the closest you can get? I have set this up in a test environment with asterisk 1.2.8 and Polycom SIP 1.6.6 If there is someone out there that has achieved the result I am looking for I will gladly pay for some training <- PM me (hope I don't upset the moderators:-)) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060601/70729d9e/attachment.htm
Damon Estep wrote:> > My goal was to have someone?s assistant see that the boss?s line was > ringing and be able to pick it up. I assumed I would have to use the > callgroup/pickupgroup to do so, although was optimistic that that the > call pickup could be programmed into the line watching button during > the ?ringing? state. >We do it a completely different way. Here's how...First I define a "dummy" extension, ie. one that is not part of our DID block and connect this to the Polycom phone in the third position (Polycom 501 with three line buttons): In sip.conf: [8220] type=friend context=from-sip host=dynamic dtmfmode=rfc2833 callerid="Some Boss" <1112223333> mailbox=3333@default nat=no qualify=yes Then in extensions.conf: exten => 3333,1,macro(stdexten|${EXTEN}|sip/${EXTEN}&sip/8220) And finally in the phone's config file (phonexxx.cfg): <reg reg.1.displayName="Some Assistant" reg.1.address="3334" reg.1.label="" reg.1.type="private" reg.1.thirdPartyName="" reg.1.auth.userId="" reg.1.auth.password="" reg.1.server.1.address="" reg.1.server.1.port="" reg.1.server.1.transport="DNSnaptr" reg.1.server.2.transport="DNSnaptr" reg.1.server.1.expires="" reg.1.server.1.register="" reg.1.server.1.retryTimeOut="" reg.1.server.1.retryMaxCount="" reg.1.server.1.expires.lineSeize="" reg.1.acd-login-logout="0" reg.1.acd-agent-available="0" reg.1.ringType="2" reg.1.lineKeys="" reg.1.callsPerLineKey="" reg.2.displayName="Some Assistant" reg.2.address="3334" reg.2.label="3334" reg.2.type="private" reg.2.thirdPartyName="" reg.2.auth.userId="" reg.2.auth.password="" reg.2.server.1.address="" reg.2.server.1.port="" reg.2.server.1.transport="DNSnaptr" reg.2.server.2.transport="DNSnaptr" reg.2.server.1.expires="" reg.2.server.1.register="" reg.2.server.1.retryTimeOut="" reg.2.server.1.retryMaxCount="" reg.2.server.1.expires.lineSeize="" reg.2.acd-login-logout="0" reg.2.acd-agent-available="0" reg.2.ringType="2" reg.2.lineKeys="" reg.2.callsPerLineKey="" reg.3.displayName="Some Boss" reg.3.address="8220" reg.3.label="3333" reg.3.type="private" ... The third position looks like the boss's extension (3333) due to the label but is really the dummy extension (8220). The first two buttons are the assistant's extension (3334). We reserve a block of extensions in the dialplan for this sort of trickery. HTH, Bob -- Bob Amen O'Reilly Media, Inc. http://www.ora.com/ http://www.oreilly.com/
Thanks Bob, We have also done some similar stuff to make it usable, the prospect that we might be able to achieve the same functionality and add to it as a bonus the ability to monitor the boss's extension state (idle, on the phone, away) with the same button was appealing, but a dead end it appears. Is there enough interest here to get together with other Polycom/asterisk users and pony up a bounty for shared line appearance? I think the Polycom implementation is based on some SIP rfc, so it is not just a Polycom feature. The functionality is going to be a must at some point, you have to be able to emulate what most of the midrange PBXs can do to propose replacing them with asterisk, and this particular feature issue has come up more than once in our line of business. Anyone have any ideas what kind of project this might be? Damon -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Bob Amen Sent: Thursday, June 01, 2006 5:10 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Polycom-Asterisk hints/presence Damon Estep wrote:> > My goal was to have someone's assistant see that the boss's line was > ringing and be able to pick it up. I assumed I would have to use the > callgroup/pickupgroup to do so, although was optimistic that that the > call pickup could be programmed into the line watching button during > the "ringing" state. >We do it a completely different way. Here's how...First I define a "dummy" extension, ie. one that is not part of our DID block and connect this to the Polycom phone in the third position (Polycom 501 with three line buttons): In sip.conf: [8220] type=friend context=from-sip host=dynamic dtmfmode=rfc2833 callerid="Some Boss" <1112223333> mailbox=3333@default nat=no qualify=yes Then in extensions.conf: exten => 3333,1,macro(stdexten|${EXTEN}|sip/${EXTEN}&sip/8220) And finally in the phone's config file (phonexxx.cfg): <reg reg.1.displayName="Some Assistant" reg.1.address="3334" reg.1.label="" reg.1.type="private" reg.1.thirdPartyName="" reg.1.auth.userId="" reg.1.auth.password="" reg.1.server.1.address="" reg.1.server.1.port="" reg.1.server.1.transport="DNSnaptr" reg.1.server.2.transport="DNSnaptr" reg.1.server.1.expires="" reg.1.server.1.register="" reg.1.server.1.retryTimeOut="" reg.1.server.1.retryMaxCount="" reg.1.server.1.expires.lineSeize="" reg.1.acd-login-logout="0" reg.1.acd-agent-available="0" reg.1.ringType="2" reg.1.lineKeys="" reg.1.callsPerLineKey="" reg.2.displayName="Some Assistant" reg.2.address="3334" reg.2.label="3334" reg.2.type="private" reg.2.thirdPartyName="" reg.2.auth.userId="" reg.2.auth.password="" reg.2.server.1.address="" reg.2.server.1.port="" reg.2.server.1.transport="DNSnaptr" reg.2.server.2.transport="DNSnaptr" reg.2.server.1.expires="" reg.2.server.1.register="" reg.2.server.1.retryTimeOut="" reg.2.server.1.retryMaxCount="" reg.2.server.1.expires.lineSeize="" reg.2.acd-login-logout="0" reg.2.acd-agent-available="0" reg.2.ringType="2" reg.2.lineKeys="" reg.2.callsPerLineKey="" reg.3.displayName="Some Boss" reg.3.address="8220" reg.3.label="3333" reg.3.type="private" ... The third position looks like the boss's extension (3333) due to the label but is really the dummy extension (8220). The first two buttons are the assistant's extension (3334). We reserve a block of extensions in the dialplan for this sort of trickery. HTH, Bob -- Bob Amen O'Reilly Media, Inc. http://www.ora.com/ http://www.oreilly.com/ _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
> On 6/1/06, Damon Estep <damon@suburbanbroadband.net> wrote: > > Thanks Bob, > > > > We have also done some similar stuff to make it usable, the prospect > > that we might be able to achieve the same functionality and add toit as> > a bonus the ability to monitor the boss's extension state (idle, onthe> > phone, away) with the same button was appealing, but a dead end it > > appears. > > > > Is there enough interest here to get together with other > > Polycom/asterisk users and pony up a bounty for shared lineappearance?> > > > I think the Polycom implementation is based on some SIP rfc, so itis> > not just a Polycom feature. > > > > The functionality is going to be a must at some point, you have tobe> > able to emulate what most of the midrange PBXs can do to propose > > replacing them with asterisk, and this particular feature issue hascome> > up more than once in our line of business. > > > > Anyone have any ideas what kind of project this might be? > > > > I would think the biggest issue with this at this point is because > Asterisk is not a SIP only platform, if one were to implement shared > line appearance, it would need to be designed in such a way that > channels other than SIP channels could participate in the "sharing" of > lines. > > It has been talked about a great deal, and at some point, it will > probably be done, but just being compliant with the SIP supported > methods of shared line appearance is not all that has to be done in > order to get this feature in. > > -- > Bird's The Word Technologies, Inc. > http://www.btwtech.com/ > _______________________________________________I'll contend that I could be way off base, but I am not sure I agree, the SIP version of shared line appearance would be implemented in the sip channel, the IAX in the IAX channel, etc. I am not aware of any IAX devices that support shared line appearance, and since IAX is an asterisk protocol there would not be any until digium(asterisk) defines one. Are you suggesting that this be put on hold until every protocol that Asterisk supports has a standard for shared line appearance? Even if this is the case, the SIP version of the feature should still be rfc compliant, so it would stand to reason that the feature would be implemented in the sip channel. Jump in if it appears that I have no clue.
> > You're right in that there is nothing in technology spec to support > the concept of shared line appearance, but I think what was more to my > point was that you could get access to a "shared line" from more > channels than just a SIP channel. I'd probably want the ability to > have two SIP channels and an IAX channel in a "shared line group", and > while SIP provides for structured communication to ask for a > grant/deny access to this resource, there isn't any reason the same > couldn't be done off the IAX channel via feaure mapped DTMF just as > you can "park" a call off of a Zap channel today even though the > underlying technology has no idea what the concept of Park really is. > The concept of channels in Asterisk are not technology specific, and > as a result, implementations of things like "shared lines" really > shouldn't be either. > > -- > Bird's The Word Technologies, Inc. > http://www.btwtech.com/What you are describing is an ability to dynamically "bundle" channels in the dialplan, that is you would define the members of the group, and then ring the group instead of the channel, this can already be done manually. That is not what the sip version of shared lines does, it allows simultaneous registrations of multiple user agents into a user agent account, and then allows any one of the registered UAs to seize the call when it rings. When the SIP server evaluates where the INVITE should go it sends it to multiple UAs, and that is the thing asterisk can not do without a dialplan that tells it to do so and a unique account for each UA to register on. It is limited to one registration per user account. I understand your "technology agnostic position", and it makes sense, however my vote (for the little that it is worth) would be to implement a SIP rfc complaint shared line appearance capability (and/or bridged line appearance), and then, if possible, extend it to support zaptel and iax and whatever else is popular. SIP is arguably the most common choice for NEW VoIP implementation, and it also appears to be the common ground upon which all vendors of VoIP gear will meet for interoperability. IAX, even with its advantages, will not likely progress to the same stage of universal acceptance, it may very well be the choice of many asterisk users, but in the end you will still have to talk SIP interoperate with the "VoIP Revolution" I can not imagine Nortel, Cisco, Lucent, Sonus, BroadSoft, and (probably) Polycom, or any of the other commercial players, embracing a protocol developed and supported by proponents of open source software :) If your comments echo those of past conversations on the matter I can see that a bounty at this point would not be money well spent, since any work the comes from it is not likely to make the cut. A bounty would only be useful to accelerate the implementation of a feature where there is widespread agreement on what the architecture should be. Damon
> > > > From Kevin Flemming at Digium: > > It will most definitely not be in 1.4, but I > would expect it to appear some time early in the next developmentcycle> and be part of Asterisk 1.6. > >Sean, Where did you find that quote, I would like to see the rest of the thread if there was relevant discussions. Thanks.
Changing the subject back to the original topic; Is there bug in the asterisk hint/presence implementation, or an intentional omission, or a lack of understanding on my part? A SIP debug of a subscribed extension shows that asterisk only sends the SIP presence notification to the subscriber when a call starts ringing, and then when it is hung up. A "show hints" reveals that asterisk changes the hint state twice, once from idle to ringing, and again from ringing to inuse, but it does not notify the subscriber on the change from ringing to inuse. Here are the relevant packets for a hint extension subscriber during the time where the state changed both times, note that the first change goes right to "on the phone", but the notify was sent when the ringing started, not when the call was answered. Ringing started here>>> Reliably Transmitting (no NAT) to 207.138.248.85:5060: NOTIFY sip:3035551200@207.138.248.85 SIP/2.0 Via: SIP/2.0/UDP 255.255.255.79:5060;branch=z9hG4bK491df6fc;rport From: <sip:3035551201@255.255.255.79>;tag=as34e8536c To: "SBB Test" <sip:3035551200@255.255.255.79>;tag=7AB691E6-26D89B2D Contact: <sip:3035551201@255.255.255.79> Call-ID: bf85d2d2-26d31aec-a6dc96e3@207.138.248.85 CSeq: 135 NOTIFY User-Agent: Asterisk PBX Max-Forwards: 70 Event: presence Content-Type: application/xpidf+xml Subscription-State: active Content-Length: 371 <?xml version="1.0"?> <!DOCTYPE presence PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd"> <presence> <presentity uri="sip:3035551200@255.255.255.79;method=SUBSCRIBE" /> <atom id="3035551201"> <address uri="sip:3035551201@255.255.255.79;user=ip" priority="0.800000"> <status status="inuse" /> <msnsubstatus substatus="onthephone" /> </address> </atom> </presence> Call hung up here >>>>>>>> Reliably Transmitting (no NAT) to 207.138.248.85:5060: NOTIFY sip:3035551200@207.138.248.85 SIP/2.0 Via: SIP/2.0/UDP 255.255.255.79:5060;branch=z9hG4bK6793e1a6;rport From: <sip:3035551201@255.255.255.79>;tag=as34e8536c To: "SBB Test" <sip:3035551200@255.255.255.79>;tag=7AB691E6-26D89B2D Contact: <sip:3035551201@255.255.255.79> Call-ID: bf85d2d2-26d31aec-a6dc96e3@207.138.248.85 CSeq: 136 NOTIFY User-Agent: Asterisk PBX Max-Forwards: 70 Event: presence Content-Type: application/xpidf+xml Subscription-State: active Content-Length: 366 <?xml version="1.0"?> <!DOCTYPE presence PUBLIC "-//IETF//DTD RFCxxxx XPIDF 1.0//EN" "xpidf.dtd"> <presence> <presentity uri="sip:3035551200@255.255.255.79;method=SUBSCRIBE" /> <atom id="3035551201"> <address uri="sip:3035551201@255.255.255.79;user=ip" priority="0.800000"> <status status="open" /> <msnsubstatus substatus="online" /> </address> </atom> </presence>
> > I think there was a patch that went in recently from Mark with regard > to SIP devices and their state when they are ringing/in use and when > they are just "in use". That may help you with what you're asking > about. >I tested on 1.2.8, was it after the release of 1.2.8?
> > > > If your comments echo those of past conversations on the matter Ican> > see that a bounty at this point would not be money well spent, sinceany> > work the comes from it is not likely to make the cut. A bounty would > > only be useful to accelerate the implementation of a feature wherethere> > is widespread agreement on what the architecture should be. > > > > A bounty for what? A bounty for implement a SIP only functionality? I > would agree that this is likely money not well spent. If you're > proposing a bounty for it to be a core-driven functionality, I do > think that would be money well spent. >Money well spent, but too much of it, I doubt anyone would contribute enough to get to that point, that is a major overhaul and a huge can of bugs.
> > > > I think there was a patch that went in recently from Mark with regard > to SIP devices and their state when they are ringing/in use and when > they are just "in use". That may help you with what you're asking > about. >Let's assume for a minute that there is a way to get a ringing notify, and that the Polycom processes the messages and properly displays the status, then; 1. A hint could be setup that monitors the sip user. 2. the hint could have a unique extension 3. the dialplan for the extension could be a call pickup sequence. Example (without regard for correct syntax) Exten 123,hint,SIP/345 Exten,123,1,(Need help here -> if sip/345 is idle then goto priority 3) Exten 123,2,Pickup(SIP/345@context) Exten 123,3,Dial(SIP/345) Now, on the Polycom 1. setup a buddy with the correct display name for exten 345, but with, but with a contact address of 123 2. turn on presence monitoring (buddy watch in Polycom terms) Do you see the value in knowing that an extensions is ringing via presence? Take it one step further, ask Polycom to implement a feature where the presence status of ringing can produce an audible event instead of only visual events. That is, if it does not already, which I have no idea on.
@suburbanbroadband.net> wrote:> > > > > > I think there was a patch that went in recently from Mark withregard> > > to SIP devices and their state when they are ringing/in use andwhen> > > they are just "in use". That may help you with what you're asking > > > about. > > > > > > > I tested on 1.2.8, was it after the release of 1.2.8? > > _______________________________________________ > > The patch was r29619 of /trunk. > > --Please forgive my ignorance, would that be in the issue tracker? I do not recognize the patch numbering scheme. Thanks! Damon
Hi, I was wondering if anyone knows of a opensource SIP voice logger. I need to simultaneously record around 150 to 200 sessions. I figured that if I just set a mirroring port on the switch and just send all RTP packets to it, I would be able to do it. The problem is: has anyone done it before? Is there a better way to do it? Thanks in advance! Vic
Hi, maybe http://www.oreka.org --- Vic <svictor@yahoo.co.jp> wrote:> Hi, I was wondering if anyone knows of a opensource > SIP > voice logger. > > I need to simultaneously record around 150 to 200 > sessions. > > I figured that if I just set a mirroring port on the > switch and just send all RTP packets to it, I would > be > able to do it. The problem is: has anyone done it > before? > Is there a better way to do it? > > Thanks in advance! > Vic > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com > -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > >http://lists.digium.com/mailman/listinfo/asterisk-users>__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
hi, maybe http://www.oreka.org --- Vic <svictor@yahoo.co.jp> wrote:> Hi, I was wondering if anyone knows of a opensource > SIP > voice logger. > > I need to simultaneously record around 150 to 200 > sessions. > > I figured that if I just set a mirroring port on the > switch and just send all RTP packets to it, I would > be > able to do it. The problem is: has anyone done it > before? > Is there a better way to do it? > > Thanks in advance! > Vic > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com > -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > >http://lists.digium.com/mailman/listinfo/asterisk-users>__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Oh sweet. -----Original Message----- From: Rob McKrill [mailto:rmckrill@gmail.com] Sent: Friday, June 02, 2006 11:25 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Polycom-Asterisk hints/presence According to the release notes for Polycom's SIP 1.6.6 firmware the "Buddy Watch" limitations have been increased from 8 watched buddies to 48 which would give you enough to watch status on three (14 button) side cars. Haven't tested it but read a discussion in the forum about it and plan to test it with a couple of my customers. On 6/2/06, Sean Cook < scook@kinex.net> wrote:> > Sean, > > Where did you find that quote, I would like to see the rest of the > thread if there was relevant discussions. > > Thanks. >It was really a two email thread... I had sent an email asking what the status of BLA/SCA: Here is the entire thread: Sean Cook wrote:> > I take it SCA/BLA isn't going to make it into 1.4. Anyone have any idea > > when support will be added to asterisk for this? >There has been no BLA support written at this point, and it does not appear that when we do it we will even use SIP-B to get there. SIP-B is very complex (overly so) and doesn't seem like a practical solution for implementing basic key system type functionality. However... I can say that an implementation of this functionality is being worked on at this time, and we intend to make it available in Asterisk as soon as we can. It will most definitely not be in 1.4, but I would expect it to appear some time early in the next development cycle and be part of Asterisk 1.6. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: <http://lists.digium.com/mailman/listinfo/asterisk-users> http://lists.digium.com/mailman/listinfo/asterisk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060602/09572825/attachment.htm
> -----Original Message----- > From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users- > bounces@lists.digium.com] On Behalf Of Mike Fedyk > Sent: Friday, June 02, 2006 10:16 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [Asterisk-Users] Polycom-Asterisk hints/presence > > How do you setup asterisk so that the assistant sees the lights but > doesn't hear the rings? >It was not intentional, but with 1.2.8 asterisk and 1.6.5 Polycom sip; 1. add a hint priority to the dialplan. 2. set the subscribe context for the subscriber 3. create a directory entry on the phone and enable buddy watch 4. assign the directory entry to a speed dial key. This can only be done if you have not set all of the Polycom keys to register on the primary account used for the phone. If you have a 501, and you set the first 2 for registration, the third will display "speed dial 1" The buddy watch feature on the Polycom phone is enabled by adding the appropriate xml tag to the config file for the phone - if you need more info let me know. The result I expected was that the "watched" extensions would ring, but a sip debug in asterisk reveals that asterisk does not send a different notify for ring and it does not send a notify when the state changes from ringing to inuse. There is only one notify sent when the watched extensions starts ringing, and it is a status of "inuse" I have not been able to determine if the Polycom would ring if a status notification of ringing was sent from asterisk. Damon