aboutsummaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authormmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b>2009-05-28 15:34:48 +0000
committermmichelson <mmichelson@f38db490-d61c-443f-a65b-d21fe96a405b>2009-05-28 15:34:48 +0000
commit2106d0145e3fe6ac8e52f0f188b3825a29f39ca0 (patch)
treeee5ec5a2ac5daa2f3f8e682b624eaf2d9796abef /include
parent5a15374cdf58709ce01443e622d2403171da7700 (diff)
Merged revisions 197606 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk ................ r197606 | mmichelson | 2009-05-28 10:32:19 -0500 (Thu, 28 May 2009) | 22 lines Recorded merge of revisions 197588 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r197588 | mmichelson | 2009-05-28 10:27:49 -0500 (Thu, 28 May 2009) | 16 lines Allow for media to arrive from an alternate source when responding to a reinvite with 491. When we receive a SIP reinvite, it is possible that we may not be able to process the reinvite immediately since we have also sent a reinvite out ourselves. The problem is that whoever sent us the reinvite may have also sent a reinvite out to another party, and that reinvite may have succeeded. As a result, even though we are not going to accept the reinvite we just received, it is important for us to not have problems if we suddenly start receiving RTP from a new source. The fix for this is to grab the media source information from the SDP of the reinvite that we receive. This information is passed to the RTP layer so that it will know about the alternate source for media. Review: https://reviewboard.asterisk.org/r/252 ........ ................ git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.6.0@197615 f38db490-d61c-443f-a65b-d21fe96a405b
Diffstat (limited to 'include')
-rw-r--r--include/asterisk/rtp.h17
1 files changed, 17 insertions, 0 deletions
diff --git a/include/asterisk/rtp.h b/include/asterisk/rtp.h
index 5a857f016..98b6b1ffc 100644
--- a/include/asterisk/rtp.h
+++ b/include/asterisk/rtp.h
@@ -133,6 +133,23 @@ struct ast_rtp *ast_rtp_new_with_bindaddr(struct sched_context *sched, struct io
void ast_rtp_set_peer(struct ast_rtp *rtp, struct sockaddr_in *them);
+/*!
+ * \since 1.4.26
+ * \brief set potential alternate source for RTP media
+ *
+ * This function may be used to give the RTP stack a hint that there is a potential
+ * second source of media. One case where this is used is when the SIP stack receives
+ * a REINVITE to which it will be replying with a 491. In such a scenario, the IP and
+ * port information in the SDP of that REINVITE lets us know that we may receive media
+ * from that source/those sources even though the SIP transaction was unable to be completed
+ * successfully
+ *
+ * \param rtp The RTP structure we wish to set up an alternate host/port on
+ * \param alt The address information for the alternate media source
+ * \retval void
+ */
+void ast_rtp_set_alt_peer(struct ast_rtp *rtp, struct sockaddr_in *alt);
+
/* Copies from rtp to them and returns 1 if there was a change or 0 if it was already the same */
int ast_rtp_get_peer(struct ast_rtp *rtp, struct sockaddr_in *them);