Re: [Ccrtp-devel] Multicast and TTL - Again

[Federico Montesino Pouzols]

Hi,

On Fri, September 15, 2006 3:39 pm, Tom Anwyll wrote:
>
>> Do I suppose it right that RTP packets are being
>> sent with TTL=32?
>
> Agreed. This is probably "bad form" for Internet apps.
> However, for internal networks that span multiple
> subnets, it is a programming requirement to have the
> ability to change it.
>

Sure, it is a bug in ccRTP. It's now fixed in CVS for the
next release. SetMcastTTL is now public; i've alse moved
the joinGroup and leaveGroup to the protected section so
that they can be used in specialized RTP session types.

> Agreed. I think unhiding the method is proper and
> eases programming complexity. I can confirm that using
> a SymmetricRTPSession type the TTL's were set (and
> routed) correctly, however, using a RTPSession type
> the TTL's were set incorrectly and not routed to the
> different subnets. I haven't dug into the
> ccRTP/CommonC++ code deep enough to figure out why
> this is. I suspect it's in the CommonC++ code. Any
> ideas why this might be?

Ah, I think the problem was in ccRTP. The TTL value was
set on the recv socket instead of the send socket.
This silly bug is also fixed in CVS. Now both symmetric
and non symmetric sessions should set the TTL value.

>> As an alternative to allow for setting multicast
>> parameters of the control
>> (RTCP) socket, a "getCSO" method could be added, but
>> I think the first
>> solution is tidier.
>
> IMHO (I'm not the author!), I would think a getCSO
> method is a requirement. As it stands now, multicast
> RTCP packets will not traverse multiple subnets.
> Hence, SDES info will not accompany multicast RTP
> streams outside of the local network. For my custom
> RTP player/client, this is not an issue, but I imagine
> it might cause some flakiness in "standardized" apps
> such as JMStudio, etc.

I think I don't understand the motivations for getCSO being
a requirement (provided that setMcastTTL is public). Now
you can call setMcastTTL(32) on your RTP session object,
and that will do:

inline Socket::Error
setMcastTTL(uint8 ttl)
{
   Socket::Error error = dso->setMulticast(true);
   if ( error ) return error;
   error = dso->setTimeToLive(ttl);
   if ( error ) return error;
   error = cso->setMulticast(true);
   if ( error ) return error;
   return cso->setTimeToLive(ttl);
}

So you don't have to care anymore of dso, cso,
setMulticast, etc. Am I missing something?

>
> I'm not an expert on MBone, but I thought it was a
> multicast based network topology and "the next cool
> thing". But in it's present implementation,
> ccRTP/CommonC++ will have  only limited functionality
> on it due to the multicast RTP/RTCP/TTL issue.
>

Sure, the limitations you have found do certainly render
wrong the RTP implementation of ccRTP in multicast
networks. Thanks for spotting these issues, I think the
changes just made in CVS should sort out them. Let us
know any other issue you may find or if you have other
suggestions.

And yes, the MBone and multicast in general is a cool idea.
A number of practical issues have been slowing its
deployment and use though, specially in non academic
networks.