Polycom/Others directed call pickup with Replaces header

[Dayton Turner]

Hey list,

So I've been trying to test the more efficient "Replaces Header" method of directed call pickups for ringing extensions or parked calls, on a Polycom VVX 400.  I've tried this with both software versions 4.1.4 and 5.3.0 and the behavior appears to be the same.

The only things I've set for this, config-wise, are:

                call.directedCallPickupMethod="native"

                call.directedCallPickupString=""

                feature.directedCallPickup.enabled="1"

                feature.enhancedFeatureKeys.enabled="1"

Then, I've added a BLF contact on the server side like so:

    attendant.resourceList.1.address="1005"

    attendant.resourceList.1.label="1005"

    attendant.resourceList.1.type="normal"

When pressing a ringing BLF key, I would expect the phone to include a Replaces: header, but it's not, and pressing the button simply sends a standard invite.  I found another option regarding Replaces header options, which is described as:

This parameter applies only to directed call pick-up attempts initiated against monitored BLF resources. If set to 1, the phone requires call-id, to-tag, and from-tag to perform a directed call-pickup when call.directedCallPickupMethod is configured as "native". If set to 0, all that is required to perform the directed call pick-up is a call-id.

Which got me wondering whether or not the phone is potentially misinterpreting the dialog message... So I forced it to 0:

    voIpProt.SIP.strictReplacesHeader="0"

Now, when I press the blinking BLF key, the phone UI implies its attempting to make a call, I see no INVITE from the phone, and the phone actually just kind of "hangs". So clearly this option is having some impact of some kind.

My question: I know that work has been done to support this behavior in Kazoo, has anyone configured a Polycom to support it?  And if so, any ideas on what I might be doing wrong?

Thanks!!

[Brandon B]

Hey Dayton - good meeting you (over the list at least). ;)  Question on this.  I see that you were ultimately able to get working (on the IRC channel from 5/15), but i'm having similar issues.  Was there any specific setting you had to do on the Kazoo side to enable this to work?  Right now, we just see a new call initiated to the user on "pickup".  I've triple checked that we have voIpProt.SIP.strictReplacesHeader=“0” in the config.  

[Dayton Turner]

Nothing changed on the Kazoo side, no, are you setting call.directedCallPickupMethod to "native" as well? And setting your contact via attendant.resourcelist?

[Brandon B]

Yeah, I've got this in the sip.cfg:

<feature 

         feature.urlDialing.enabled="0" 

         feature.directedCallPickup.enabled="1" 

         feature.enhancedFeatureKeys.enabled="1" 

         feature.presence.enabled="1"/>

<call 

         call.directedCallPickupMethod="native" 

         call.directedCallPickupString="" 

         call.parkedCallRetrieveMethod="native"

         />

  <voIpProt>

     <SIP

  voIpProt.SIP.specialEvent.checkSync.alwaysReboot="1"

  voIpProt.SIP.enable="1"

  voIpProt.SIP.local.port="5060"

           voIpProt.SIP.strictReplacesHeader=“0”/>

and this in the mac_reg.cfg:

<attendant attendant.reg="1" attendant.ringType="1"

 attendant.behaviors.display.spontaneousCallAppearances.normal="0" 

attendant.behaviors.display.spontaneousCallAppearances.automata="0"

 attendant.behaviors.display.remoteCallerID.normal="1"

 attendant.behaviors.display.remoteCallerID.automata="1" 

 attendant.resourceList.1.type="normal"

attendant.resourceList.1.address="1236" attendant.resourceList.1.label="Pramod V"

Knowing that nothing special is needed on backend, I can do some more testing on my side.  Grateful for any quick scan you can do on the lines above for sanity check, though.  Thanks!

On Tuesday, April 21, 2015 at 4:01:26 PM UTC-7, Dayton Turner wrote:

[Dayton Turner]

That all looks good to me, matches what I have. My most recent testing was against kazoo 3.20 and the latest kamailio configs, that may play a factor in my testing of course. I do recall beating my head against a wall about this, where it simply sent a new call to the ringing contact instead of a replaces header. Then after testing it one more time, it "just worked" 

--
You received this message because you are subscribed to a topic in the Google Groups "2600hz-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/2600hz-dev/abjkl3xEJD4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 2600hz-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dayton Turner]

OK so I just updated to 5.4 and it "works" now, but only because it finally dials *31 instead of kfp+ba1h71d0 when you try to pick it back up - it does also still try the Replaces: mechanism, but it appears as though its using the wrong Call-ID - it queries a call-id that doesnt seem to exist.  The Target-Call-ID would match, but thats not what its looking up. (in kazoo)

Is this something that was recently modified in omnipresence (since 3.20?)

Because it tries the replaces method now, and it fails and dials *31, the "pickup" itself from the time of buttonpress til you're on the line with the person is roughly 10 seconds.

Ideas?

Brandon B

July 24, 2015 at 5:57 PM

Just an update here as I saw some chatter on IRC regarding the call parking that is a similar feature.  By upgrading to the 5.4 polycom firmware we were able to get park/pickup to work with one-touch.  The directed pickup *kind of* works.  It picks up the call, but after exactly 30 seconds, it starts playing the original called party's voicemail message.  So it is a good exercise in talking fast!  In any case, wanted to put the update out there.

On Tuesday, April 21, 2015 at 4:01:26 PM UTC-7, Dayton Turner wrote:

--

Dayton Turner, CEO
Voxter Communications
(604) 638-3851
www.voxter.com

[Dayton Turner]

Thanks for the the tip Brandon!

Do you know what was required on the phone config side for the parking to function or was it as easy as automata contacts for each slot?

Dayton Turner, CEO
Voxter Communications Inc
P: (604)629-8647 F: (604)629-8646
www.voxter.com

On Fri, Jul 24, 2015 at 5:57 PM -0700, "Brandon B" <bra...@nofg.net> wrote:

Just an update here as I saw some chatter on IRC regarding the call parking that is a similar feature.  By upgrading to the 5.4 polycom firmware we were able to get park/pickup to work with one-touch.  The directed pickup *kind of* works.  It picks up the call, but after exactly 30 seconds, it starts playing the original called party's voicemail message.  So it is a good exercise in talking fast!  In any case, wanted to put the update out there.

On Tuesday, April 21, 2015 at 4:01:26 PM UTC-7, Dayton Turner wrote:

[Brandon B]

Just an update here as I saw some chatter on IRC regarding the call parking that is a similar feature.  By upgrading to the 5.4 polycom firmware we were able to get park/pickup to work with one-touch.  The directed pickup *kind of* works.  It picks up the call, but after exactly 30 seconds, it starts playing the original called party's voicemail message.  So it is a good exercise in talking fast!  In any case, wanted to put the update out there.

On Tuesday, April 21, 2015 at 4:01:26 PM UTC-7, Dayton Turner wrote:

[VOIPITS INC.]

Just in case it is useful to anyone, on recent Yealinks the setting required for this to work was called "Dialog Info Call Pickup".  It needs to be enabled, and Directed call Pickup code needed to be "**".  Both settings found in the account section under Advanced (for whichever account)

Also, this works out of the box on Grandstreams.