[Freeswitch-users] Caller ID on inbound calls on Polycom

[Wellie Chao]

Yes, I see how display updates are useful on outbound calls now based on 
your examples, but what about use cases for inbound calls? It doesn't seem 
that useful to have the display update to the extension that is called 
after the call is answered (everybody knows their own extension, after 
all). Just wondering why that default behavior was selected. Is there a 
way to leave display updates turned on for the outbound leg of the call 
and to turn them off for the inbound leg of the call?



Date: Fri, 23 Apr 2010 08:14:52 -0400
From: Steven Ward <steve.d.ward at gmail.com>
Reply-To: freeswitch-users at lists.freeswitch.org
To: freeswitch-users at lists.freeswitch.org
Subject: Re: [Freeswitch-users] Caller ID on inbound calls on Polycom

To give one example, display updates are very useful in the application I'm using.

I have operators using speed dials for dialing out to dialplan that does a fifo out; so I see what the speed dial is when I
press it (e.g. Operator_Call); but then when the operator is connected to the actual caller, the display updates to the CID of
the caller she's talking to - very useful.

Also, people using a SIP phone to call into a fifo see the number they dialed (the number that gets them into the fifo).  But
when they're answered by an actual phone, their display updates to the number of the endpoint they're talking to.



On Thu, Apr 22, 2010 at 10:31 PM, Wellie Chao <wchao at yahoo.com> wrote:
      As I mentioned in my last email, the ignore_display_updates variable did
      the trick, but I am just curious: what is the purpose of the default
      behavior where the display changes to the callee name and number? I am
      guessing there must be some use case (in fact a fairly prevalent use case)
      where showing the callee is more desirable than showing the caller, but
      I'm not aware of what that might be and am curious to find out what the
      use case(s) are. Changing the display to callee also seems to affect call
      logs on the Polycom, which makes the received call log kind of useless.


      Date: Thu, 22 Apr 2010 22:57:53 +0300
      From: Yehavi Bourvine <yehavi.bourvine at gmail.com>
      Reply-To: freeswitch-users at lists.freeswitch.org
      To: freeswitch-users at lists.freeswitch.org
      Subject: Re: [Freeswitch-users] Caller ID on inbound calls on Polycom

      Try adding the following line in your diaplan before the bridge command:
       
      <action application="set" data="ignore_display_updates=true"/>
      (try true and false and see which one works better for you).
       
                                 __Yehavi:
      2010/4/22 Wellie Chao <wchao at yahoo.com>
           I recently updated my FreeSWITCH installation from 1.0.4 to 1.0.6 and now
           I see a strange behavior with caller ID on Polycom phones when handling
           inbound calls.

           Here is the scenario:

           * Call is from 212-555-2222 (external number not on my softswitch)

           * Call is to 212-555-1001 (number on my softswitch, extension 1001)

           * extension 1001 is a Polycom phone (it's an IP301, but same problem
             occurs on other Polycom models such as the 501 and 601). SIP 3.1.4 and
             SIP 3.1.6 both affected. SIP 3.2.3 doesn't run on the IP301/501/601.

           * on phone 1001, the caller ID will display 212-555-2222 while ringing.
             The moment I pick up, the display will change to "From: 1001" (referring
             to the extension of the phone itself).

           Has anyone else experienced this problem, and does anyone know how to fix
           it? It does not occur with the snom 320 (and I assume it does not occur
           with any of the snom models based on extrapolation).

           While the problem only started when I updated from 1.0.4 to 1.0.6, it's
           entirely possible it's a configuration setting on the Polycom rather than
           a FreeSWITCH issue. I'm not sure. Anyone have pointers about how to
           resolve the problem (or even how to go about investigating the root
           cause)?

           _______________________________________________
           FreeSWITCH-users mailing list
           FreeSWITCH-users at lists.freeswitch.org
           http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
           UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
           http://www.freeswitch.org


      _______________________________________________
      FreeSWITCH-users mailing list
      FreeSWITCH-users at lists.freeswitch.org
      http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
      UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
      http://www.freeswitch.org