Imagine an offer SDP that has one line of "m" with codecs 8 and 101 for DMTF and marked as sendrecv:
m = audio 35904 RTP/AVP 8 101
a = rtpmap:8 PCMA/8000
a = rtpmap:101 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv
The offered SDP is answered by a SDP with one line of "m" containing codecs 8 and 120 for DTMF similarly marked as sendrecv:
m = audio 1235 RTP/AVP 8 120
a = rtpmap:8 PCMA/8000
a = rtpmap:120 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv
From RFC 3264:
For streams marked as sendrecv in the answer, the "m=" line MUST
contain at least one codec the answerer is willing to both send and
receive, from amongst those listed in the offer. The stream MAY
indicate additional media formats, not listed in the corresponding
stream in the offer, that the answerer is willing to send or
receive (of course, it will not be able to send them at this time,
since it was not listed in the offer).
Above part of the RFC3264, proves that sending a different DTMF fmtp(120 to 101) in answer SDP complies with RFC3264 since the codec 8(G711a) matches with the offer SDP.
Is it okay to say the codec exchange is completed successfully and DTMF exchange will okay or is DTMF is not expected to work at this point?
In general:
RTP payload type numbers 0-95 identify a static media encoding. E.g. payload type 8 means PCMA audio with a clock rate of 8000 Hz (RFC3551). As such, this description doesn't have to (but should) be included in the media format description of the SDP offer/answer, using the "a=rtpmap:" and "a=fmtp:" attributes (RFC4566).
Payload type numbers 96-127 are dynamic. These can be used to negotiate encodings that aren't included in the static list. When using one of these numbers, an encoding specification has to be included in the media format description to specify the exact encoding parameters.
Both negotiating parties can choose their own dynamic payload type number to represent the same media encoding, this doesn't have to be the same number. This can be useful when a party already assigned a particular dynamic payload type number to another encoding. In your example one party uses 101 in the m-line and the other one uses 120, but these numbers represent the same media encoding (see "a=rtpmap:" lines). Each party tells the other 'when you send RTP using encoding X you must include payload type number Y in the RTP packet headers.
The payload type number is included in the PT field of RTP packets headers (RFC 3550)
In this case:
The "a=fmtp:" attribute in the answer specifies 101 as payload type number instead of 120. That means it doesn't apply to the telephone-events payload and no information is available as to which DTMF events are supported (RFC 4733). I think this is an implementation error and the fmtp attribute is meant to apply to the telephone-events payload.
It is an indication that you should expect DTMF issues. But it could also all work fine. Give it a try...
Related
From a client we receive an UPDATE message which contains the below media with fmt properties as below.
m=video 0 RTP/SAVP 0
Their aim is to close video media but it is causing us problems.
Is their message correct?
The usual format of closing video stream which we can correctly handle is
m=video 0 RTP/AVP 96 97 98
This is correct. According to the RFC 3264:
Existing media streams are removed by creating a new SDP with the
port number for that stream set to zero. The stream description MAY
omit all attributes present previously, and MAY list just a single
media format.
This makes sense, because when a participant doesn't want to have a video stream, it doesn't matter which formats it would be willing to use. m=video 0 RTP/SAVP 0 simply means "no video stream" or "terminate the video stream".
And there is no obligation that the media format in this case should make any sense. Just like in the message you received: the format 0 stands for PCMU, which is not even a video format.
8bit and binary are valid values for the Content-Transfer-Encoding header (here is a nice summary on SO).
However, trying to figure out which one was the most suitable for my needs, I encountered the following notices :
Binary encoded messages are not valid Internet messages.
and
Because not all Message Transfer Agents (MTAs) can handle 8bit data, the 8bit encoding is not a valid encoding mechanism for Internet mail.
Digging a bit I found out these warnings likely origin from Microsoft documentation.
What does it actually means ? Should one avoid these values ?
NB : It is not clear to me what the quoted "Internet messages" term specifically refers to. For my purposes, I am concerned only with multipart emails.
SDP RFC is silent on the sequence of codecs . so my question is can we send FMTP line above RTPMAP?
There is no any standard for this as it is codec dependent. If your software includes also codec's, then you should pass these parameters to your codec interface or configure your codec accordingly. Each codec expects different parameters, so there is no any high-level format that should be respected.The processing differs from codec to codec. Sometime it contains values that can be omitted, sometimes contains important parameters which must be used accordingly.
The format is like this: a=fmtp PAYLOADNUMBER PARAMETERS_SEPARATED_BY_SEMICOLON
For example for G.723 you can have something like this:
a=fmtp:4 bitrate=6.3;annexa=yes
Or for G.729:
a=fmtp:18 annexb=yes
Or for speex:
a=fmtp:105 mode=8;mode=any
I'm working on an implementation of TCP for a class and I'm wondering what the Window Size field actually mean.
I understand that the window size is the number of bytes, but does that number of bytes apply to:
the payload of the TCP Segment, not including the header or to
the entire TCP Segment, including the header?
Thus far, I've looked on Wikipedia:
RFC 793 states that:
The window indicates an allowed number of octets that the sender may
transmit before receiving further permission.
RFC 2581 states that:
receiver's advertised window (rwnd) is a receiver-side limit on the
amount of outstanding data
Neither of these make it particularly clear. Anyone?
It applies to the payload only. The sender can always transmit ACKs, FINs, RSTs, etc., with no payload.
While testing SIP Video call, I am getting the below the media line information in an answer for an Offered media. Is this valid media line ??
where media format number is different from the rtpmap number:
m=video 49218 RTP/AVP 109
b=TIAS:322000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42801f; max-mbps=216000; max-fs=3600; sar=13
a=sendonly
It's not a valid session description, but for a more subtle reason than Ralf's answer. A PT (payload type) of 109 falls in the dynamic range of the RTP/AVP profile defined in RFC 3551 which applies because of the RTP/AVP in the m line. "Dynamic" means what it says: RTP/AVP defines a whole bunch of standard codecs - PCM mu-law, G.729, and so on - and also allows for you to define your own PTs.
Here, the description says "we're going to use a custom PT of 109, and define another at 96, and forget to define what 109 means".
It's perfectly valid to define a bunch of rtpmap attributes and not use them; it's not valid to use a PT and then not define it!
I would say that it's an implementation bug since the rtpmap attribute is not referencing a payload format that has been specified in the media line, which effectively renders the attribute useless.
From Rfc4566:
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
This attribute maps from an RTP payload type number (as used in
an "m=" line) to an encoding name denoting the payload format
to be used.