asterisk

Commit Graph

Author	SHA1	Message	Date
Mark Michelson	24eec5a10b	res_pjsip_nat: Adjust when contact should be rewritten. A previous change made the contact only get rewritten if the dialog's route set was not marked frozen. Unfortunately, while the intent of this is correct, the dialog's route set actually gets marked as frozen earlier than expected, especially for UAS dialogs. Instead, the idea is that the contact needs to not be rewritten if there is a pre-existing route set on the dialog. This is now accomplished by checking the dialog's route set list instead of checking if the route set is frozen. Doing this causes some broken tests to begin passing again. ASTERISK-25196 Reported by Mark Michelson Change-Id: I525ab251fd40a52ede327a52a2810a56deb0529e	10 years ago
Mark Michelson	028fa54620	res_pjsip_nat: Rewrite route set when required. When performing some provider testing, the rewrite_contact option was interfering with proper construction of a route set when sending an ACK after receiving a 200 OK response to an INVITE. The initial INVITE was sent to address sip:foo. The 200 OK had a Contact header with URI sip:bar. In addition, the 200 OK had Record-Route headers for sip:baz and sip:foo, in that order. Since the Record-Route headers had the lr parameter, the result should have been: * Set R-URI of the ACK to sip:bar. * Add Route headers for sip:foo and sip:baz, in that order. However, the rewrite_contact option resulted in our rewriting the Contact header on the 200 OK to sip:foo. The result was: * R-URI remained sip:foo. * We added Route headers for sip:foo and sip:baz, in that order. The result was that sip:bar was not indicated in the ACK at all, so the far end never received our ACK. The call eventually dropped. The intention of rewrite_contact is to rewrite the most immediate destination of our SIP request to be the same address on which we received a request or response. In the case of processing a SIP response with Record-Route headers, this means that instead of rewriting the Contact header, we should instead rewrite the bottom-most Record-Route header. In the case of processing a SIP request with Record-Route headers, this means we rewrite the top-most Record-route header. Like when we rewrite the Contact header, we also ensure to update the dialog's route set if it exists. ASTERISK-25196 #close Reported by Mark Michelson Change-Id: I9702157c3603a2d0bd8a8215ac27564d366b666f	10 years ago
Richard Mudgett	6ca98524bf	Audit ast_pjsip_rdata_get_endpoint() usage for ref leaks. Valgrind found some memory leaks associated with ast_pjsip_rdata_get_endpoint(). The leaks would manifest when sending responses to OPTIONS requests, processing MESSAGE requests, and res_pjsip supplements implementing the incoming_request callback. * Fix ast_pjsip_rdata_get_endpoint() endpoint ref leaks in res/res_pjsip.c:supplement_on_rx_request(), res/res_pjsip/pjsip_options.c:send_options_response(), res/res_pjsip_messaging.c:rx_data_to_ast_msg(), and res/res_pjsip_messaging.c:send_response(). * Eliminated RAII_VAR() use with ast_pjsip_rdata_get_endpoint() in res/res_pjsip_nat.c:nat_on_rx_message(). * Fixed inconsistent but benign return value in res/res_pjsip/pjsip_options.c:options_on_rx_request(). Review: https://reviewboard.asterisk.org/r/4511/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433222 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Matthew Jordan	1995baad71	ARI/PJSIP: Add the ability to redirect (transfer) a channel in a Stasis app This patch adds a new feature to ARI to redirect a channel to another server, and fixes a few bugs in PJSIP's handling of the Transfer dialplan application/ARI redirect capability. New Feature A new operation has been added to the ARI channels resource, redirect. With this, a channel in a Stasis application can be redirected to another endpoint of the same underlying channel technology. Bug fixes In the process of writing this new feature, two bugs were fixed in the PJSIP stack: (1) The existing .transfer channel callback had the limitation that it could only transfer channels to a SIP URI, i.e., you had to pass 'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is still supported, it is somewhat unintuitive - particularly in a world full of endpoints. As such, we now also support specifying the PJSIP endpoint to transfer to. (2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by updating its Contact header. Alas, that resulted in the forwarding destination set by the dialplan application/ARI resource/whatever being rewritten with very incorrect information. Hence, we now don't bother updating an outgoing response if it is a 302. Since this took a looong time to find, some additional debug statements have been added to those modules that update the Contact headers. Review: https://reviewboard.asterisk.org/r/4316/ ASTERISK-24015 #close Reported by: Private Name ASTERISK-24703 #close Reported by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431717 65c4cc65-6c06-0410-ace0-fbb531ad65f3	10 years ago
Kinsey Moore	289830cdc6	PJSIP: Enforce module load dependencies This enforces that res_pjsip, res_pjsip_session, and res_pjsip_pubsub have loaded properly before attempting to load any modules that depend on them since the module loader system is not currently capable of resolving module dependencies on its own. ASTERISK-24312 #close Reported by: Dafi Ni Review: https://reviewboard.asterisk.org/r/4062/ ........ Merged revisions 425690 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425691 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Joshua Colp	494bb9f931	res_pjsip_nat: Place source port into rport of responses if 'force_rport' is on. When the 'force_rport' option is enabled the behavior should be the same as if the remote side placed rport into the message themselves. Therefore any responses we send should include the source port of the request in the rport of the Via header. #SIPit31 ASTERISK-24387 #close Reported by: Matt Jordan ........ Merged revisions 425131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425132 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	ac095304e6	PJSIP: Force transport on contact rewrite If contact rewriting is enabled but the contact differs in transport from what is actually being used, messages after the initial INVITE transaction can be sent to an incorrect transport/port combination. In the case where this bug occurred the remote party never received a BYE since it was sent to the remote party's TCP port over UDP. Review: https://reviewboard.asterisk.org/r/4032/ ........ Merged revisions 424244 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424245 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	dcf1ad14da	Add module support level to ast_module_info structure. Print it in CLI "module show" . ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Kinsey Moore	d5431ed358	PJSIP: Fix address for ACK in NAT situations In NAT scenarios where a call is placed to a Grandstream phone, res_pjsip will sometimes send the ACK to a 200 OK to the private address of the device behind the NAT instead of the address of the NAT device. This corrects that behavior by rewriting the address in the Contact header in the incoming 200 OK and the dialog's target address if necessary (since it has already been rewritten to the incorrect private address). (closes issue ASTERISK-23106) Review: https://reviewboard.asterisk.org/r/3168/ Reported by: Matt Jordan ........ Merged revisions 407000 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407001 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
Joshua Colp	f89ab79862	res_pjsip_nat: Don't assume a Contact header will always contain a URI. If the 'rewrite_contact' option was enabled and a Contact header was received which contained a '' a crash would occur. This change makes the res_pjsip_nat module ignore the Contact header if it contains only a ''. (closes issue ASTERISK-23101) Reported by: Matt Jordan ........ Merged revisions 405019 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405020 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	4d760694b2	res_pjsip_nat: Add NAT module to session dialogs. Due to the way pjproject internally works it was possible for the NAT module to not be invoked on messages with-in a session dialog. This means that the various parts of the message would not get rewritten with the source IP address and port. This change uses a session supplement to add the NAT module to the dialog on the first incoming or outgoing INVITE. (closes issue ASTERISK-22941) Reported by: Leif Madsen ........ Merged revisions 403510 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403511 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

13 Commits (ca65ddcd199dca4681055b51fc63b906e48f1950)