asterisk

Commit Graph

Author	SHA1	Message	Date
Corey Farrell	b35ac9e566	res_pjsip: Fix leak of fake_auth references. pjsip_distributor leaks references to fake_auth when the default realm has not changed. ASTERISK-27306 Change-Id: I3fcf103b3680ad2d1d4610dcd6738eeaebf4d202	8 years ago
George Joseph	a10bc3e23f	Merge "pjsip_distributor.c: Fix deadlock with TCP type transports."	8 years ago
Richard Mudgett	b485f6c59c	pjsip_distributor.c: Fix deadlock with TCP type transports. When a SIP message comes in on a transport, pjproject obtains the lock on the transport and pulls the data out of the socket. Unlike UDP, the TCP transport does not allow concurrent access. Without concurrency the transport lock is not released when the transport's message complete callback is called. The processing continues and eventually Asterisk starts processing the SIP message. The first thing Asterisk tries to do is determine the associated dialog of the message to determine the associated serializer. To get the associated serializer safely requires us to get the dialog lock. To send a request or response message for a dialog, pjproject obtains the dialog lock and then obtains the transport lock. Deadlock can result because of the opposite order the locks are obtained. * Fix the deadlock by obtaining the serializer associated with the dialog another way that doesn't involve obtaining the dialog lock. In this case, we use an ao2 container to hold the associated endpoint and serializer. The new locks are held a brief time and won't overlap other existing lock times. ASTERISK-27090 #close Change-Id: I9ed63f4da9649e9db6ed4be29c360968917a89bd	8 years ago
Richard Mudgett	65a5ac0168	pjsip_distributor.c: Fix unidentified_requests hash functions. The OBJ_SEARCH_xxx defines should not be used as if they were individual bits. They represent a multi-bit enumeration value field. Change-Id: I32abc9a475396dab02402a7014357dd94284e17b	8 years ago
zuul	1774f778f6	Merge "res_pjsip: Update artificial auth whenever default_realm changes."	9 years ago
Richard Mudgett	6400f5f309	res_pjsip: Update artificial auth whenever default_realm changes. There was code attempting to update the artificial authentication object whenever the default_realm changed. However, once the artificial authentication object was created it would never get updated. The artificial authentication object would require a system restart for a change to the default_realm to take effect. ASTERISK-26799 Change-Id: Id59036e9529c2d3ed728af2ed904dc36e7094802	9 years ago
Richard Mudgett	54812f18b5	pjsip_distributor.c: Update some debug messages to get transaction name. * Removed overloaded unmatched response ignore. We obviously sent the request so we shouldn't ignore it because it isn't new work. ASTERISK-26669 ASTERISK-26738 Change-Id: I55fb5cadc83a8e6699b347c6dc7fa32c5a617d37	9 years ago
Richard Mudgett	ce810a892b	pjsip_distributor.c: Fix off-nominal tdata ref leak. Change-Id: I571f371d0956a8039b197b4dbd8af6b18843598d	9 years ago
Joshua Colp	901e612739	res_pjsip: Only invoke unidentified endpoint logic when unidentified. The code was incorrectly invoking the unidentified logic when an endpoint had actually been identified, causing log messages to be output. ASTERISK-26349 #close Change-Id: Id8104fc9e3d138d5e8b6f6977ecc08765fd17d4f	9 years ago
Mark Michelson	28b2aeba0b	res_pjsip: Do not crash on ACKs from unknown endpoints. The endpoint identification PJSIP module is intended to identify which endpoint an incoming request is from. If an endpoint is not identified, then an artificial endpoint is used in its place when proceeding. The problem is that the ACK request type is an exception to the rule. The artificial endpoint is not used when processing an ACK. This results in the possibility of having a NULL endpoint being used further on. The reason ACK is an exception is an attempt not to spam security logs with unidentified requests. Presumably, you've already logged the unidentified request on the preceeding INVITE. Up until Asterisk 13.10, retrieving a NULL endpoint in this fashion didn't cause an issue. A new change in 13.10 added endpoint ACL checking shortly after endpoint identification. Because we are accessing a NULL endpoint, this ACL check resulted in a crash. The fix here is to be sure to retrieve the artificial endpoint for all request types. ACKs still do not generate unidentified request security events. ASTERISK-26264 #close Reported by nappsoft AST-2016-006 Change-Id: Ie0c795ae2d72273decb972dd74b6a1489fb6b703	9 years ago
Richard Mudgett	b6e03a5ff3	pjsip_distributor.c: Add missing allocation failure check. Change-Id: I932ab2cea845e534d9ff318035b6de39972d3b28	9 years ago
Richard Mudgett	2cd67d5b07	taskprocessors: Implement high/low water mark alerts. When taskprocessors get backed up, there is a good chance that we are being overloaded and need to defer adding new work to the system. * Implemented a high/low water alert mechanism for modules to check if the system is being overloaded and take appropriate action. When a taskprocessor is created it has default congestion levels set. A taskprocessor can later have those congestion levels altered for specific needs if stress testing shows that the taskprocessor is a symptom of overloading or needs to handle bursty activity without triggering an overload alert. * Add CLI "core show taskprocessor" low/high water columns. * Fixed __allocate_taskprocessor() to not use RAII_VAR(). RAII_VAR() was never a good thing to use when creating a taskprocessor because of the nature of how its references needed to be cleaned up on a partial creation. * Made res_pjsip's distributor check if the taskprocessor overload alert is active before placing a message representing brand new work onto a distributor serializer. ASTERISK-26088 Reported by: Richard Mudgett Change-Id: I182f1be603529cd665958661c4c05ff9901825fa	10 years ago
Richard Mudgett	2ff26e9746	pjsip_distributor.c: Consistently pick a serializer for messages. Incoming messages that are not part of a dialog or a recognized response to one of our requests need to be sent to a consistent serializer. Under load we may be queueing retransmissions before we can process the original message. We don't need to throw these messages onto random serializers and cause reentrancy and message sequencing problems. * Created a pool of pjsip/distributor serializers that get picked by hashing the call-id and remote tag strings of the received messages. * Made ast_sip_destroy_distributor() destroy items in the reverse order of creation. ASTERISK-26088 Reported by: Richard Mudgett Change-Id: I2ce769389fc060d9f379977f559026fbcb632407	10 years ago
Richard Mudgett	df2791da8f	pjsip_distributor.c: Ignore messages until fully booted. We should not be processing any incoming messages until we are fully booted. We may not have dialplan or other needed configuration loaded yet. ASTERISK-26089 #close Reported by: Scott Griepentrog ASTERISK-26088 Reported by: Richard Mudgett Change-Id: I584aefb4f34b885a8927e1f13a2c64babd606264	10 years ago
Richard Mudgett	aec7916595	pjsip_distributor.c: Use correct rdata info access method (Part 2). The pjproject doxygen for rdata->msg_info.info says to call pjsip_rx_data_get_info() instead of accessing the struct member directly. You need to call the function mostly because the function will generate the struct member value if it is not already setup. Change-Id: I4d519385a577f3e9d9193a88125e493cf17fa799	10 years ago
Richard Mudgett	7d44d12816	pjsip_distributor.c: Use correct rdata info access method. The pjproject doxygen for rdata->msg_info.info says to call pjsip_rx_data_get_info() instead of accessing the struct member directly. You need to call the function mostly because the function will generate the struct member value if it is not already setup. Change-Id: Iafe8b01242b7deb0ebfdc36685e21374a43936d2	10 years ago
Mark Michelson	1c02b19b79	res_pjsip: Match dialogs on responses better. When receiving an incoming response to a dialog-starting INVITE, we were not matching the response to the INVITE dialog. Since we had not recorded the to-tag to the dialog structure, the PJSIP-provided method to find the dialog did not match. Most of the time, this was not a problem, because there is a fall-back that makes the response get routed to the same serializer that the request was sent on. However, in cases where an asynchronous DNS lookup occurs in the PJSIP core, the thread that sends the INVITE is not actually a threadpool serializer thread. This means we are unable to record a serializer to handle the incoming response. Now, imagine what happens when an INVITE is sent on a non-serialized thread, and an error response (such as a 486) arrives. The 486 ends up getting put on some random threadpool thread. Eventually, a hangup task gets queued on the INVITE dialog serializer. Since the 486 is being handled on a different thread, the hangup task can execute at the same time that the 486 is being handled. The hangup task assumes that it is the sole owner of the INVITE session and channel, so it ends up potentially freeing the channel and NULLing the session's channel pointer. The thread handling the 486 can crash as a result. This change has the incoming response match the INVITE transaction, and then get the dialog from that transaction. It's the same method we had been using for matching incoming CANCEL requests. By doing this, we get the INVITE dialog and can ensure that the 486 response ends up being handled by the same thread as the hangup, ensuring that the hangup runs after the 486 has been completely handled. ASTERISK-25941 #close Reported by Javier Riveros Change-Id: I0d4cc5d07e2a8d03e9db704d34bdef2ba60794a0	10 years ago
Alexei Gradinari	69a85a519f	res_pjsip: Endpoint IP Access Controls With the old SIP module we can use IP access controls per peer. PJSIP module missing this feature. This patch added next configuration Endpoint options: "acl" - list of IP ACL section names in acl.conf "deny" - List of IP addresses to deny access from "permit" - List of IP addresses to permit access from "contact_acl" - List of Contact ACL section names in acl.conf "contact_deny" - List of Contact header addresses to deny "contact_permit" - List of Contact header addresses to permit This patch also better logging failed request: add custom message instead of "No matching endpoint found" add SIP method to logging ASTERISK-25900 Change-Id: I456dea3909d929d413864fb347d28578415ebf02	10 years ago
George Joseph	4f8cfa0220	pjsip_distributor: Add missing newline to NOTICE There was a newline missing from the end of the "no matching endpoint" notice. Change-Id: Idc11fe5bc0354072291663dbffe648c471e39181	10 years ago
George Joseph	4ebf9a938d	res_pjsip: Add ability to identify by Authorization username A feature of chan_sip that service providers relied upon was the ability to identify by the Authorization username. This is most often used when customers have a PBX that needs to register rather than identify by IP address. From my own experiance, this is pretty common with small businesses who otherwise don't need a static IP. In this scenario, a register from the customer's PBX may succeed because From will usually contain the PBXs account id but an INVITE will contain the caller id. With nothing recognizable in From, the service provider's Asterisk can never match to an endpoint and the INVITE just stays unauthorized. The fixes: A new value "auth_username" has been added to endpoint/identify_by that will use the username and digest fields in the Authorization header instead of username and domain in the the From header to match an endpoint, or the To header to match an aor. This code as added to res_pjsip_endpoint_identifier_user rather than creating a new module. Although identify_by was always a comma-separated list, there was only 1 choice so order wasn't preserved. So to keep the order, a vector was added to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar to find the aor. The res_pjsip_endpoint_identifier_* modules are called in globals/endpoint_identifier_order. Along the way, the logic in res_pjsip_registrar was corrected to match most-specific to least-specific as res_pjsip_endpoint_identifier_user does. The order is: username@domain username@domain_alias username Auth by username does present 1 problem however, the first INVITE won't have an Authorization header so the distributor, not finding a match on anything, sends a securty_alert. It still sends a 401 with a challenge so the next INVITE will have the Authorization header and presumably succeed. As a result though, that first security alert is actually a false alarm. To address this, a new feature has been added to pjsip_distributor that keeps track of unidentified requests and only sends the security alert if a configurable number of unidentified requests come from the same IP in a configurable amout of time. Those configuration options have been added to the global config object. This feature is only used when auth_username is enabled. Finally, default_realm was added to the globals object to replace the hard coded "asterisk" used when an endpoint is not yet identified. The testsuite tests all pass but new tests are forthcoming for this new feature. ASTERISK-25835 #close Reported-by: Ross Beer Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d	10 years ago
Mark Michelson	1afc8432dc	PJSIP: Prevent deadlock due to dialog/transaction lock inversion. A deadlock was observed where the monitor thread was stuck, therefore resulting in no incoming SIP traffic being processed. The problem occurred when two 200 OK responses arrived in response to a terminating NOTIFY request sent from Asterisk. The first 200 OK was dispatched to a threadpool worker, who locked the corresponding transaction. The second 200 OK arrived, resulting in the monitor thread locking the dialog. At this point, the two threads are at odds, because the monitor thread attempts to lock the transaction, and the threadpool thread loops attempting to try to lock the dialog. In this case, the fix is to not have the monitor thread attempt to hold both the dialog and transaction locks at the same time. Instead, we release the dialog lock before attempting to lock the transaction. There have also been some debug messages added to the process in an attempt to make it more clear what is going on in the process. ASTERISK-25668 #close Reported by Mark Michelson Change-Id: I4db0705f1403737b4360e33a8e6276805d086d4a	10 years ago
Mark Michelson	e8881e1770	Taskprocessors: Increase high-water mark In practical tests, we have seen certain taskprocessors, specifically Stasis subscription taskprocessors, cross the recently-added high-water mark and emit a warning. This high-water mark warning is only intended to be emitted when things have tanked on the system and things are heading south quickly. In the practical tests, the Stasis taskprocessors sometimes had a max depth of 180 tasks in them, and Asterisk wasn't in any danger at all. As such, this ups the high-water mark to 500 tasks instead. It also redefines the SIP threadpool request denial number to be a multiple of the taskprocessor high-water mark. Change-Id: Ic8d3e9497452fecd768ac427bb6f58aa616eebce	10 years ago
Mark Michelson	40b58a5d2b	res_pjsip distributor: Don't send 503 response to responses. When the SIP threadpool is backed up with tasks, we send 503 responses to ensure that we don't try to overload ourselves. The problem is that we were not insuring that we were not trying to send a 503 to an incoming SIP response. This change makes it so that we only send the 503 on incoming requests. Change-Id: Ie2b418d89c0e453cc6c2b5c7d543651c981e1404	10 years ago
Mark Michelson	264c74aa22	res_pjsip: Deny requests when threadpool queue is backed up. We have observed situations where the SIP threadpool may become deadlocked. However, because incoming traffic is still arriving, the SIP threadpool's queue can continue to grow, eventually running the system out of memory. This change makes it so that incoming traffic gets rejected with a 503 response if the queue is backed up too much. Change-Id: I4e736d48a2ba79fd1f8056c0dcd330e38e6a3816	10 years ago
Richard Mudgett	30cd559345	DNS: Need to use the same serializer for a pjproject SIP transaction. All send/receive processing for a SIP transaction needs to be done under the same threadpool serializer to prevent reentrancy problems inside pjproject when using an external DNS resolver to process messages for the transaction. * Add threadpool API call to get the current serializer associated with the worker thread. * Pick a serializer from a pool of default serializers if the caller of res_pjsip.c:ast_sip_push_task() does not provide one. This is a simple way to ensure that all outgoing SIP request messages are processed under a serializer. Otherwise, any place where a pushed task is done that would result in an outgoing out-of-dialog request would need to be modified to supply a serializer. Serializers from the default serializer pool are picked in a round robin sequence for simplicity. A side effect is that the default serializer pool will limit the growth of the thread pool from random tasks. This is not necessarily a bad thing. * Made pjsip_resolver.c use the requesting thread's serializer to execute the async callback. * Made pjsip_distributor.c save the thread's serializer name on the outgoing request tdata struct so the response can be processed under the same serializer. ASTERISK-25115 #close Reported by: John Bigelow Change-Id: Iea71c16ce1132017b5791635e198b8c27973f40a	11 years ago
Kevin Harwell	e62bd46511	res_pjsip: make it unloadable (take 2) Due to the original patch causing memory corruptions it was removed until the problem could be resolved. This patch is the original patch plus some added locking around stasis router subcription that was needed to avoid the memory corruption. Description of the original problem and patch (still applicable): The res_pjsip module was previously unloadable. With this patch it can now be unloaded. This patch is based off the original patch on the issue (listed below) by Corey Farrell with a few modifications. Namely, removed a few changes not required to make the module unloadable and also fixed a bug that would cause asterisk to crash on unloading. This patch is the first step (should hopefully be followed by another/others at some point) in allowing res_pjsip and the modules that depend on it to be unloadable. At this time, res_pjsip and some of the modules that depend on res_pjsip cannot be unloaded without causing problems of some sort. The goal of this patch is to get res_pjsip and only res_pjsip to be able to unload successfully and/or shutdown without incident (crashes, leaks, etc...). Other dependent modules may still cause problems on unload. Basically made sure, with the patch applied, that res_pjsip (with no other dependent modules loaded) could be succesfully unloaded and Asterisk could shutdown without any leaks or crashes that pertained directly to res_pjsip. ASTERISK-24485 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4363/ patches: pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909) ........ Merged revisions 431179 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431180 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kevin Harwell	07e2a48ab1	REVERTING res_pjsip: make it unloadable Due to the original patch causing memory corruptions the patch is being removed until the problem can be resolved. ........ Merged revisions 430734 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430735 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kevin Harwell	49542a794b	res_pjsip: make it unloadable The res_pjsip module was previously unloadable. With this patch it can now be unloaded. This patch is based off the original patch on the issue (listed below) by Corey Farrell with a few modifications. Namely, removed a few changes not required to make the module unloadable and also fixed a bug that would cause asterisk to crash on unloading. This patch is the first step (should hopefully be followed by another/others at some point) in allowing res_pjsip and the modules that depend on it to be unloadable. At this time, res_pjsip and some of the modules that depend on res_pjsip cannot be unloaded without causing problems of some sort. The goal of this patch is to get res_pjsip and only res_pjsip to be able to unload successfully and/or shutdown without incident (crashes, leaks, etc...). Other dependent modules may still cause problems on unload. Basically made sure, with the patch applied, that res_pjsip (with no other dependent modules loaded) could be succesfully unloaded and Asterisk could shutdown without any leaks or crashes that pertained directly to res_pjsip. ASTERISK-24485 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4311/ patches: pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909) ........ Merged revisions 430628 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430629 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	47074f4bfd	res_pjsip: Ensure in-dialog responses have an endpoint associated. When handling incoming messages we determine if it is associated with a dialog. If so we use that to determine what serializer and endpoint to use for the message. Previously this would pass the endpoint to the endpoint lookup module to actually place the endpoint completely on the message. For in-dialog responses, however, this did not occur as dialog processing took over and the endpoint lookup did not occur. This change just places the endpoint in the expected spot immediately instead of relying on the endpoint lookup module. In-dialog responses thus have the expected endpoint. AST-1459 #close Review: https://reviewboard.asterisk.org/r/4146/ ........ Merged revisions 427490 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427491 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427492 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	45b7b474ac	res_pjsip: Prevent crashes when PJPROJECT presents an rdata with no message When a message that exceeds the PJ_MAX_PKT_SIZE is sent over a reliable transport, it is possible (although it shouldn't occur) for pjproject to pass up an rdata object with a NULL msg in the msg_info. Needless to say, things that attempt to dereference this are in for a rough ride. In particular, this caused crashes in three different locations, all of which are 'low level' enough to intercept an rdata object early in processing: (1) res_pjsip_logger (2) res_hep_pjsip (3) res_pjsip/distributor Anything that can intercept an rdata object before res_pjsip/distributor should be defensive when looking at the received packet. #SIPit31 ASTERISK-24369 #close Reported by: Matt Jordan ........ Merged revisions 424618 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 424619 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424620 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	7cbb6eab15	PJSIP: Add Path header support This adds Path support to chan_pjsip in res_pjsip_path.c with minimal additions in res_pjsip_registrar.c to store the path and additions in res_pjsip_outbound_registration.c to enable advertisement of path support to registrars and intervening proxies. Path information is stored on contacts and is enabled via Address of Record (AoRs) and Registration configuration sections. While adding path support, it became necessary to be able to add SIP supplements that handled messages outside of sessions, so a framework for handling these types of hooks was added in parallel to the already-existing session supplements and several senders of out-of-dialog requests were refactored as a result. (closes issue ASTERISK-21084) Review: https://reviewboard.asterisk.org/r/3050/ ........ Merged revisions 405565 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405566 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	aced8bdd2e	Fix erroneous behavior when sending auth rejection to artificial endpoint. We were not including an authentication challenge when sending a 401 response to unmatched endpoints. This was due to the conversion to use a vector for authentication section names on an endpoint. The vector for artificial endpoints was empty, resulting in the challenge being sent back containing no challenges. This is worked around by placing a bogus value in the artificial endpoint's auth vector. This value is never looked up by anything, since they instead will directly call ast_sip_get_artificial_auth(). git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405420 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	b18ed67d16	Switch PJSIP auth to use a vector. Since Asterisk has a vector API now, places where arrays are manually resized don't really make sense any more. Since the auth work in PJSIP was freshly-written, it was easy to reform it to use a vector. Review: https://reviewboard.asterisk.org/r/3044 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403499 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	1b14a78d14	res_pjsip: Add support for building against pjproject with SIP transaction group lock support. SIP transaction group lock support has been backported into our pjproject. Since the code now internally uses a group lock the code is now changed to unlock it if present. Note that the act of finding the transaction is what actually returns it locked. For further information about group locks check out the wiki page at: http://trac.pjsip.org/repos/wiki/Group_Lock (issue ASTERISK-22818) Reported by: Matt Jordan ........ Merged revisions 402864 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402865 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	bb1568caa1	PJSIP: Add log messages when requests are received for non-existent endpoints (closes issue ASTERISK-22552) Reported by: Rusty Newton Review: https://reviewboard.asterisk.org/r/2934/ ........ Merged revisions 401938 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@401939 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	a181544299	Fix dialog matching in the SIP distributor. Dialog matching is performed in the distributor for the sole purpose of retrieving an associated serializer so the request may be serialized. This patch fixes two problems. First, incoming CANCEL requests that had no to-tag (which really should be all CANCEL requests) would not match with a dialog. An earlier bug fix to deal with early CANCEL requests would result in the CANCEL being replied to with a 481. The fix for this is to find the matching INVITE transaction and get the dialog from that transaction. Second, no SIP responses were matching dialogs. This is because we were inverting the tags that we were passing into PJSIP's dialog finding function. This logic has been corrected by setting local and remote tag variables based on whether the incoming message is a request or response. ........ Merged revisions 397854 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397855 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	735b30ad71	The large GULP->PJSIP renaming effort. The general gist is to have a clear boundary between old SIP stuff and new SIP stuff by having the word "SIP" for old stuff and "PJSIP" for new stuff. Here's a brief rundown of the changes: * The word "Gulp" in dialstrings, functions, and CLI commands is now "PJSIP" * chan_gulp.c is now chan_pjsip.c * Function names in chan_gulp.c that were "gulp_" are now "chan_pjsip_" * All files that were "res_sip" are now "res_pjsip" * The "res_sip" directory is now "res_pjsip" * Files in the "res_pjsip" directory that began with "sip_" are now "pjsip_" * The configuration file is now "pjsip.conf" instead of "res_sip.conf" * The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP" * CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as the starting word instead of "sip" git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395764 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago

37 Commits (8a281776d5e92183489624da7e1993c560e2fecc)