Various improvements #2
Conversation
| @@ -57,24 +57,24 @@ | |||
| "lineNum": "6", | |||
| "indent": "1", | |||
| "section": "Audio Lines", | |||
| "lineText": "m=audio 58779 UDP\/TLS\/RTP\/SAVPF 111 103 104 9 0 8 106 105 13 126", | |||
| "description": "<p><em>m<\/em> means it is a media line – it condenses a lot of information on the media attributes of the stream. In this order, it tells us:<ul><li><em>audio<\/em>- the media type is going to be used for the session (media types are registered at the IANA),<\/li><li><em>54278<\/em><span – the port is going to be used for SRTP (and for RTCP if RTCP multiplex is supported by the other peer),<\/li><li><em>RTP\/SAVPF<\/em>- the transport protocol is going to be used for the session, and last but not least<\/li><li><em>111 103 104 0 8 106 105 13 126<\/em>- the media format descriptions are supported by the browser to send and receive media.<\/li><\/ul>RTP\/SAVPF is defined in <a href=\"http:\/\/tools.ietf.org\/html\/rfc5124\">RFC5124<\/a>. In short it requires the use of SRTP and SRTCP and RTCP Feedback packets.<\/p><p>The media format descriptions, with protocol RTP\/SAVPF, gives the RTP payload numbers which are going to be used for the different formats. Payload numbers lower than 96 are mapped to encodingformats by the<a href=\"http:\/\/www.iana.org\/assignments\/rtp-parameters\/rtp-parameters.xhtml\">IANA<\/a>. In our SDP<em>0<\/em>maps to G711U and<em>8<\/em>to G711A. Format numbers larger than 95 are dynamic and there are <em>a=rtpmap:<\/em> attribute to map from the RTP payload type numbers to media encoding names. There are also<em>a=fmtp:<\/em> attributes which specify format parameters<\/p>" | |||
| "lineText": "m=audio 9 RTP\/SAVPF 111 103 104 9 0 8 106 105 13 126", | |||
There was a problem hiding this comment.
RTP/SAVPF has been deprecated so this should not be shown.
The port 58779 is still updated if you look at the SDP while the session is running. As long as it is replaced consistently in the various places it impacts (as done below) i'm ok with changing that.
| "lineText": "c=IN IP4 217.130.243.155", | ||
| "description": "<em>c<\/em> is a connection line. This line gives the IP from where you expect to send and receive the real time traffic. As ICE is mandatory in WebRTC the IP in the c-line is not going to be used." | ||
| "lineText": "c=IN IP4 0.0.0.0", | ||
| "description": "<em>c<\/em> is a connection line. This line gives the IP from where you expect to send and receive the real time traffic. As ICE is mandatory in WebRTC the IP in the c-line is not going to be used. Firefox and Chrome both send 0.0.0.0" |
There was a problem hiding this comment.
... initially and then update the field with the best candidate.
(or something like that)
There was a problem hiding this comment.
Yes, I think you are right, if ICE candidates have been already gathered then the SDP will contain in the 'c' line the port of the best candidate (it will be a host UDP candidate), so to be coherent with the SDP (ehich contains candidates) this IP should have a value.
I guess we could explain this to give more information, before getting any candidate the value of the IP will be '0.0.0.0' so it can be helpful for the reader.
| }, | ||
| { | ||
| "display": "line", | ||
| "lineNum": "8", | ||
| "indent": "1", | ||
| "section": "Audio Lines", | ||
| "lineText": "a=rtcp:51472 IN IP4 217.130.243.155", | ||
| "description": "This line explicitly specifies the IP and port that will used for RTCP, not derived from the base media port. Note that is the same port as for SRTP as RTCP multiplex is supported." | ||
| "lineText": "a=rtcp:9 IN IP4 0.0.0.0", |
There was a problem hiding this comment.
yes, while there are not ICE candidates some valid values must be given to the port and the IP in the "rtcp" line, so '9' and '0.0.0.0' are the 'default' values. It would be also a good thing to add this to the explanation.
| @@ -387,8 +387,8 @@ | |||
| "lineNum": "42", | |||
| "indent": "1", | |||
| "section": "Video Lines", | |||
| "lineText": "m=video 60372 UDP\/TLS\/RTP\/SAVPF 100 101 116 117 96", | |||
| "description": "<p><em>m<\/em> means it is a media line – it condenses a lot of information on the media attributes of the stream. In this order, it tells us:<ul><li><em>audio<\/em>- the media type is going to be used for the session (media types are registered at the IANA),<\/li><li><em>54278<\/em><span – the port is going to be used for SRTP (and for RTCP if RTCP multiplex is supported by the other peer),<\/li><li><em>RTP\/SAVPF<\/em>- the transport protocol is going to be used for the session, and last but not least<\/li><li><em>100 101 116 117 96<\/em> - the media format descriptions are supported by the browser to send and receive media.<\/li><\/ul>RTP\/SAVPF is defined in <a href=\"http:\/\/tools.ietf.org\/html\/rfc5124\">RFC5124<\/a>. In short it requires the use of SRTP and SRTCP and RTCP Feedback packets.<\/p><p>The media format descriptions, with protocol RTP\/SAVPF, gives the RTP payload numbers which are going to be used for the different formats. Payload numbers lower than 96 are mapped to encodingformats by the<a href=\"http:\/\/www.iana.org\/assignments\/rtp-parameters\/rtp-parameters.xhtml\">IANA<\/a>. In our SDP<em>0<\/em>maps to G711U and<em>8<\/em>to G711A. Format numbers larger than 95 are dynamic and there are <em>a=rtpmap:<\/em> attribute to map from the RTP payload type numbers to media encoding names. There are also<em>a=fmtp:<\/em> attributes which specify format parameters<\/p>" | |||
| "lineText": "m=video 9 RTP\/SAVPF 100 101 116 117 96", | |||
|
Feel free to edit or modify the patch prior to inclusion |
|
@fippo - what do you want to do here? Is it quick enough for you to merge this? I can attempt it, but I would likely need you to review it again. |
|
or perhaps @antonroman can help with the merge? |
No description provided.