Bill Gibbs
2006-Aug-28 10:15 UTC
[asterisk-users] Call parking with Polycom's - works but MOH stops in one scenario
501s, 601s running 1.6.5 Asterisk 1.2.10 NAT Logs at the bottom of the email Using AMP or FreePBX for the config files Here's what's happening: Call comes in Answer the call On the Polycom Hit Transfer (person calling in hears MOH just fine) Enter park extension (my case - 190) Listen to the digits being read back, ie 191 Now here's where it gets odd 1) If I wait after the digits are read back MOH starts on the Polycom At this point if I hit Transfer (complete the attended transfer obviously) to send the call to the park, MOH stops on the phone calling in. However parking continues to work, including ring back...so other than the MOH stopping (which I assume has to do something with Asterisk not thinking the phone is on hold anymore?) the park feature works fine. Basically if I wait too long it never initiates the MOH again to the parked call however - is this because Asterisk thinks it's now on a "real" extension hence no MOH (which may be why it plays back MOH if I transfer the call to the park extension in the first place????) The call DOES show up in "show parkedcalls" though so Asterisk obviously knows it is parked. 2) Now if I hit Transfer quickly after the digits are read back (basically before it finishes the last digit but enough for me to know what it is), MOH continues on the person who is parked (which is the behavior I want) Park pickup/ringback works fine....and the logs show this 3) Blind transfer -MOH always works but not what I want since the person who put it on Park now doesn't know what extension to pick it up I also see in the logs after the final "transfer" -- Incoming call: Got SIP response 500 "Internal Server Error" back from 192.168.1.100 No matter if I hit Transfer the 2nd time quickly or wait for MOH to start On a side note, anyone ever get the Polycom "call-park" and Park softkey feature to work? There doesn't seem to be any documentation about it and hitting the button does nothing. Music on hold plays (transfer quick, just before the last digit is read back) Notice the MOH starts for the parked call after the ZOMBIE lines -- SIP/102-09515c68 is ringing -- SIP/102-09515c68 answered SIP/X.X.X.X-094fc5d8 -- Started music on hold, class 'default', on SIP/X.X.X.X-094fc5d8 -- Executing Park("SIP/102-09590970", "") in new stack == Parked SIP/102-09590970 on 191. Will timeout back to extension [from-internal] s, 1 in 45 seconds -- Added extension '191' priority 1 to parkedcalls -- Playing 'digits/1' (language 'en') -- Playing 'digits/9' (language 'en') -- Playing 'digits/1' (language 'en') -- Stopped music on hold on SIP/X.X.X.X-094fc5d8 == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-09590970<ZOMBIE>' in macro 'dial' == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-09590970<ZOMBIE>' in macro 'exten-vm' == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-09590970<ZOMBIE>' -- Started music on hold, class 'default', on SIP/X.X.X.X-094fc5d8 == Spawn extension (from-internal, s, 1) exited KEEPALIVE on 'SIP/X.X.X.X-094fc5d8' -- Incoming call: Got SIP response 500 "Internal Server Error" back from 192.168.1.100 so I see how it started, then stopped, then started MOH again now if I do it after I wait after the last digit is read and then hit Transfer here's the log output: It never initiates the MOH - is this because Asterisk thinks it's now on a "real" extension hence no MOH Notice how the started MOH is initiated BEFORE the lines about the ZOMBIE stuff than above where it worked -- SIP/102-094f9970 is ringing -- SIP/102-094f9970 answered SIP/X.X.X.X-09515c68 -- Started music on hold, class 'default', on SIP/X.X.X.X-09515c68 -- Executing Park("SIP/102-0950a2b0", "") in new stack == Parked SIP/102-0950a2b0 on 191. Will timeout back to extension [from-internal] s, 1 in 45 seconds -- Added extension '191' priority 1 to parkedcalls -- Playing 'digits/1' (language 'en') -- Playing 'digits/9' (language 'en') -- Playing 'digits/1' (language 'en') -- Started music on hold, class 'default', on SIP/102-0950a2b0 == Spawn extension (from-internal, s, 1) exited KEEPALIVE on 'SIP/102-0950a2b0' -- Stopped music on hold on SIP/102-0950a2b0 -- Stopped music on hold on SIP/X.X.X.X-09515c68 -- Started music on hold, class 'default', on SIP/X.X.X.X-09515c68 == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-0950a2b0<ZOMBIE>' in macro 'dial' == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-0950a2b0<ZOMBIE>' in macro 'exten-vm' == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-0950a2b0<ZOMBIE>' -- Incoming call: Got SIP response 500 "Internal Server Error" back from 192.168.1.100 Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060828/1281e0a4/attachment.htm
Bill Gibbs
2006-Aug-28 13:42 UTC
[asterisk-users] RE: Call parking with Polycom's - works but MOH stops in one scenario
When using the # key identified in features.conf this issue goes away. Still...odd...and so is the lack of documentation on the built in Park button... Bill ________________________________ From: Bill Gibbs Sent: Monday, August 28, 2006 1:02 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Call parking with Polycom's - works but MOH stops in one scenario 501s, 601s running 1.6.5 Asterisk 1.2.10 NAT Logs at the bottom of the email Using AMP or FreePBX for the config files Here's what's happening: Call comes in Answer the call On the Polycom Hit Transfer (person calling in hears MOH just fine) Enter park extension (my case - 190) Listen to the digits being read back, ie 191 Now here's where it gets odd 1) If I wait after the digits are read back MOH starts on the Polycom At this point if I hit Transfer (complete the attended transfer obviously) to send the call to the park, MOH stops on the phone calling in. However parking continues to work, including ring back...so other than the MOH stopping (which I assume has to do something with Asterisk not thinking the phone is on hold anymore?) the park feature works fine. Basically if I wait too long it never initiates the MOH again to the parked call however - is this because Asterisk thinks it's now on a "real" extension hence no MOH (which may be why it plays back MOH if I transfer the call to the park extension in the first place????) The call DOES show up in "show parkedcalls" though so Asterisk obviously knows it is parked. 2) Now if I hit Transfer quickly after the digits are read back (basically before it finishes the last digit but enough for me to know what it is), MOH continues on the person who is parked (which is the behavior I want) Park pickup/ringback works fine....and the logs show this 3) Blind transfer -MOH always works but not what I want since the person who put it on Park now doesn't know what extension to pick it up I also see in the logs after the final "transfer" -- Incoming call: Got SIP response 500 "Internal Server Error" back from 192.168.1.100 No matter if I hit Transfer the 2nd time quickly or wait for MOH to start On a side note, anyone ever get the Polycom "call-park" and Park softkey feature to work? There doesn't seem to be any documentation about it and hitting the button does nothing. Music on hold plays (transfer quick, just before the last digit is read back) Notice the MOH starts for the parked call after the ZOMBIE lines -- SIP/102-09515c68 is ringing -- SIP/102-09515c68 answered SIP/X.X.X.X-094fc5d8 -- Started music on hold, class 'default', on SIP/X.X.X.X-094fc5d8 -- Executing Park("SIP/102-09590970", "") in new stack == Parked SIP/102-09590970 on 191. Will timeout back to extension [from-internal] s, 1 in 45 seconds -- Added extension '191' priority 1 to parkedcalls -- Playing 'digits/1' (language 'en') -- Playing 'digits/9' (language 'en') -- Playing 'digits/1' (language 'en') -- Stopped music on hold on SIP/X.X.X.X-094fc5d8 == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-09590970<ZOMBIE>' in macro 'dial' == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-09590970<ZOMBIE>' in macro 'exten-vm' == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-09590970<ZOMBIE>' -- Started music on hold, class 'default', on SIP/X.X.X.X-094fc5d8 == Spawn extension (from-internal, s, 1) exited KEEPALIVE on 'SIP/X.X.X.X-094fc5d8' -- Incoming call: Got SIP response 500 "Internal Server Error" back from 192.168.1.100 so I see how it started, then stopped, then started MOH again now if I do it after I wait after the last digit is read and then hit Transfer here's the log output: It never initiates the MOH - is this because Asterisk thinks it's now on a "real" extension hence no MOH Notice how the started MOH is initiated BEFORE the lines about the ZOMBIE stuff than above where it worked -- SIP/102-094f9970 is ringing -- SIP/102-094f9970 answered SIP/X.X.X.X-09515c68 -- Started music on hold, class 'default', on SIP/X.X.X.X-09515c68 -- Executing Park("SIP/102-0950a2b0", "") in new stack == Parked SIP/102-0950a2b0 on 191. Will timeout back to extension [from-internal] s, 1 in 45 seconds -- Added extension '191' priority 1 to parkedcalls -- Playing 'digits/1' (language 'en') -- Playing 'digits/9' (language 'en') -- Playing 'digits/1' (language 'en') -- Started music on hold, class 'default', on SIP/102-0950a2b0 == Spawn extension (from-internal, s, 1) exited KEEPALIVE on 'SIP/102-0950a2b0' -- Stopped music on hold on SIP/102-0950a2b0 -- Stopped music on hold on SIP/X.X.X.X-09515c68 -- Started music on hold, class 'default', on SIP/X.X.X.X-09515c68 == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-0950a2b0<ZOMBIE>' in macro 'dial' == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-0950a2b0<ZOMBIE>' in macro 'exten-vm' == Spawn extension (macro-dial, s, 10) exited non-zero on 'SIP/102-0950a2b0<ZOMBIE>' -- Incoming call: Got SIP response 500 "Internal Server Error" back from 192.168.1.100 Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060828/1da7151d/attachment.htm