[Asterisk-Dev] park app vs. extension 700 [sorry for double post but...]

Christopher L. Wade clwade at sparco.com
Wed Dec 1 09:32:43 MST 2004


Sorry for the double post, but since it go no response from the -user 
list and since I'm gonna add another point to my email, this one 
slightly more -dev related, I'll post here as well.  Again, Sorry.

Hi All,

Using Cisco 7940 in SIP mode, is there a reason why a (native sip) blind 
transfer to an extension that calls the Park app would be any different 
than a (native sip) blind transfer to extension 700 (the default parking 
extension)?

They both produce the same effect, a call being parked.  But the * 
manager output is different for the two different methods.

1.) Calling the Park application from any extension defined in 
extensions.conf results in 'From' and 'Channel' being identical.  This 
is bad, this means I have to fire a 'UserEvent' (with ${BRIDGEPEER} as 
the body) before I call the Park application, this is redundant, and 
capable of giving false parks, as Park may fail.

2.) Calling extension 700 results in 'From' being the 'Channel' that 
performed the blind transfer.  This is good, a 'ParkedCall' event from 
this is ensured to have been parked, unlike 1, and I now know who parked 
the call.

Any ideas.  I hope this is understandable, I can explain in greater 
detail (extensions.conf) if needed.

Finally, in implementing a solution for screen based parked call pickup, 
I have finally settled on using just the 'ParkedCall' event from the * 
manager to create a db entry representing the parked call.  This allows 
me to have an XML based pickup utility (for Cisco 7940's) so my users 
don't have to worry about what exten the call was parked to.  This part 
works great.  (save the feature request/bug detailed earlier)

What I haven't found, mostly because it doesn't seem to exist, is an 
event that is fired when a parked call is picked up.  My solution to 
this was simply create a 'UnParkedCall' event that fires during the 
'park_exec' function in res_features.c.  Attached is a patch which 
includes this solution.  This is just a copy-n-paste of the 'ParkedCall' 
event, changing the 'From' to chan->name instead of peer->name, so that 
'From' is the user picking up the call, which matches 'From' in the 
'ParkedCall' event.

The patch also comments out the extension announcement, which I think 
would be better done as a features.conf option, but IWFM.  Feel free to 
ignore that change.

PS, I'm setting 'musicclass', et. al., in the various sip.conf, and 
zapata.conf locations as needed.  However, MOH only works for parking 
when I call SetMusicOnHold before calling Park, transfers to extension 
700 have no MOH at all.  This is the reason for using 1 in the initial 
problem description.  I know it is listed on the wiki as this being 
needed, but why can't * just use the 'musicclass' set in the conf file?
(by the way, MOH works just fine otherwise, during hold, and anywhere 
else you would expect, just not for parking)

Sorry for the exceptionally long post, I've just got alot to talk about 
right now and I have a tendancy to be a little long winded.  Don't flame 
me if this isn't -dev related enough, I simply figured that since it 
included a possible feature via a patch, it might just qualify (if only 
slightly).

Thanks,
Chris

-- 
Christopher L. Wade                     Unistar-Sparco Computers, Inc.
Senior Systems Administrator                            dba Sparco.com
Email: clwade at sparco.com                             7089 Ryburn Drive
Phone: (901) 872 2272 / (800) 840 8400            Millington, TN 38053
Fax:   (901) 872 8482                                              USA
-------------- next part --------------
Index: res/res_features.c
===================================================================
RCS file: /usr/cvsroot/asterisk/res/res_features.c,v
retrieving revision 1.21
diff -u -r1.21 res_features.c
--- res/res_features.c  3 Nov 2004 22:37:55 -0000       1.21
+++ res/res_features.c  1 Dec 2004 16:06:26 -0000
@@ -221,7 +221,7 @@
                                if (adsipark && adsi_available(peer)) {
                                        adsi_announce_park(peer, pu->parkingnum);
                                }
-                               ast_say_digits(peer, pu->parkingnum, "", peer->language);
+/*                                     ast_say_digits(peer, pu->parkingnum, "", peer->language); */
                                if (adsipark && adsi_available(peer)) {
                                        adsi_unload_session(peer);
                                }
@@ -746,6 +746,18 @@
                                ast_log(LOG_WARNING, "Whoa, failed to remove the extension!\n");
                } else
                        ast_log(LOG_WARNING, "Whoa, no parking context?\n");
+
+manager_event(EVENT_FLAG_CALL, "UnParkedCall",
+"Exten: %d\r\n"
+"Channel: %s\r\n"
+"From: %s\r\n"
+"CallerID: %s\r\n"
+"CallerIDName: %s\r\n\r\n"
+,pu->parkingnum, pu->chan->name, chan->name
+,(pu->chan->cid.cid_num ? pu->chan->cid.cid_num : "")
+,(pu->chan->cid.cid_name ? pu->chan->cid.cid_name : "")
+);
+
                free(pu);
        }
        /* JK02: it helps to answer the channel if not already up */


More information about the asterisk-dev mailing list