Hello,
(Sorry for re-posting this here from sr-users; in retrospect, it seemed more appropriate to do so.)
I recently encountered SDP attributes that look like this:
Media Attribute (a): alt:1 3 : njfxofkg bavpjfxg 192.168.2.59 41978 Media Attribute (a): alt:2 2 : fpukfyaj dqmiarjx 192.168.111.1 41978 Media Attribute (a): alt:3 1 : euvrwenk jctmhavh 192.168.238.1 41978
I was not familiar with these. However, RFC 4796 says:
alt: the media stream is taken from the alternative source. A typical use case for this is an event where the ambient sound is separated from the main sound. The alternative audio stream could be, for example, the sound of a jungle. Another example is the video of a conference room, while the main stream carries the video of the speaker. This is similar to the 'live' role in H.239.
RFC 6064 http://tools.ietf.org/html/rfc6064#section-4.4 speaks to this a little as well.
This does not really make any clearer to me what these mean in this scenario, and unfortunately I cannot find out from the user.
My question is: I assume that rtpengine (both Kamailio and daemon-side) does not support this, correct? Are there any plans to in the future? Can anyone with more experience with video, perhaps, give some insight into the meaning and application of this attribute?
Thanks!
-- Alex
On 10/02/14 02:32, Alex Balashov wrote:
Hello,
(Sorry for re-posting this here from sr-users; in retrospect, it seemed more appropriate to do so.)
I recently encountered SDP attributes that look like this:
Media Attribute (a): alt:1 3 : njfxofkg bavpjfxg 192.168.2.59 41978 Media Attribute (a): alt:2 2 : fpukfyaj dqmiarjx 192.168.111.1 41978 Media Attribute (a): alt:3 1 : euvrwenk jctmhavh 192.168.238.1 41978
I was not familiar with these. However, RFC 4796 says:
alt: the media stream is taken from the alternative source. A typical use case for this is an event where the ambient sound is separated from the main sound. The alternative audio stream could be, for example, the sound of a jungle. Another example is the video of a conference room, while the main stream carries the video of the speaker. This is similar to the 'live' role in H.239.
RFC 6064 http://tools.ietf.org/html/rfc6064#section-4.4 speaks to this a little as well.
This does not really make any clearer to me what these mean in this scenario, and unfortunately I cannot find out from the user.
My question is: I assume that rtpengine (both Kamailio and daemon-side) does not support this, correct? Are there any plans to in the future? Can anyone with more experience with video, perhaps, give some insight into the meaning and application of this attribute?
I didn't reply originally because I don't have much insight to offer, other than that rtpengine doesn't support this at all and that RFC 4796 talks about an "a=content" attribute, not "a=alt". Older versions of the ANAT RFC [1] talk about this attribute, but the final RFC [2] doesn't.
cheers
[1] https://tools.ietf.org/html/draft-ietf-mmusic-anat-02 [2] http://tools.ietf.org/html/rfc4091
On 10/02/2014 09:16 AM, Richard Fuchs wrote:
I didn't reply originally because I don't have much insight to offer, other than that rtpengine doesn't support this at all and that RFC 4796 talks about an "a=content" attribute, not "a=alt". Older versions of the ANAT RFC [1] talk about this attribute, but the final RFC [2] doesn't.
No worries, Richard. Thank you for your reply.
-
Alex Balashov -
Richard Fuchs