This CEO says her riskiest career move was becoming an engineer

I like this words: “There’s never a perfect time for anything—you just have go for it and keep your eyes on your goal.”

girlswhocodeWritten by Anne Kreamer
August 25, 2015

In the US, where only 11% of working engineers are women and fewer than 5% of the CEOs of the 500 biggest companies are female, Jennifer Van Buskirk, the president of Cricket Wireless, a subsidiary of AT&T, is something of a freak. In a good way.

Van Buskirk, 42, chose a course of study that many thought was then “risky” for a woman—becoming an engineer. In 1991, when she entered Virginia Tech, she says women and minorities comprised only 15% of engineering students (pdf) nationwide and were much less likely than men to be employed in engineering once they did graduate.

“I was definitely not taking the easy route,” Van Buskirk told Quartz. “I was typically one of the only women in my college classes and often had to work harder than my male counterparts to be heard.”

She says she found the experience exhilarating. “I really liked breaking the mold and challenging the stereotypes about women. Probably because I was confident in my analytical skills and my ability to learn and adapt, so no matter what obstacles were thrown my way, I knew I could figure a way around them.”

In her approach to her education and prospective career, Van Buskirk intuitively understood two critical components of successful risk-taking. She embraced what Stanford University psychology professor Carol Dweck calls a “growth” mind-set, which is a belief in one’s ability to learn, change, and handle challenges. The other attribute is what University of Pennsylvania psychologist Angela Duckworth, calls “grit,” which is “the sustained and focused application of talent over time.”

When AT&T acquired Cricket from Leap Wireless in 2013 the company was losing about a million subscribers a year, but under Van Buskirk’s leadership, it now boasts 5 million subscribers. What she considers her greatest risk, taking a job she knew nothing about, has proven to be worth taking.

I asked Van Buskirk about how she’s navigated professional risk and here’s what she said.

Van Buskirk:

“I’ve taken a lot of perceived risks in my career.

In fact, that sense of confidence, which was formed in me at an early age, has been the lynchpin of my career success. It has enabled me to embrace risk and leverage it versus run from it. In 2005, I put that confidence to the test when I responded to a request from Ralph de la Vega, our current head of Mobility & Business Solutions at AT&T. Back then, Ralph wanted me to interview for his chief of staff role. While this probably doesn’t sound like a very risky move—especially when you compare it to starting Aio Wireless or Cricket Wireless–it sure felt like it—for two reasons.

Reason number one: I knew nothing about the job—literally, zero. And reason number two: I was seven months pregnant at the time.

I was pretty certain I could learn the role, but I remember looking at my pregnant belly and saying to myself, ‘I’m never going to get this job – who would hire me like this?’ And even if I did get hired, would it be career-suicide to jump into a demanding, high profile, new role just to step out to give birth, then jump back in? How much pressure would I be putting on my family and myself in order to make all this work?

And, of course, there were the inevitable skeptics who echoed those doubts. But I realized there’s never a perfect time for anything—you just have go for it and keep your eyes on your goal. And my goal was to be a leader and, as such, do something impactful for the company.

I ended up getting the chief of staff job, which led to other roles within AT&T, which, eventually, brought me to where I am today, president of Cricket Wireless. By staying confident and believing in myself and my capabilities; by ensuring that I don’t let others define me; and by embracing change instead of avoiding it, I’ve been able to chart my own course. And that course has included leading Cricket Wireless—one of the most successful consumer brands in the wireless industry.

I’ve taken what many perceive as big risks in my career, but I’ve always viewed them as opportunities. I’ve tackled challenges head-on and I’ve learned to be comfortable with being uncomfortable. I think that’s the key: don’t let perception become reality. If you look for the opportunity, you can always mitigate the risk.”

We welcome your comments at


Trouble shooting: step by step to analysis crashes

This post’s goal is to guide a starter to analysis a crash by reading into the assemble code.

But the example listed here is not a good one, because the crash point is not an obvious one, the real reason of the crash for this example is still remain uncovered.

My point here is, we can use a such kind of way to analysis some crash, and once you read this post, you can start the first step. If you run into any problems when analysis your crash, well, we can discuss wih them together here. Here we go. Continue reading “Trouble shooting: step by step to analysis crashes”

A common bug of HD3 series terminals

An issue of call establishment delay when conferencing with Polycom MCU RMX2000

The situation was

1. Meeting entities
1). Polycom MCU: Polycom RMX 2000, version ID: 8.3.0
2). Kedacom HD3 H600 SP4

2. Call scenario
HD3 joined a multi-point conference with RMX2000.
1) All the H.225 and H.245 processes were OK.
2) OLC request from both side returned with ACK.
3) The audio packets could be captured right after the OLC ACK.
4) The video packets from HD3 sent right after got the OLC ACK from the MCU.
5) HD3 could not receive any video packets from the MCU.
6) HD3 waiting for a terminalYouAreSeeing conferenceIndication from the MCU to switch the status to InConf…
7) 20 seconds later we finally got the terminalYouAreSeeing indication. Along with the terminalYouAreSeeing, we got the video.

Seems the MCU was waiting for a command to switch its status to an established-mode.
But we just don’t know what it is, even after tested lot’s of MTs from Polycom, Tendburg, HUAWEI, ZTE, which all of them just working fine.

What we got is only that it must be a HD3’s bug.

After a long long times comparison with the pcap file, the only difference was the H.224 channel.
We did not open the H.224(FECC) channel together with the audio, video and H.239 channel, this caused the RMX2000 to wait 20 seconds to send the terminalYouAreSeeing indication.
It’s a yet-another-long-existing bug, we survived a long time, but today we finally ran into the consequence.

PCAP file: a-common-bug-of-hd3-series-terminals.pcap

RTCP and AVPF related missing features

Most of the missing features are AVPF related, which is defined in RFC4585 and RFC5104.

RFC4585: Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
RFC5104:  Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)

AVPF contains a mechanism for conveying such a message, but did not specify for which codec and according to which syntax the message should conform.  Recently, the ITU-T finalized Rec.H.271, which (among other message types) also includes a feedback message.  It is expected that this feedback message will fairly quickly enjoy wide support.  Therefore, a mechanism to convey feedback messages according to H.271 appears to be desirable.

RTCP Receiver Report Extensions
1. CCM – Codec Control Message
2. FIR – Full Intra Request Command
A Full Intra Request (FIR) Command, when received by the designated
media sender, requires that the media sender sends a Decoder Refresh
Point (see section 2.2) at the earliest opportunity.  The evaluation
of such an opportunity includes the current encoder coding strategy
and the current available network resources.

FIR is also known as an “instantaneous decoder refresh request”,
“fast video update request” or “video fast update request”.

3. TMMBR – Temporary Maximum Media Stream Bit Rate Request
4. TMMBN – Temporary Maximum Media Stream Bit Rate Notification

Example from RFC5104:

Receiver A: TMMBR_max total BR = 35 kbps, TMMBR_OH = 40 bytes
Receiver B: TMMBR_max total BR = 40 kbps, TMMBR_OH = 60 bytes

For a given packet rate (PR), the bit rate available for media
payloads in RTP will be:

Max_net media_BR_A =
TMMBR_max total BR_A – PR * TMMBR_OH_A * 8 … (1)

Max_net media_BR_B =
TMMBR_max total BR_B – PR * TMMBR_OH_B * 8 … (2)

For a PR = 20, these calculations will yield a Max_net media_BR_A =
28600 bps and Max_net media_BR_B = 30400 bps, which suggests that
receiver A is the limiting one for this packet rate.  However, at a
certain PR there is a switchover point at which receiver B becomes
the limiting one.  The switchover point can be identified by setting
Max_media_BR_A equal to Max_media_BR_B and breaking out PR:

TMMBR_max total BR_A – TMMBR_max total BR_B
PR =  ——————————————- … (3)

5. TSTR – Temporal-Spatial Trade-off Request

5. TSTN – Temporal-Spatial Trade-off Request

6. VBCM – H.271 Video Back Channel Message

7. RTT – Round Trip Time
A receiver that receives a request closely after
sending a decoder refresh point — within 2 times the longest round
trip time (RTT) known, plus any AVPF-induced RTCP packet sending
delays — should await a second request message to ensure that the
media receiver has not been served by the previously delivered
decoder refresh point.  The reason for the specified delay is to
avoid sending unnecessary decoder refresh points.

8a. PLI – Picture Loss Indication
8b. SLI – Slice Loss Indication
8c. RPSI – Reference Picture Selection Indication

Here’s a sample INVITE command relaying from FreeSWITCH:

INVITE sip:1009@;transport=tcp SIP/2.0
Via: SIP/2.0/TCP;branch=z9hG4bK6p37yQX86QXar
Route: <sip:1009@>;transport=tcp
Max-Forwards: 69
From: "Extension 1008" <sip:1008@>;tag=DKK4FpBB3ptSS
To: <sip:1009@;transport=tcp>
Call-ID: 0199ec1f-9e53-1233-8583-000c29f7d152
CSeq: 77747697 INVITE
Contact: <sip:mod_sofia@;transport=tcp>
User-Agent: FreeSWITCH-mod_sofia/1.7.0+git~20150614T062551Z~a647b42910~64bit
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 495
X-FS-Support: update_display,send_info
Remote-Party-ID: "Extension 1008" <sip:1008@>;party=calling;screen=yes;privacy=off

o=FreeSWITCH 1436150633 1436150634 IN IP4
c=IN IP4
t=0 0
m=audio 16890 RTP/AVP 96 0 8 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1; stereo=0; sprop-stereo=0
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
m=video 22404 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42801F
a=rtcp-fb:96 ccm fir tmmbr
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli

Sample SDP of WebRTC for Firefox

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:36.0) Gecko/20100101 Firefox/36.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: pPQe97SI5k09yaPnVLa2RQ==
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: Lm5/9dDv4pjyphQQeswS+V+AiKc=

...Q^.U...BK......IIP.F....Q'.A...z..T5:::{"name":"log","args":[[">>> Message from server: ","Room foo has 1 client(s)"]]}.`5:::{"name":"log","args":[[">>> Message from server: ","Request to create or join room","foo"]]}.$5:::{"name":"joined","args":["foo"]}.B5:::{"name":"emit(): client GgKg1qt9TCXtfPb6n2g0 joined room foo"}..$.N...t _. {I.l ..+iW.)...l{V.=8..l}K.noW.<:I.*sE..g.Z5:::{"name":"log","args":[[">>> Message from server: ","Got message: ","got user media"]]}.~.x5:::{"name":"message","args":[{"type":"offer","sdp":"
o=mozilla...THIS_IS_SDPARTA-38.0 2820695485956467000 0 IN IP4
t=0 0
a=fingerprint:sha-256 7C:7B:AE:C2:AE:ED:14:39:A4:7A:EE:4B:FB:FE:90:90:E8:A1:0B:C1:50:FC:C8:9C:FA:28:68:22:EE:1C:F6:97
a=group:BUNDLE sdparta_0 sdparta_1
a=msid-semantic:WMS *
m=audio 9 RTP/AVP 109 9 0 8
c=IN IP4
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:{69b2b229-1dc0-4291-a703-aafe505d477b} {ebc6bb1c-8525-4a70-9601-354b53c5c103}
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ssrc:4051396866 cname:{f0f8a3ab-8c54-4694-872a-98dd14f0c821}
m=video 9 RTP/AVP 126 97
c=IN IP4
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=msid:{69b2b229-1dc0-4291-a703-aafe505d477b} {34f61d33-9fe4-42ff-8e2b-ef9c465c6f67}
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=ssrc:3993721606 cname:{f0f8a3ab-8c54-4694-872a-98dd14f0c821}



Restore blogroll function for your WordPress

Found some features were missing after upgraded my blog to the latest version, WordPress v4.0, such as blogrolls.
Tried to find it all over the dashboard, but got no luck.
So I turned to the almighty Google, finally got the solution, and it’s really easy. All you need to do is adding the following code to the end of functions.php of your theme:




About H.235 encryption algorithms

[20150822 Update] For the record, I didn’t find the right ITU-REC document when I wrote this post, and misguided by a claim of HUAWEI VP9650 which says it has AES256 supported, but when I sending out a call from VP9650, it showed a new DH group DH1536, so I made my conclusion arbitary, DH1536 means AES256, obviously, it’s a terrible mistake.

Planning to upgrade to H.235 encryption from AES128 to AES256, but don’t know where to start.

Did not find a short way to achieve that.

We wished to get some informations about AES256 by capturing some pcap files of some other Video Conference solution providers.

But did not find a device which actually supports H.235 + AES256 feature.

So we returned to the ITU-REC document for more details.  The right ITU-REC should be T-REC-H.235.6-201401-I!!PDF-E.pdf.

Some key steps of implementing H.235.

1. SETUP: Caller send a public key token DHSet of in H.225 SETUP, which includes:

1) halfkey: contains the random public key of one party

2)modsize: contains the DH-prime

3)generator: contains the DH-group

1. Public key token DHSet of in H.225 SETUP
1. Public key token DHSet of in H.225 SETUP

2. CONNECT: Callee generate a private key token by using the public key of caller, and send it back to the caller in its H.225 CONNECT, also including halfkey, modsize and generator.

2. Private key token of DHSet in H.225 CONNECT
2. Private key token of DHSet in H.225 CONNECT

3. TCS: Both caller and callee send their H.245 TCS with H.235 capabilities.

3. Sample H.245 TCS with H.235 capability
3. Sample H.245 TCS with H.235 capability

4. MasterSlave determination

5. Master generate a media key which will be used to encrypt/decrypt the media.

5a. OLC(from master): Open a logical channel with a specified H.235 media, and send to the slaver

H235Key in H.245 OLC
H235Key in H.245 OLC

5b. OLC ACK(from master): Reply the media key to the OLC requester(Slaver)

H235Key in H.245 OLC ACK
H235Key in H.245 OLC ACK

6. Some other H.245 request/indication messages, such as encryptionUpdateRequest, encryptionUpdate.

H.235 encryption related node definitions:

1. The tokenOID in H.225 SETUP and CONNECT message:
1a. H600’s tokenOID

1b. Huawei MCU’s tokenOID
ProductId: VP9650, versionId: V200R001C02B018SP07 Apr 28 2014 16:15:31+08
1. Public key token DHSet of in H.225 SETUP - HUAWEI-MCU-VP9650 3. Sample H.245 TCS with H.235 capability - HUAWEI-MCU-VP9650

1c. Huawei TE40’s tokenOID
ProductId: TEx0, versionId: Release

“T”      {itu-t (0) recommendation (0) h (8) 235 version (0) 2 5} {itu-t (0) recommendation (0) h (8) 235 version (0) 1 5} Used in Procedures I and IA as the baseline ClearToken for the message authentication and replay protection and optionally also for Diffie-Hellman key management as described in D.7.1.
“DH1024” {itu-t (0) recommendation (0) h (8) 235 version (0) 2 43} 1024-bit DH group
“DH1536” {itu-t (0) recommendation (0) h (8) 235 version (0) 3 44} 1536-bit DH group
From chapter D.11 List of object identifiers of <T-REC-H.235-200308-S!!PDF-E.pdf>, P.70-71

[20150822 Update]

Earlier when I wrote this post, I didn’t find the right ITU/T standard(T-REC-H.235.6-201401-I!!PDF-E.pdf).

The information I got was that HUAWEI VP9650 supports AES256, and when I tried to sending out a call on VP9650, I got  to know it supports following DH groups:


So I made my conclusion arbitarty that DH1536 is our goal: AES256, but turned out I was terribly wrong. (I don’t know why VP9650 sending out max to DH1536 while it claims having AES 256 supported)

DH group - DH1536

2. Media encryption algorithm definitions on H.245 TCS, OLC, OLC ACK,etc:

The most frequently used/seem types are:
2a. AES 128 bit CBC: 2.16.840.
2b. DES 56 bit CBC(Voice encryption using DES in CBC mode and 512-bit DH-group):

2.16.840. – id-aes128-ECB
2.16.840. – id-aes128-CBC
2.16.840. – id-aes128-OFB
2.16.840. – id-aes128-CFB
2.16.840. – id-aes128-GCM
2.16.840. – id-aes-CCM
2.16.840. – id-aes192-ECB
2.16.840. – id-aes192-CBC
2.16.840. – id-aes192-OFB
2.16.840. – id-aes192-CFB
2.16.840. – id-aes192-GCM
2.16.840. – id-aes192-CCM
2.16.840. – id-aes256-ECB
2.16.840. – id-aes256-CBC
2.16.840. – id-aes256-OFB
2.16.840. – id-aes256-CFB
2.16.840. – id-aes256-GCM
2.16.840. – id-aes256-CCM

Source :

About DH key exchange:
3. Diffie-Hellman,
4. rfc3526: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE),
5. Huawei VP9650(which claims having AES256 supported):

Add compilation time cost for each source file in make file

Encountered an issue of extreme long time compiling days ago, so we tried to add a time cost output in the Makefile to locate what on earth happened during the compilation.

There are two Makefiles need to be modified, one is Linux based Makefile, another is Android based Makefile

Linux Makefile:

## Rules
## Suffix rules
$(SRC_DIR)/%.o: $(SRC_DIR)/%.s
    $(CC) -c -o $@ $(CFLAGS) $<
$(SRC_DIR)/%.o: $(SRC_DIR)/%.cpp
    @now=`date`; echo "==========compile at $${now}"
    $(CC) -c -o $@ $(CFLAGS) $<


@echo "Compilation begin at `date`"
@echo Compilation in progress, please wait ...
@sleep 1
@now=`date`; echo "Compilation end at $${now}"

Test Makefile:

Android Makefile:
You need to modify NDK common make file,, to archive this, it’s locating at /path-to-ndk/android-ndk-r7c/build/core/

_CC   := $$(NDK_CCACHE) $$($$(my)CXX)

# Jacky, add timestamp to the compile output
# 1) for linux
# NOW := `date`
# 2) for windows
NOW        := %TIME:~0,10%

_TEXT := "Compile++ $$(call get-src-file-text,$1), start at: $$(NOW)"

$$(eval $$(call ev-build-source-file))

Test Makefile:

Finished my studies in USTC

Last weekend, from May 15 to May 17, I took a train to Hefei along with more than thirty classmates,
to attend the desertation defence, the final phase of the postgraduate study.

Those were really busy days for all of us, there were so much forms and paper works for
documentations and files waiting for us to fill, to print, to get them signed, to be sealed,
not to mention most of us still need to prepare and modify our defence PPT.

Most of the paper works were supposed to be done before we went to Hefei, so, frankly, I think that
our class teacher in Shanghai, who’s responsible only for the documentations, did not do her job well,
but nothing was.

Well, now it’s over, let the bygones be bygones, here I want to say I’m really happy that I passed the defence.
and also really sorry for those who didn’t get through the defence. Those professors were really tough, about 25% ~ 30% of us didn’t survive the defence, :'(

Here are some pictures shoot in the USTC.

A simple guide of starting use EasyRTC

Working on a Loongson( PC, goal is to make it a Meeting Terminal. Because its CPU is MIPS arch, there could be lots of unexpected problems, so the first thought hit us is WebRTC.

This post is the first step to research into this topic.

Continue reading “A simple guide of starting use EasyRTC”

A simple script to sync a forked repository with the source repository

The mechanism is simple like this:

1. Pull/Clone your own repository(which was forked from another repository) to a local PC.
2. Add remote source repository to a tag of the local copy.
3. Do local merge for the two repositories.
4. Resolve the conflications if exists.
5. Commit the local copy to your repository.
6. Done and do some check.

#Sync the forked repository with the original source

#1. First clone the repository of your own.
#Skip this step if you already have a local copy of your own fork repository
git clone
cd nginx-rtmp-module

#2. Add remote repository

#Add a tag for your repository and point to the origin source repository
git remote add jackyhwei

#3. Fetch the newly added tag source
git fetch jackyhwei

#4. Merge the newly fetched source to master
git merge jackyhwei/master

#Manually resolve the conflications if there exists
git commit -m "merged by jackyhwei"

#5. Push the codes to your repository. BTW: git push requires you input your username and password.
git push -u origin master

#6. Check local info
git remote -v  
git branch -a

If you’v made some modification for your own repository, there will be an error like below when you do the push:

Permission denied(publickey).
fetal: The remote end hung up unexpectedly.

It’s because you didn’t add a public key for your repository, use following script to add it:

cd ..
mv .ssh ssh_bak
ssh-keygen #this command will generate a public/private rsa key pair for you.
cd .ssh
ls #there would be two files: id_rsa and

Copy the contents in to your clipboard, and go to the repository administration web page, select the Deploy Keys menu, and Add the deploy key(which is in your clipboard) to it.

Try push again.

Have my blog theme changed

I was using PageLines’s Platform theme for over 3 years, I really liked it.
It’s simple, fast, and easy to use.

The only problem is Platform theme does not mobile friendly, it’s sucked when you visit my blog by your smart phone. And this became the root reason of my decision of replacing it with a new theme.

And the new one is Customizr, designed by Press Customizr. Not so freshing as Platform, but seems good to me when I visit my blog by my phone. Wish you’d like it too.

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

           <xs:element name="media_control">
                     <xs:element name="vc_primitive"
                                           maxOccurs="unbounded" />
                     <xs:element name="general_error"
                                           maxOccurs="unbounded" />

           <!-- Video control primitive.  -->

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

           <!-- Encoder Command:
                Picture Fast Update

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


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”