| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
"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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
