Re: [MMUSIC] draft-holmberg-mmusic-t140-usage-data-channel-gateway considerations

[Christer Holmberg <[e-mail]>]

Hi Gunnar,
    
>    1. Keep-alive.
>    
>    In the gateway considerations section, there were a few sentences about 
>    keep-alive. It was stated that RFC 4103 does not specify any need for 
>    keep-alive. That is true, but because RFC 4103 specifies that 
>    transmission occurs only when there is text to transmit, there will be a 
>    need for keep-alive traffic in many network configurations. On the data 
>    channel side, this is implied in the WebRTC data channel, but on the RTP 
>    side, the need for keep-alive must be considered. This is mentioned in 
>    RFC 6263, where RTCP multiplexing is recommended as the preferred 
>    option. Most current RFC 4103 implementations however send keep-alive by 
>    sending the Unicode BOM character at suitable intervals, and these 
>    should be extracted and deleted by a gateway on the way from RTP to the 
>    data channel.
>    
>    Even if we have said that we cannot have all gateway considerations 
>    documented here, I suggest that a couple of words about RFC6263 
>    mentioning the possible need for keep-alive on the RTP side are inserted.
  
The text in -01 says that the gateway may have to extract keep-alives from, and MAY add keep-alives to, the RTP stream.

We can for sure reference mechanisms normally used to implement 4103 keep-alives. 

But, if you want to define *generic* recommendations/guidance regarding keep-alives on 4103 streams I think that shall be done in an update to 4103. There is nothing data channel gateway specific about that.

---
  
>    2. Sendonly, recvonly, etc
>    
>    On the RTP side, there is a possibility to express directions in SDP by 
>    the sendonly etc. attributes. I think I have seen them used in RFC 4103 
>    implementations.
>    
>    Will these attributes automatically be possible to use in the T.140 data 
>    channel? I guess not, because it is not really said that the T.140 data 
>    channel tries to be a replica of the RFC 4103 RTP transport with all its 
>    possible attributes. Some of the attributes enabled for RFC 4103 may be 
>    of application interest for the T.140 data channel application, while 
>    others are of little or no interest or irrelevant. I am afraid that we 
>    need to go through possible attributes and mention the relevant ones in 
>    a general section on attributes, and then IANA-register the use. (this 
>    relates also to the current discussion in another thread about IANA 
>    registration of attributes for data channels).  The msrp-data-channel 
>    draft has a section on sendonly etc. I suggest that we also include one.
  
The data channel itself is always bi-directional. Now, if you want to allow usage of direction attributes for T.140 data I guess we would have to define usage of them inside a 'dcsa' attribute.

Regards,

Christer