[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