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

[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.

Google shares SoC details for its modular smartphone coming 2015

Project_Ara_scattered_partsInterest in Google’s Project Ara is definitely very high among the tech loving community around the world. In the coming months, we expect to hear a lot more about the project as Google plans to launch the first device under the project by late 2015. The Mountain View based company recently shared some new information about the Project Ara that includes details on the SoCs and also the form factor of the device.

For the SoC, Google is working with NVIDIA and Marvell for two separate reference designs and form factor module prototypes. NVIDIA’s Tegra K1, the chipset used on the Google Nexus 9, and the Marvell PXA1928 are two chipsets that could be seen on the upcoming MDK v0.20 release. While most of you will be well aware of the NVIDIA Tegra K1 chipset, the Marvell PXA1928 chipset may be unfamiliar to most of you. The PXA1928 chipset is a 64-bit mobile SoC with a quad-core Cortex A53 based CPU, high perfroamnce GC5000 GPU and a 5-mode modem with support for LTE TDD/FDD, HSPA+, TD HSPA+ and EDGE connectivity.

Google also mentioned in the post that the Spiral 3 prototype was on schedule and should become available by spring. Before that, the company plans to show off its Spiral 2 prototypes at the Developers Conference in January. Also in January, Toshiba will be unveiling their second generation of UniPro switch and bridge ASICs with contactless M-PHY data transfer capability. These will be basis of Google’s Spiral 3 prototype and the final MDK release that is scheduled for next year.

Although we still have very little information on the first prototypes, Google did mention in the post that the Spiral 2 form factor prototypes look beautiful and come with custom module shells. The Project Ara Developers Conference is scheduled to be held in Mountain View, California on January 14th 2015 and in Singapore on January 21st 2015.

Source: Google ATAP

Big Announcement from Apple: All the Apps need to be 64 bit

Yesterday, Dec 17, 2014, a notice was launched on Apple Developer site, asking developers to submit 64 bit Apps to App Store for IOS, and all the Apps without 64 bit support will not be approved after June 1, 2015.

This could be a big requirement for me, and for my team, because we are definitely not ready for it now.

Seems we must change our developping schedules now.


Lastest info about UniGate IOT Controller

Yesterday, I got to know that the UniGate is promoted to be one of the major products for UniSVR when I talked with a former colleague from UniSVR.

It’s really a good thing to know. As what I always say, I have a good faith in the UniGate and IOT field.

Keep fighting! Looking forward to it.

Continue reading “Lastest info about UniGate IOT Controller”

Debugging & troubleshooting tutorial: backtrace + addr2line

Planning to write a series of posts about debugging & trouble shooting tricks. And I’d like to make backtrace as a start. As a typical programmer(AKA nerd), I’d like to jump to the topic directly before run into blah-blah.

Everyone knows, bug is free, so it may be at everywhere, to check out your free gift(s) sending to your clients, you may consider backtrace.
Continue reading “Debugging & troubleshooting tutorial: backtrace + addr2line”