IP 650 Attendant Console Ringing

[Anonymous]

I have the IP650 set up with the side car.

The first line is an attendant feature for extension 2001

If someone calls 2001, I hear the attendant ring tone and I can either pick it up or the user at 2001 picks it up.

If 2001 is on the phone, the line key is a solid red and the symbol is the circle with the line through it.

If a second person calls 2001, the line key flashes green with the music notes indicating an incoming call.

The issue is at this point - there is no attendant ring tone. Only the visual aspect occurs.

How can I change it so that the second call allows the IP650 to hear the attendant ring tone?

Updater: 4.4.0.0080

Sip Version: 4.0.4.2906

Thanks,

--Eric

[SteffenBaierUK]

Hello Eric,

welcome to the Polycom Community.

I am not fully sure if I understood the above.

If the User on the phone is on the line and another call comes into the phone you should hear a message waiting tone n the handset. 

Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

Polycom Global Services

[Anonymous]

no - If a call comes into user 2002 and user 2008 is the attendant. 2008 sees the blinking green light and hears the attendant ring. User 2002 picks up her own line.

While user 2002 is on the phone, a second call comes to her 2002 extension. Attendant 2008 sees the blinking green light but does not hear the attendant ring. User 2002 hears the busy waiting tone but that is irrelevant to my problem.

How do I get attendant 2008 to hear the second inbound call while 2002 is already on the first call?

[Anonymous]

Any ideas?

[SteffenBaierUK]

Hello Eric,

is your scenario as follows:

• Phone A has a BLF instance of Phone B
  
  
• Phone B is in a call and shows busy on Phone A
  
  
• Phone C rings Phone B but on phone A only the LED flashed but no audible sound is played

If yes then I believe I have just reproduced this in my lab.

Please go ahead and raise this via your Polycom reseller and/or Polycom support directly and quote VESC-3775.

I will log this as well as an internal issue but customer issues receive higher priorities.

Best regards

Steffen

[Anonymous]

Thanks for the reference.

I kicked it back to our rep and will see where it goes.

I'll keep this thread updated!

Thanks,

--Eric

[SteffenBaierUK]

Hello Eric,

I actually worked this with our Developers and received an update last week.

We are actually behaving RFC conform as per RFC 4235:

4.1.1. Dialog Element


   The dialog element reports information about a specific dialog or
   "half-dialog".  It has a single mandatory attribute: id.  The id
   attribute provides a single string that can be used as an identifier
   for this dialog or "half-dialog".  This is a different identifier
   than the dialog ID defined in RFC 3261 [2], but related to it.

   For a caller, the id is created when an INVITE request is sent.  When
   a 1xx response with a tag, or a 2xx response is received, the dialog
   is formally created.  The id remains unchanged.  However, if an
   additional 1xx or 2xx is received, resulting in the creation of
   another dialog (and resulting FSM), that dialog is allocated a new
   id.

   For a callee, the id is created when an INVITE outside of an existing
   dialog is received.  When a 2xx or a 1xx with a tag is sent, creating
   the dialog, the id remains unchanged.

   The id MUST be unique amongst all current dialogs at a UA.

   

If I look at an SIP Notify from Asterisk (in my case 10.0.0.0

Initial call to Phone B as shown on Phone A:

<?xml version="1.0"?><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:3002@10.252.122.122"><dialog id="3002" direction="recipient">\n
        <state>early</state>\n
        </dialog>\n
        </dialog-info>\n

Next Call from phone C to phone B as shown on Phone A:

<?xml version="1.0"?><dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="4" state="full" entity="sip:3002@10.252.122.122"><dialog id="3002" direction="recipient">\n
        <state>early</state>\n
        </dialog>\n
        </dialog-info>\n

As you can see in above example the dialog id is both times the same.

So basically, which is arguable with our developers, we should not even visually signal the "new" incoming call.

Please contact your SIP server provider on this as I assume they can work this above scenario out and comment on their interpretation of the RFC.

Best Regards

Steffen Baier

[Anonymous]

Was there any solution to this situation?  I have the exact same issue.  Any help would be wonderful on this.

[SteffenBaierUK]

Hello dpcompany,

welcome to the Polycom Community.

As already explained to the previous user this is working as designed per RFC.

Could you provide more details what exactly your issue is in regards to this post back from 2013?

Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

Polycom Global Services