Posted: Tue May 19, 2009 7:14 pm Post subject: [asterisk-dev] [Code Review] Add ability to set an alternate
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/
-----------------------------------------------------------
This patch implements a way to let the RTP stack know that there may be a potential alternate source for media. The alterations to RTP are:
* new function ast_rtp_set_altpeer to set what the alternate media source may be.
* new sockaddr_in structures inside the ast_rtp and ast_rtcp structures to hold these alternate sources.
* ast_rtp_read and ast_rtcp_read have been updated to expect media from these alternate sources.
The alterations to chan_sip are:
* new function get_ip_and_port_from_sdp to get the remote IP address and port for audio/video streams from the SDP
* When we are going to respond to a REINVITE with a 491, we call get_ip_and_port_from_sdp, followed by ast_rtp_set_altpeer so that the
RTP stack will not react incorrectly when it receives media from this alternate source.
Please see the "Testing Done" section for some code review details.
I tested by setting up phones and Asterisk boxes as shown in the first diagram in the link I printed in the "Description."
I found that in REINVITE glare situations, I always successfully had two-way audio. There was a slight catch, though. Usually there would be about a 0.5-1 second gap between when the callee answered the phone and when the caller was able to hear the callee's audio. I have not yet been able to track this odd behavior down. So, in addition to making sure that what I have presented here looks reasonable, if any reviewers might be able to point out what potentially is causing the short delay upon answering the calls, please speak up.
Thanks,
Mark
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Tue May 19, 2009 8:13 pm Post subject: [asterisk-dev] [Code Review] Add ability to set an alternate
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/#review786
-----------------------------------------------------------
I believe I may know where the small audio delay that I experienced is coming from. It happens because Asterisk B will wait between 0.1 and 2 seconds to re-send its REINVITE to A, and A will wait between 2.1 and 4 seconds to re-send its REINVITE to B if the REINVITEs had "glared" earlier. It is likely this gap between retransmission of REINVITEs where audio is not heard.
- Mark
On 2009-05-19 15:00:31, Mark Michelson wrote:
Quote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/
-----------------------------------------------------------
This patch implements a way to let the RTP stack know that there may be a potential alternate source for media. The alterations to RTP are:
* new function ast_rtp_set_altpeer to set what the alternate media source may be.
* new sockaddr_in structures inside the ast_rtp and ast_rtcp structures to hold these alternate sources.
* ast_rtp_read and ast_rtcp_read have been updated to expect media from these alternate sources.
The alterations to chan_sip are:
* new function get_ip_and_port_from_sdp to get the remote IP address and port for audio/video streams from the SDP
* When we are going to respond to a REINVITE with a 491, we call get_ip_and_port_from_sdp, followed by ast_rtp_set_altpeer so that the
RTP stack will not react incorrectly when it receives media from this alternate source.
Please see the "Testing Done" section for some code review details.
I tested by setting up phones and Asterisk boxes as shown in the first diagram in the link I printed in the "Description."
I found that in REINVITE glare situations, I always successfully had two-way audio. There was a slight catch, though. Usually there would be about a 0.5-1 second gap between when the callee answered the phone and when the caller was able to hear the callee's audio. I have not yet been able to track this odd behavior down. So, in addition to making sure that what I have presented here looks reasonable, if any reviewers might be able to point out what potentially is causing the short delay upon answering the calls, please speak up.
Thanks,
Mark
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Tue May 19, 2009 11:37 pm Post subject: [asterisk-dev] [Code Review] Add ability to set an alternate
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/#review787
-----------------------------------------------------------
If i remember correctly there is an SDP to attribute specify rctp port port explicitly.
So it would be wise to add an rtcpport parametr to this function and not simply assume that is is rtpport + 1
- vadim
On 2009-05-19 15:00:31, Mark Michelson wrote:
Quote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/
-----------------------------------------------------------
This patch implements a way to let the RTP stack know that there may be a potential alternate source for media. The alterations to RTP are:
* new function ast_rtp_set_altpeer to set what the alternate media source may be.
* new sockaddr_in structures inside the ast_rtp and ast_rtcp structures to hold these alternate sources.
* ast_rtp_read and ast_rtcp_read have been updated to expect media from these alternate sources.
The alterations to chan_sip are:
* new function get_ip_and_port_from_sdp to get the remote IP address and port for audio/video streams from the SDP
* When we are going to respond to a REINVITE with a 491, we call get_ip_and_port_from_sdp, followed by ast_rtp_set_altpeer so that the
RTP stack will not react incorrectly when it receives media from this alternate source.
Please see the "Testing Done" section for some code review details.
I tested by setting up phones and Asterisk boxes as shown in the first diagram in the link I printed in the "Description."
I found that in REINVITE glare situations, I always successfully had two-way audio. There was a slight catch, though. Usually there would be about a 0.5-1 second gap between when the callee answered the phone and when the caller was able to hear the callee's audio. I have not yet been able to track this odd behavior down. So, in addition to making sure that what I have presented here looks reasonable, if any reviewers might be able to point out what potentially is causing the short delay upon answering the calls, please speak up.
Thanks,
Mark
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Wed May 20, 2009 2:46 pm Post subject: [asterisk-dev] [Code Review] Add ability to set an alternate
Quote:
On 2009-05-19 19:26:45, vadim wrote:
> /branches/1.4/main/rtp.c, line 2070
> <http://reviewboard.digium.com/r/252/diff/1/?file=5273#file5273line2070>
>
> If i remember correctly there is an SDP to attribute specify rctp port port explicitly.
> So it would be wise to add an rtcpport parametr to this function and not simply assume that is is rtpport + 1
>
>
I believe you are referring to RFC 3605. After looking at that document, not only can the RTCP port be specified in an a=rtcp line, but also a separate IP address may be specified for RTCP. You are correct, we should be looking for this attribute line in an SDP in case RTCP should be sent to a separate destination.
However, I have never seen this attribute used before, and this isn't the main focus of this patch. If we want to add support for parsing rtcp attribute lines in an SDP, I think it should be done as a separate patch. For now, I am simply copying the logic used currently when parsing an SDP.
Quote:
On 2009-05-19 19:26:45, vadim wrote:
> /branches/1.4/channels/chan_sip.c, line 5118
> <http://reviewboard.digium.com/r/252/diff/1/?file=5271#file5271line5118>
>
> I think
> int get_ip_and_port_from_sdp(struct sip_request *req, const enum media_type media, struct sockaddr_in *sin);
>
> Will be more efficient
I will make that change.
- Mark
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/#review787
-----------------------------------------------------------
On 2009-05-19 15:00:31, Mark Michelson wrote:
Quote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/
-----------------------------------------------------------
This patch implements a way to let the RTP stack know that there may be a potential alternate source for media. The alterations to RTP are:
* new function ast_rtp_set_altpeer to set what the alternate media source may be.
* new sockaddr_in structures inside the ast_rtp and ast_rtcp structures to hold these alternate sources.
* ast_rtp_read and ast_rtcp_read have been updated to expect media from these alternate sources.
The alterations to chan_sip are:
* new function get_ip_and_port_from_sdp to get the remote IP address and port for audio/video streams from the SDP
* When we are going to respond to a REINVITE with a 491, we call get_ip_and_port_from_sdp, followed by ast_rtp_set_altpeer so that the
RTP stack will not react incorrectly when it receives media from this alternate source.
Please see the "Testing Done" section for some code review details.
I tested by setting up phones and Asterisk boxes as shown in the first diagram in the link I printed in the "Description."
I found that in REINVITE glare situations, I always successfully had two-way audio. There was a slight catch, though. Usually there would be about a 0.5-1 second gap between when the callee answered the phone and when the caller was able to hear the callee's audio. I have not yet been able to track this odd behavior down. So, in addition to making sure that what I have presented here looks reasonable, if any reviewers might be able to point out what potentially is causing the short delay upon answering the calls, please speak up.
Thanks,
Mark
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Wed May 20, 2009 3:00 pm Post subject: [asterisk-dev] [Code Review] Add ability to set an alternate
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/
-----------------------------------------------------------
(Updated 2009-05-20 10:48:41.110501)
Review request for Asterisk Developers.
Changes
-------
Addressed Vadim's idea regarding the efficiency of get_ip_and_port_from_sdp. Re-tested and found that everything still appears to be working.
This patch implements a way to let the RTP stack know that there may be a potential alternate source for media. The alterations to RTP are:
* new function ast_rtp_set_altpeer to set what the alternate media source may be.
* new sockaddr_in structures inside the ast_rtp and ast_rtcp structures to hold these alternate sources.
* ast_rtp_read and ast_rtcp_read have been updated to expect media from these alternate sources.
The alterations to chan_sip are:
* new function get_ip_and_port_from_sdp to get the remote IP address and port for audio/video streams from the SDP
* When we are going to respond to a REINVITE with a 491, we call get_ip_and_port_from_sdp, followed by ast_rtp_set_altpeer so that the
RTP stack will not react incorrectly when it receives media from this alternate source.
Please see the "Testing Done" section for some code review details.
I tested by setting up phones and Asterisk boxes as shown in the first diagram in the link I printed in the "Description."
I found that in REINVITE glare situations, I always successfully had two-way audio. There was a slight catch, though. Usually there would be about a 0.5-1 second gap between when the callee answered the phone and when the caller was able to hear the callee's audio. I have not yet been able to track this odd behavior down. So, in addition to making sure that what I have presented here looks reasonable, if any reviewers might be able to point out what potentially is causing the short delay upon answering the calls, please speak up.
Thanks,
Mark
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Fri May 22, 2009 3:43 pm Post subject: [asterisk-dev] [Code Review] Add ability to set an alternate
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/#review792
-----------------------------------------------------------
Ship it!
I think vadim's point about another parameter for RTCP is something still good to consider for the sake of API stability. It is reasonable to assume that we may need that parameter in the future, so it wouldn't hurt to have it there.
However, I would only worry about it for the trunk version of the patch, if at all.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/
-----------------------------------------------------------
This patch implements a way to let the RTP stack know that there may be a potential alternate source for media. The alterations to RTP are:
* new function ast_rtp_set_altpeer to set what the alternate media source may be.
* new sockaddr_in structures inside the ast_rtp and ast_rtcp structures to hold these alternate sources.
* ast_rtp_read and ast_rtcp_read have been updated to expect media from these alternate sources.
The alterations to chan_sip are:
* new function get_ip_and_port_from_sdp to get the remote IP address and port for audio/video streams from the SDP
* When we are going to respond to a REINVITE with a 491, we call get_ip_and_port_from_sdp, followed by ast_rtp_set_altpeer so that the
RTP stack will not react incorrectly when it receives media from this alternate source.
Please see the "Testing Done" section for some code review details.
I tested by setting up phones and Asterisk boxes as shown in the first diagram in the link I printed in the "Description."
I found that in REINVITE glare situations, I always successfully had two-way audio. There was a slight catch, though. Usually there would be about a 0.5-1 second gap between when the callee answered the phone and when the caller was able to hear the callee's audio. I have not yet been able to track this odd behavior down. So, in addition to making sure that what I have presented here looks reasonable, if any reviewers might be able to point out what potentially is causing the short delay upon answering the calls, please speak up.
Thanks,
Mark
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Fri May 22, 2009 3:49 pm Post subject: [asterisk-dev] [Code Review] Add ability to set an alternate
Quote:
On 2009-05-22 11:31:50, Russell Bryant wrote:
> /branches/1.4/include/asterisk/rtp.h, lines 130-143
> <http://reviewboard.digium.com/r/252/diff/2/?file=5275#file5275line130>
>
> Add \since 1.6.3 to the docs here
Hmm, the plan was to add this to all branches, not just trunk. In fact, this review request was made against 1.4.
Would \since 1.4.26 make more sense?
- Mark
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/#review792
-----------------------------------------------------------
On 2009-05-20 10:48:41, Mark Michelson wrote:
Quote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/
-----------------------------------------------------------
This patch implements a way to let the RTP stack know that there may be a potential alternate source for media. The alterations to RTP are:
* new function ast_rtp_set_altpeer to set what the alternate media source may be.
* new sockaddr_in structures inside the ast_rtp and ast_rtcp structures to hold these alternate sources.
* ast_rtp_read and ast_rtcp_read have been updated to expect media from these alternate sources.
The alterations to chan_sip are:
* new function get_ip_and_port_from_sdp to get the remote IP address and port for audio/video streams from the SDP
* When we are going to respond to a REINVITE with a 491, we call get_ip_and_port_from_sdp, followed by ast_rtp_set_altpeer so that the
RTP stack will not react incorrectly when it receives media from this alternate source.
Please see the "Testing Done" section for some code review details.
I tested by setting up phones and Asterisk boxes as shown in the first diagram in the link I printed in the "Description."
I found that in REINVITE glare situations, I always successfully had two-way audio. There was a slight catch, though. Usually there would be about a 0.5-1 second gap between when the callee answered the phone and when the caller was able to hear the callee's audio. I have not yet been able to track this odd behavior down. So, in addition to making sure that what I have presented here looks reasonable, if any reviewers might be able to point out what potentially is causing the short delay upon answering the calls, please speak up.
Thanks,
Mark
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Fri May 22, 2009 4:13 pm Post subject: [asterisk-dev] [Code Review] Add ability to set an alternate
Quote:
On 2009-05-22 11:31:50, Russell Bryant wrote:
> /branches/1.4/include/asterisk/rtp.h, lines 130-143
> <http://reviewboard.digium.com/r/252/diff/2/?file=5275#file5275line130>
>
> Add \since 1.6.3 to the docs here
wrote:
Hmm, the plan was to add this to all branches, not just trunk. In fact, this review request was made against 1.4.
Would \since 1.4.26 make more sense?
Yeah, \since 1.4.26, sorry about that.
- Russell
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/#review792
-----------------------------------------------------------
On 2009-05-20 10:48:41, Mark Michelson wrote:
Quote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/
-----------------------------------------------------------
This patch implements a way to let the RTP stack know that there may be a potential alternate source for media. The alterations to RTP are:
* new function ast_rtp_set_altpeer to set what the alternate media source may be.
* new sockaddr_in structures inside the ast_rtp and ast_rtcp structures to hold these alternate sources.
* ast_rtp_read and ast_rtcp_read have been updated to expect media from these alternate sources.
The alterations to chan_sip are:
* new function get_ip_and_port_from_sdp to get the remote IP address and port for audio/video streams from the SDP
* When we are going to respond to a REINVITE with a 491, we call get_ip_and_port_from_sdp, followed by ast_rtp_set_altpeer so that the
RTP stack will not react incorrectly when it receives media from this alternate source.
Please see the "Testing Done" section for some code review details.
I tested by setting up phones and Asterisk boxes as shown in the first diagram in the link I printed in the "Description."
I found that in REINVITE glare situations, I always successfully had two-way audio. There was a slight catch, though. Usually there would be about a 0.5-1 second gap between when the callee answered the phone and when the caller was able to hear the callee's audio. I have not yet been able to track this odd behavior down. So, in addition to making sure that what I have presented here looks reasonable, if any reviewers might be able to point out what potentially is causing the short delay upon answering the calls, please speak up.
Thanks,
Mark
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum