Media Control(Video Picture Fast Update) mechanism for SIP

This question was origined from an experience of conferencing with different meeting terminals, including Polycom, Cisco, Tandburg, Huawei, etc.

In our current implementation of SIP conference, we are using a stream_id tag in the Video Fast Update command to  tell the peer we are requesting an Intra frame for a specific stream. And the stream_id tag value was recorded from the Label attribute of the SDP exchange process.
sip
However, this situation was:
1. Some of the vendors don’t have stream_id in the VideoFastUpdate command, such as CISCO and Tandburg, but if we send a VideoFastUpdate with stream_id tag in it, it doesn’t matter, it can response a 200 OK, only the stream_id value can not be zero, otherwise, it will reply with a 500 error.
2. Polycom does have a stream_id in it, but no matter what circumstances, the stream_id is alway 1.
3. Huawei seems have a same implementation with Kedacom, having a stream_id in it, and the value is coherence with the LABEL tag in the SDP.

Then I turned to the RFC document, RFC5168: XML Schema for Media Control, category: informational, developed by Microsoft, Polycom, Radvision.
The definition is placed in phase 5 of this document:
The Schema Definition

  <?xml version="1.0" encoding="utf-8" ?>

   <xs:schema id="TightMediaControl"
    elementFormDefault="qualified"
     xmlns:xs="http://www.w3.org/2001/XMLSchema">

           <xs:element name="media_control">
               <xs:complexType>
                  <xs:sequence>
                     <xs:element name="vc_primitive"
                                           type="vc_primitive"
                                           minOccurs="0"
                                           maxOccurs="unbounded" />
                     <xs:element name="general_error"
                                           type="xs:string"
                                           minOccurs="0"
                                           maxOccurs="unbounded" />
                  </xs:sequence>
               </xs:complexType>
           </xs:element>

           <!-- Video control primitive.  -->

           <xs:complexType name="vc_primitive">
                   <xs:sequence>
                     <xs:element name="to_encoder" type="to_encoder" />
                      <xs:element name="stream_id"
                                       type="xs:string"
                                       minOccurs="0"
                                       maxOccurs="unbounded" />
                           </xs:sequence>
           </xs:complexType>

           <!-- Encoder Command:
                Picture Fast Update
           -->

           <xs:complexType name="to_encoder">
                   <xs:choice>
                           <xs:element name="picture_fast_update"/>
                   </xs:choice>
           </xs:complexType>

   </xs:schema>

So, as you can see, there is actually a stream_id tag in it. But when I tried to find more about it, nothing was found. Weird enough for a RFC document.

After re-read the full document, found out there was a description which explains the situation:
New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel.

Failed to establish H.460 call through Polycom MCU issue

Details of the issue:

The situation is H600 can establish H.460 calls with most of the GKs around the world, but failed to a Polycom GK.
Allow me to explain the details of this issue:
1. Caller: Group500, callee: H600, GK/MCU: Polycom RMX 2000
2. Group500 sent a call to GK with callModel set to gatekeeperRouted, calling target: H600
3. GK sent H.460 SCI to H600
4. H600 replied SCR to GK
5. H600 established a H.225 TCP connection to the Polycom GK successfully
6. H600 sent facility to GK.
7. Polycom GK shutdown the H.225 TCP connection from H600 actively, and call terminated. Continue reading “Failed to establish H.460 call through Polycom MCU issue”

Make VLC player to support play H.264 ES stream file

As I knew, H.264 ES stream file can be played back by CorePlayer(Commercial version of MPlayer).
But not VLC Player. But as I was told that someone did use VLC Player to player H.264 ES stream file.
So made some further dig into this issue, turned out the old version of VLC Player does support, while versions later than 1.0 doesn’t by default.
Continue reading “Make VLC player to support play H.264 ES stream file”

OLC process rule of Avaya MCU 5110

Backgroud:
1. Both H800 and Avaya MCU 5110 support up to H.264 1080P video.
2. Avaya MCU supports 720P video when conferencing with Avaya endpoints(XT1000)
3. H800 Called by(Or calling to) Avaya(RADVision) MCU 5110, the opened video channel can only max to 4CIF.
Continue reading “OLC process rule of Avaya MCU 5110”

Step by step to enable x264 with OpenCL – NVIDIA solution

x264 project added OpenCL video acceleration to it’s implementation early at about 2013(not sure with the date), and my goal here is test the video encoding performance of x264 when with OpenCL video accelerator enabled.

Test hardware environments: HP Pavilion 14
1. Graphic card: NVIDIA GeForce GT730M card.
2. CPU: Intel Core Ivy Bridge i7-3632QM
Continue reading “Step by step to enable x264 with OpenCL – NVIDIA solution”

Patent: Data transmission method for video conferencing and video conferencing systems

I submitted a patent paper, Data transmission method for video conferencing and video conferencing systems, to my parent agent early at Sep, 2014.

It is a patent with H.460 involved, origin from the V5.0 platform system.

But did not get any feedback until the Chinese New Year of 2015.

And after a few days of discussion and revision, finally got it finished. So, yes, the efficiency of patent agent could also be great once they decided to start.

Here is the Patent Application No. 201510096936.3

A simple implementation of GUID/UUID

GUID, Globally Unique Identifier, aka UUID(Universally Unique Identifier), is very useful when you need a global identifier in you program.
GUID is a 128-bit integer number used to identify resources. The term GUID is generally used by developers working with Microsoft technologies, while UUID is used everywhere else.
Continue reading “A simple implementation of GUID/UUID”

Solution to fix WordPress update failure issue

I was having problem while updating one of my plugin weeks ago, telling me that

Could not create directory. /home/<>/public_html/wp-content/plugins/download-manager
Plugin install failed.

or

Unable to locate WordPress Content directory (wp-content).

Continue reading “Solution to fix WordPress update failure issue”

About alias: H.323 ID

Days earlier, ran into an issue which was H.323 ID related when conferencing with CISCO and LIFESIZE endpoints.

Normally we got used to set the H.323 ID with any charactors we want. But seems some manufacturors like CISCO and
LIFESIZE don’t think it appropriate, because they are adapting some rules in the naming of H.323 ID.

Here was the issue:
When trying to start a call, if the peer endpoint’s H.323 ID is named with {DIGIT}.{DIGIT}, such as 123.456, both CISCO’s and LIFESIZE’ endpoints will not to send ARQ to the registered GK to start the call.

The first thought was DOT is not allowed in H.323 ID to CISCO and LIFESIZE, then made more tries with different combinations, turned out an H.323 ID with {ALPHA}.{DIGIT} just worked fine.

Then turned to the ITU/T H.323 series of documents, trying to find a detail naming rule for H.323 ID, but got no luck but a simple description:

The H.323 ID consists of a string of ISO/IEC 10646 characters as defined in Rec. ITU-T H.225.0. It
may be a user name, conference name, e-mail name, or other identifier.

To my understanding of this phrase, DOT should not be an invalid character, but why this happened???

BTW: Tested HUAWEI(TEx0) and POLYCOM(PVX8.0.2) endpoints,  a H.323 ID named with {DIGIT}.{DIGIT} rule is allowed to them.

Debugging & troubleshooting tutorial: core dump debug

As you know, there are LIMIT settings in Linux OS which may have something to do with some frequent-happen-issue. Such as stack size, open files, core file generation, etc.

Here are some tips about ulimit, core, and some debugging tricks relevant.

1. ulimit comamnd

——————————

To view your OS limitations, you can use command:

ulimit -a

It will show you the current OS limitations for your environment like this:

[weiguohua@localhost ~]$ ulimit -a

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
pending signals                 (-i) 1024
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 16384
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

2. Enable core file
——————————

If you wish to generate a core file when your program crashed, you can use a command like this:

ulimit -c 123456789

The number following ulimit -c is the max core file size, you can set a number as you wish.

And there are rules for core file name, they are saved in:

1) /proc/sys/kernel/core_pattern

Used to control the core file name format
Default value: core
You can change it to “/home/weiguohua/corefile/core-%e-%p-%t” which means all the core file will be saved to the folder “/home/weiguohua/corefile”, and the core file name will be “core-[program name]-[pid]-[crash-time]”.

echo /home/weiguohua/corefile/core-%e-%p-%t > /proc/sys/kernel/core_pattern

 2) /proc/sys/kernel/core_uses_pid

0: Default setting, means the core file will not suffixed with a PID.
1: Add a PID suffix to the core file, such as “core.9721”

You can change it by command:

echo 1 > /proc/sys/kernel/core_uses_pid

You can man core to reference the naming rule of core dump files.

3. Debug a core file by GDB
——————————

Debugging a core file in some way is nothing different with debugging the program in a normal way.
Assume your program name is segment.out, and the generated core file name is core.9721, you can start your debug by command:

gdb ./segment.out core.9721

Then your can do anything you want for the core file, such as bt, p, etc.

P.S. If a core dump happened, and you can not locate the function by gdb backtrace, you can:
1) Use ldd to check out the so files(dynamic link libraries) this program depends on.
2) Use nm to list the symbols of the so files, and search the addresses in the core file.
3) Locate the functions by comparing the addresses in core file and the symbol map listed by nm command.

4. Memory maps for a running program
——————————

You can view the address map & range for a running program by simply cat the maps file in the /proc/[pid] folder.
It will print out the detail memory map of all the symbols the program loaded, including the so files it depended on.

[weiguohua@localhost 9721]# pwd
/proc/9721
[weiguohua@localhost 9721]# cat maps

00110000-00113000 r-xp 00000000 fd:00 677857     /lib/libdl-2.12.so
00113000-00114000 r–p 00002000 fd:00 677857     /lib/libdl-2.12.so
00114000-00115000 rw-p 00003000 fd:00 677857     /lib/libdl-2.12.so
00115000-00127000 r-xp 00000000 fd:00 677856     /lib/libz.so.1.2.3
00127000-00128000 rw-p 00011000 fd:00 677856     /lib/libz.so.1.2.3
00128000-00256000 r-xp 00000000 fd:00 1967906    /usr/lib/mysql/libmysqlclient.so.16.0.0
00256000-0029d000 rw-p 0012e000 fd:00 1967906    /usr/lib/mysql/libmysqlclient.so.16.0.0
0029d000-002c5000 r-xp 00000000 fd:00 677847     /lib/libm-2.12.so
002c5000-002c6000 r–p 00027000 fd:00 677847     /lib/libm-2.12.so
002c6000-002c7000 rw-p 00028000 fd:00 677847     /lib/libm-2.12.so
002c7000-00439000 r-xp 00000000 fd:00 1867809    /usr/lib/libcrypto.so.1.0.0
00439000-0044d000 rw-p 00172000 fd:00 1867809    /usr/lib/libcrypto.so.1.0.0
0044d000-00450000 rw-p 00000000 00:00 0
00450000-00457000 r-xp 00000000 fd:00 677864     /lib/libcrypt-2.12.so
00457000-00458000 r–p 00007000 fd:00 677864     /lib/libcrypt-2.12.so
00458000-00459000 rw-p 00008000 fd:00 677864     /lib/libcrypt-2.12.so
00459000-00480000 rw-p 00000000 00:00 0
00480000-0054a000 r-xp 00000000 fd:00 677879     /lib/libkrb5.so.3.3
0054a000-00550000 rw-p 000ca000 fd:00 677879     /lib/libkrb5.so.3.3
00550000-00595000 r-xp 00000000 fd:00 677863     /lib/libfreebl3.so
00595000-00596000 rw-p 00045000 fd:00 677863     /lib/libfreebl3.so
00596000-0059a000 rw-p 00000000 00:00 0
0059f000-005bd000 r-xp 00000000 fd:00 677835     /lib/ld-2.12.so
005bd000-005be000 r–p 0001d000 fd:00 677835     /lib/ld-2.12.so
005be000-005bf000 rw-p 0001e000 fd:00 677835     /lib/ld-2.12.so
005bf000-005c8000 r-xp 00000000 fd:00 677876     /lib/libkrb5support.so.0.1
005c8000-005c9000 rw-p 00008000 fd:00 677876     /lib/libkrb5support.so.0.1
005c9000-005e6000 r-xp 00000000 fd:00 677860     /lib/libselinux.so.1
005e6000-005e7000 r–p 0001c000 fd:00 677860     /lib/libselinux.so.1
005e7000-005e8000 rw-p 0001d000 fd:00 677860     /lib/libselinux.so.1
005f2000-00628000 r-xp 00000000 fd:00 1967263    /usr/libexec/postfix/pickup
00629000-0062a000 r–p 00036000 fd:00 1967263    /usr/libexec/postfix/pickup
0062a000-0062b000 rw-p 00037000 fd:00 1967263    /usr/libexec/postfix/pickup
0062b000-0062c000 rw-p 00000000 00:00 0
00634000-00678000 r-xp 00000000 fd:00 1867822    /usr/lib/libldap-2.4.so.2.5.2
00678000-00679000 rw-p 00044000 fd:00 1867822    /usr/lib/libldap-2.4.so.2.5.2
00679000-00685000 r-xp 00000000 fd:00 655000     /lib/libnss_files-2.12.so
00685000-00686000 r–p 0000b000 fd:00 655000     /lib/libnss_files-2.12.so
00686000-00687000 rw-p 0000c000 fd:00 655000     /lib/libnss_files-2.12.so
006c1000-006e2000 rw-p 00000000 00:00 0          [heap]
006f9000-0086c000 r-xp 00000000 fd:00 655098     /lib/libdb-4.7.so
0086c000-0086f000 rw-p 00173000 fd:00 655098     /lib/libdb-4.7.so
00888000-008a0000 r-xp 00000000 fd:00 1867808    /usr/lib/libsasl2.so.2.0.23
008a0000-008a1000 rw-p 00018000 fd:00 1867808    /usr/lib/libsasl2.so.2.0.23
009ff000-00a02000 r-xp 00000000 fd:00 677878     /lib/libcom_err.so.2.1
00a02000-00a03000 rw-p 00002000 fd:00 677878     /lib/libcom_err.so.2.1
00b40000-00b6f000 r-xp 00000000 fd:00 655464     /lib/libpcre.so.0.0.1
00b6f000-00b70000 rw-p 0002e000 fd:00 655464     /lib/libpcre.so.0.0.1
00bb5000-00bb7000 r-xp 00000000 fd:00 677875     /lib/libkeyutils.so.1.3
00bb7000-00bb8000 rw-p 00001000 fd:00 677875     /lib/libkeyutils.so.1.3
00c30000-00c56000 r-xp 00000000 fd:00 677877     /lib/libk5crypto.so.3.1
00c56000-00c57000 rw-p 00026000 fd:00 677877     /lib/libk5crypto.so.3.1
00c71000-00c72000 r-xp 00000000 00:00 0          [vdso]
00cac000-00ce2000 r-xp 00000000 fd:00 677880     /lib/libgssapi_krb5.so.2.2
00ce2000-00ce3000 rw-p 00036000 fd:00 677880     /lib/libgssapi_krb5.so.2.2
00cfb000-00d12000 r-xp 00000000 fd:00 677844     /lib/libpthread-2.12.so
00d12000-00d13000 r–p 00016000 fd:00 677844     /lib/libpthread-2.12.so
00d13000-00d14000 rw-p 00017000 fd:00 677844     /lib/libpthread-2.12.so
00d14000-00d16000 rw-p 00000000 00:00 0
00dab000-00dc1000 r-xp 00000000 fd:00 655424     /lib/libnsl-2.12.so
00dc1000-00dc2000 r–p 00016000 fd:00 655424     /lib/libnsl-2.12.so
00dc2000-00dc3000 rw-p 00017000 fd:00 655424     /lib/libnsl-2.12.so
00dc3000-00dc5000 rw-p 00000000 00:00 0
00e4f000-00ea2000 r-xp 00000000 fd:00 1867810    /usr/lib/libssl.so.1.0.0
00ea2000-00ea6000 rw-p 00052000 fd:00 1867810    /usr/lib/libssl.so.1.0.0
00efc000-00f09000 r-xp 00000000 fd:00 1843537    /usr/lib/liblber-2.4.so.2.5.2
00f09000-00f0a000 rw-p 0000c000 fd:00 1843537    /usr/lib/liblber-2.4.so.2.5.2
00f3b000-00f50000 r-xp 00000000 fd:00 677859     /lib/libresolv-2.12.so
00f50000-00f51000 r–p 00014000 fd:00 677859     /lib/libresolv-2.12.so
00f51000-00f52000 rw-p 00015000 fd:00 677859     /lib/libresolv-2.12.so
00f52000-00f54000 rw-p 00000000 00:00 0
b762c000-b7630000 rw-p 00000000 00:00 0
b7630000-b77b5000 r-xp 00000000 fd:00 677841     /lib/libc-2.12.so
b77b5000-b77b6000 —p 00185000 fd:00 677841     /lib/libc-2.12.so
b77b6000-b77b8000 r–p 00185000 fd:00 677841     /lib/libc-2.12.so
b77b8000-b77b9000 rw-p 00187000 fd:00 677841     /lib/libc-2.12.so
b77b9000-b77be000 rw-p 00000000 00:00 0
b77d3000-b77d4000 rw-p 00000000 00:00 0
bfdde000-bfdf3000 rw-p 00000000 00:00 0          [stack]

[H.323] TCS negotiation rule of HUAWEI

Encountered a capability negotiation issue when conferencing with a HUAWEI terminal.

It happened in a dual stream(H.239) capability negotiation.

Environments:
1. According to the H.245 TCS, both terminal have 1080P 60 fps capability.
2. The band width setting was extreme low.
3. HUAWEI sent a OLC request with 4CIF H.264 video.

Continue reading “[H.323] TCS negotiation rule of HUAWEI”

An issue about HUAWEI TEx0 H.264 video capability calculating

Encounter a H.264 video capability issue while conferencing with HUAWEI TEx0 MT.
Both MTs(H800 and TEx0) have 1080P 60 fps H.264 video capability, but HUAWEI MT will send an OLC request with 1080P 30 fps when starting open the logical channel, while conferencing with Cisco MTs, this issue doesn’t happen.

H800 H.264 capabilityH.245 TCS from H800HUAWEI TEx0 H.264 capabilityH.245 TCS from TEx0OLC from HUAWEI TEx0H.245 OLC from HUAWEI TEx0

Checked the H.245 TCS of H800, found there was no CustomMaxFS value in it (only CustomMaxMBPS and CustomMaxBRandCPB),

  • H800 TCS: Level: 85, CustomMaxMBPS: 972 –> 1080P 60 fps
  • TEx0 TCS: Level: 71, CustomMaxMBPS: 983, CustomMaxFS: 32 –> 1080P 60 fps
  • OLC from TEx0: Level: 71, CustomMaxMBPS: 212, CustomMaxFS: 32 –> 1080P 30 fps

Conclusion:

HUAWEI TEx0 will use Level parameter only if there’s no CustomMaxFS.
In this case, we presented only H.264 Level, and CustomMaxMBPS, TEx0 will just ignore the CustomMaxMBPS parameter, that is to say it considered only the H.264 Level parameter, and the Level default capability is right 1080P 30 fps.

Solution:

Add CustomMaxFS parameter to H800’s TCS, everything works just fine.

Some key notes for RFC3264

Facing a new task of standardizing SIP protocols for the Kedacom conference Endpoints.

So I digged into some RFC document recently. Here are some key notes for RFC3264: An OfferAnswer Model with the Session Description Protocol (SDP)

1. Capatibility comparison – Direction

—————————————–

If “a=sendrecv” attribute does not exist, or been omitted, that means the direction is sendrecv, since sendrecv is the default.

2. [Offering] RTP Port in m

—————————————–

RTP port in m line for recvonly and sendrecv streams, while RTCP port for sendonly streams.

For recvonly and sendrecv streams, the port number and address in the
offer indicate where the offerer would like to receive the media
stream.  For sendonly RTP streams, the address and port number
indirectly indicate where the offerer wants to receive RTCP reports.
Unless there is an explicit indication otherwise, reports are sent to
the port number one higher than the number indicated.  The IP address
and port present in the offer indicate nothing about the source IP
address and source port of RTP and RTCP packets that will be sent by
the offerer.

3. [Offering] Switching media format if multiple formats supported**

—————————————–

If multiple formats are listed, it
means that the offerer is capable of making use of any of those
formats during the session.  In other words, the answerer MAY change
formats in the middle of the session, making use of any of the
formats listed, without sending a new offer.

[Offering] Capatibility comparison – Preference

——————————————

In all cases, the formats in the “m=” line MUST be listed in order of
preference, with the first format listed being preferred.  In this
case, preferred means that the recipient of the offer SHOULD use the
format with the highest preference that is acceptable to it.

[Offering] Capatibility comparison – Preference 2

—————————————–

For sendrecv RTP
streams, the payload type numbers indicate the value of the payload
type field the offerer expects to receive, and would prefer to send.
However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.

* This is what SIP different with H.323, the payload type value in H.245 OLC mean’s the request will send the payload with this payload type value, while in SDP it means you should send your payload with the value I specified in my SDP.

[Offering] Bandwidth description

—————————————–

If the bandwidth attribute is present for a stream, it indicates the
desired bandwidth that the offerer would like to receive.  A value of
zero is allowed, but discouraged.  It indicates that no media should
be sent.  In the case of RTP, it would also disable all RTCP.

[Offering] A typical usage example for multiple media streams

—————————————–

A typical usage example for multiple media streams of the same type
is a pre-paid calling card application, where the user can press and
hold the pound (“#”) key at any time during a call to hangup and make
a new call on the same card.  This requires media from the user to
two destinations – the remote gateway, and the DTMF processing
application which looks for the pound.  This could be accomplished
with two media streams, one sendrecv to the gateway, and the other
sendonly (from the perspective of the user) to the DTMF application.

[Answering] Answering SDP must have at least one media format while rejecting

—————————————–

To reject an offered
stream, the port number in the corresponding stream in the answer
MUST be set to zero.  Any media formats listed are ignored.  At least
one MUST be present, as specified by SDP.

[Answering] Stream marked as recvonly can suggest a new format for the offerer

—————————————–

For streams marked as recvonly in the answer, the “m=” line MUST
contain at least one media format the answerer is willing to receive
with 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 receive.

Similarly, just like recvonly streams, sendrecv streams can suggest new formats for the offerer (of course, it will not be able to send them at this time, since it was not listed in the offer).

[Answering]Capability comparison – RECOMMENDED Order for answerer

—————————————–

If a stream in the offer lists
audio codecs 8, 22 and 48, in that order, and the answerer only
supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has
no reason to change it, the ordering of codecs in the answer be 8,
48, and not 48, 8.

[Answering]Prefer RTP payload type with the value in the offer rather than in the answer

—————————————–

In the case of RTP, it MUST use the payload type numbers
from the offer, even if they differ from those in the answer.

[multicast] ??? How to handle participants in a some conference but with different format support ???

—————————————–

The set of media formats in the answer MUST be equal to or be a
subset of those in the offer.  Removing a format is a way for the
answerer to indicate that the format is not supported.

[Processing Answer]

—————————————–

It(Call offerer) MUST send using a media format listed in the answer,
and it SHOULD use the first media format listed in the answer when it
does send.

The reason this is a SHOULD, and not a MUST (its also a SHOULD,
and not a MUST, for the answerer), is because there will
oftentimes be a need to change codecs on the fly.  For example,
during silence periods, an agent might like to switch to a comfort
noise codec.  Or, if the user presses a number on the keypad, the
agent might like to send that using RFC 2833 [9].  Congestion
control might necessitate changing to a lower rate codec based on
feedback.

[Modifying the Session] Session version of REINVITE

—————————————–

When issuing an offer that modifies the session,
the “o=” line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP.  If the version in the origin
line does not increment, the SDP MUST be identical to the SDP with
that version number.

[Modifying the Session] Rules for m(Media stream) line of REINVITE

—————————————–

If an SDP is offered, which is different from the previous SDP, the
new SDP MUST have a matching media stream for each media stream in
the previous SDP.

[Modifying the Session] Adding a Media Stream in REINVITE

—————————————–

New media streams are created by new additional media descriptions
below the existing ones, or by reusing the “slot” used by an old
media stream which had been disabled by setting its port to zero.

[Modifying the Session] Changing the Set of Media Formats in REINVITE

—————————————–

For example, if A generates an offer
with G.711 assigned to dynamic payload type number 46, payload type
number 46 MUST refer to G.711 from that point forward in any offers
or answers for that media stream within the session.  However, it is
acceptable for multiple payload type numbers to be mapped to the same
codec, so that an updated offer could also use payload type number 72
for G.711.

     The mappings need to remain fixed for the duration of the session
      because of the loose synchronization between signaling exchanges
      of SDP and the media stream.

[Modifying the Session] Sending Media Stream after REINVITE is done

—————————————–

Similarly, as described in Section 6, as soon as it sends
its answer, the answerer MUST begin sending media using any formats
in the offer that were also present in the answer
Similarly, when the offerer receives the
answer, it MUST begin sending media using any formats in the answer

[Modifying the Session] Rules of ceasing use of an old media format for Agents

—————————————–

When an agent ceases using a media format (by not listing that format
in an offer or answer, even though it was in a previous SDP) the
agent will still need to be prepared to receive media with that
format for a brief time.

[Modifying the Session] Hold on a call

—————————————–

Hold on a call means request the other participant(s) stop sending streams to it.

   If the stream to be placed on hold was previously a sendrecv media
stream, it is placed on hold by marking it as sendonly.  If the
stream to be placed on hold was previously a recvonly media stream,
it is placed on hold by marking it inactive.

Certain third party call control scenarios do not work when an
      answerer responds to held SDP with held SDP.

[Modifying the Session] Hold on a call 2

—————————————–
Does it mean the sending of the Hold on requester will continue? The answer is no.

   Typically, when a user “presses” hold, the agent will generate an
offer with all streams in the SDP indicating a direction of sendonly,
and it will also locally mute, so that no media is sent to the far
end, and no media is played out.