Hi Anthony and team I have a situation where the timestamp in a RTP stream generated by FS jumps backwards. Version 1.2.22. It seems the cause of this is that media from the A leg starts late. So in the meantime we start generating media on the B leg with our own timestamp. Then media starts arriving on the A leg so we relay it and we start using that timestamp instead of our own. FS sets the marker bit when this happens but I'm not sure this makes it OK to turn back the timestamp. I think we should actually be using a new SSRC. Any thoughts? (happy to raise a Jira ticket and verify in master). Richard -- Richard Brady M: +44 (0)7771 623 348 T: +44 (0)20 8144 8160 E: rnbrady@gmail.com
There is actually a setting to force new SSRC in a condition like that. Internally it's called RTP_BUG_CHANGE_SSRC_ON_MARKER. If I remember correctly it should be set in the sofia profile config: <param name="auto-rtp-bugs" data="CHANGE_SSRC_ON_MARKER"/> Try that out and see if it helps. /Peter 2014-03-28 11:37 GMT+01:00 Richard Brady <rnbrady@gmail.com>:
Hi Anthony and team
I have a situation where the timestamp in a RTP stream generated by FS jumps backwards. Version 1.2.22.
It seems the cause of this is that media from the A leg starts late. So in the meantime we start generating media on the B leg with our own timestamp.
Then media starts arriving on the A leg so we relay it and we start using that timestamp instead of our own.
FS sets the marker bit when this happens but I'm not sure this makes it OK to turn back the timestamp. I think we should actually be using a new SSRC.
Any thoughts? (happy to raise a Jira ticket and verify in master).
Richard
-- Richard Brady M: +44 (0)7771 623 348 T: +44 (0)20 8144 8160 E: rnbrady@gmail.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks Peter That's really useful. I opted for rtp-rewrite-timestamps but had missed that one and will try it next if I don't see an improvement. There's also RTP_BUG_SEND_LINEAR_TIMESTAMPS. I'm quite confident I can work around the issue but would like to make sure that if there is an RFC non-compliance in default FS we get it resolved for the benefit of others. My understanding: The marker bit makes it ok to jump the timestamp for silence suppression / discontinuous transmission etc. BUT the marker bit doesn't make it ok to change the timestamp SOURCE (and jump the timestamp backwards for example). In that case the SSRC MUST change too. Regards, Richard On 28 March 2014 11:08, Peter Olsson <peter@olssononline.se> wrote:
There is actually a setting to force new SSRC in a condition like that.
Internally it's called RTP_BUG_CHANGE_SSRC_ON_MARKER. If I remember correctly it should be set in the sofia profile config:
<param name="auto-rtp-bugs" data="CHANGE_SSRC_ON_MARKER"/>
Try that out and see if it helps.
/Peter
2014-03-28 11:37 GMT+01:00 Richard Brady <rnbrady@gmail.com>:
Hi Anthony and team
I have a situation where the timestamp in a RTP stream generated by FS jumps backwards. Version 1.2.22.
It seems the cause of this is that media from the A leg starts late. So in the meantime we start generating media on the B leg with our own timestamp.
Then media starts arriving on the A leg so we relay it and we start using that timestamp instead of our own.
FS sets the marker bit when this happens but I'm not sure this makes it OK to turn back the timestamp. I think we should actually be using a new SSRC.
Any thoughts? (happy to raise a Jira ticket and verify in master).
Richard
-- Richard Brady M: +44 (0)7771 623 348 T: +44 (0)20 8144 8160 E: rnbrady@gmail.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I believe that setting was the other way around in my original patch (to use this by default). However, even if it sounds like it should be more compliant, it caused problems with some devices - that's why it ended up like this. It was some time ago - so I don't remember every detail though. 2014-03-28 13:39 GMT+01:00 Richard Brady <rnbrady@gmail.com>:
Thanks Peter
That's really useful. I opted for rtp-rewrite-timestamps but had missed that one and will try it next if I don't see an improvement. There's also RTP_BUG_SEND_LINEAR_TIMESTAMPS.
I'm quite confident I can work around the issue but would like to make sure that if there is an RFC non-compliance in default FS we get it resolved for the benefit of others.
My understanding:
The marker bit makes it ok to jump the timestamp for silence suppression / discontinuous transmission etc.
BUT the marker bit doesn't make it ok to change the timestamp SOURCE (and jump the timestamp backwards for example). In that case the SSRC MUST change too.
Regards, Richard
On 28 March 2014 11:08, Peter Olsson <peter@olssononline.se> wrote:
There is actually a setting to force new SSRC in a condition like that.
Internally it's called RTP_BUG_CHANGE_SSRC_ON_MARKER. If I remember correctly it should be set in the sofia profile config:
<param name="auto-rtp-bugs" data="CHANGE_SSRC_ON_MARKER"/>
Try that out and see if it helps.
/Peter
2014-03-28 11:37 GMT+01:00 Richard Brady <rnbrady@gmail.com>:
Hi Anthony and team
I have a situation where the timestamp in a RTP stream generated by FS jumps backwards. Version 1.2.22.
It seems the cause of this is that media from the A leg starts late. So in the meantime we start generating media on the B leg with our own timestamp.
Then media starts arriving on the A leg so we relay it and we start using that timestamp instead of our own.
FS sets the marker bit when this happens but I'm not sure this makes it OK to turn back the timestamp. I think we should actually be using a new SSRC.
Any thoughts? (happy to raise a Jira ticket and verify in master).
Richard
-- Richard Brady M: +44 (0)7771 623 348 T: +44 (0)20 8144 8160 E: rnbrady@gmail.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Do you mean the CHANGE_SSRC_ON_MARKER setting? I don't think that's the way to address it. Marker aside, I'd like the SSRC to change when switching from locally generated to relayed media, but I guess that would also cause the "problems with some devices" of which you speak. If you mean rtp-rewrite-timestamps then I'm divided. What I can't work out is why the SSRC isn't changing when the source changes. My reading of the code says it should be. Richard On 28 March 2014 13:11, Peter Olsson <peter@olssononline.se> wrote:
I believe that setting was the other way around in my original patch (to use this by default). However, even if it sounds like it should be more compliant, it caused problems with some devices - that's why it ended up like this. It was some time ago - so I don't remember every detail though.
2014-03-28 13:39 GMT+01:00 Richard Brady <rnbrady@gmail.com>:
Thanks Peter
That's really useful. I opted for rtp-rewrite-timestamps but had missed that one and will try it next if I don't see an improvement. There's also RTP_BUG_SEND_LINEAR_TIMESTAMPS.
I'm quite confident I can work around the issue but would like to make sure that if there is an RFC non-compliance in default FS we get it resolved for the benefit of others.
My understanding:
The marker bit makes it ok to jump the timestamp for silence suppression / discontinuous transmission etc.
BUT the marker bit doesn't make it ok to change the timestamp SOURCE (and jump the timestamp backwards for example). In that case the SSRC MUST change too.
Regards, Richard
On 28 March 2014 11:08, Peter Olsson <peter@olssononline.se> wrote:
There is actually a setting to force new SSRC in a condition like that.
Internally it's called RTP_BUG_CHANGE_SSRC_ON_MARKER. If I remember correctly it should be set in the sofia profile config:
<param name="auto-rtp-bugs" data="CHANGE_SSRC_ON_MARKER"/>
Try that out and see if it helps.
/Peter
2014-03-28 11:37 GMT+01:00 Richard Brady <rnbrady@gmail.com>:
Hi Anthony and team
I have a situation where the timestamp in a RTP stream generated by FS jumps backwards. Version 1.2.22.
It seems the cause of this is that media from the A leg starts late. So in the meantime we start generating media on the B leg with our own timestamp.
Then media starts arriving on the A leg so we relay it and we start using that timestamp instead of our own.
FS sets the marker bit when this happens but I'm not sure this makes it OK to turn back the timestamp. I think we should actually be using a new SSRC.
Any thoughts? (happy to raise a Jira ticket and verify in master).
Richard
-- Richard Brady M: +44 (0)7771 623 348 T: +44 (0)20 8144 8160 E: rnbrady@gmail.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Ok, I understand this better having looked at the commits. The RFC behaviour should to change the SSRC value when the synchronisation source changes, i.e. change the SSRC when the SSRC changes. There is no way to configure FS to behave this way. Richard
We don't pass through ssrc from streams over a bridge. We do pass the timestamps to preserve jitter. If you have a device that has a problem with this then you can use the params you identified to solve it. On Mar 29, 2014 10:24 AM, "Richard Brady" <rnbrady@gmail.com> wrote:
Ok, I understand this better having looked at the commits.
The RFC behaviour should to change the SSRC value when the synchronisation source changes, i.e. change the SSRC when the SSRC changes.
There is no way to configure FS to behave this way.
Richard
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks. Have done. On 5 April 2014 20:15, Anthony Minessale <anthony.minessale@gmail.com>wrote:
We don't pass through ssrc from streams over a bridge. We do pass the timestamps to preserve jitter. If you have a device that has a problem with this then you can use the params you identified to solve it. On Mar 29, 2014 10:24 AM, "Richard Brady" <rnbrady@gmail.com> wrote:
Ok, I understand this better having looked at the commits.
The RFC behaviour should to change the SSRC value when the synchronisation source changes, i.e. change the SSRC when the SSRC changes.
There is no way to configure FS to behave this way.
Richard
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
Anthony Minessale
-
Peter Olsson
-
Richard Brady