tag:blogger.com,1999:blog-40215389107726852482024-03-12T21:40:40.086-04:00The whole “9” yards!!It was a long way to get the snom m9 to the point where it is right now. Right from the source, this blog gives you some extra insight how this thing works, some tricks on how to use it a little better, and what might be included in the next firmware versions.SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.comBlogger54125tag:blogger.com,1999:blog-4021538910772685248.post-806300569687459702012-10-02T15:36:00.001-04:002012-10-02T15:36:25.999-04:00The m9r on Ringcentral<br />
A cloud-based business phone system uses the Internet to deliver all the features of an on-premise PBX—minus the costly setup and the bulky hardware. And since the Internet isn't bound to a specific location, a cloud-based PBX seamlessly integrates multiple locations and remote employees.<br />
<br />
RingCentral is one such popular cloud based phone system, designed to help small businesses manage mobile, fax, and email communications. Its products include RingCentral Office, RingCentral Mobile, and RingCentral Fax.<br />
<br />
So, today's blog shows how we got the snom m9r up and running with the RingCentral Office™ service.<br />
<div>
<h2>
Set up your RingCentral account: </h2>
<div>
<ol>
<li>If you don’t already have a RingCentral account, sign up with the service on their website. Add the number of lines and select No Device as your phone. </li>
<li>If you already have an account, use your existing lines or add new lines from the RingCentral service site using Add DigitalLines as shown in the figure below. Select Use Existing Device when prompted to choose a phone.</li>
</ol>
</div>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAmvymXxSRJvQCCJWF3RyLGIcZBw841NyF7ITns0DMXNUjUbnpVDfw_IacRuOZovaKJUwvyo2Flgd116n6b10ZX5bn9SuM5de6iqFRoB8XKb423FdBkHGnEv-jfnTLA5y1CgSEq-3AZIpl/s1600/RC1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="247" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAmvymXxSRJvQCCJWF3RyLGIcZBw841NyF7ITns0DMXNUjUbnpVDfw_IacRuOZovaKJUwvyo2Flgd116n6b10ZX5bn9SuM5de6iqFRoB8XKb423FdBkHGnEv-jfnTLA5y1CgSEq-3AZIpl/s320/RC1.png" width="320" /></a></div>
<div>
<h2>
Record configuration information from RingCentral:</h2>
<div>
<ol>
<li>After purchasing your lines, log in as an administrator and go to My Settings > DigitalLines. You’ll find a list of the lines you purchased.</li>
<li>Locate each line you wish to use with your cordless phone. Make sure the E911 column displays the word Edit.</li>
<li>Otherwise, click Failed and provide the e911 data.</li>
<li>Click Setup Instructions for each line you’ll be provisioning on your cordless phone. Copy each of the five fields shown in the figure below.</li>
</ol>
</div>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJzETLJxq6LoubRZySKRjhl0DrmaYHa_dym7lWwFzWGkOqnF9WXWSTlf-TnyLXs1S91Miuj98YGdseXPM4Gen2gitRS7ASeTnG4lovwyrzQQiCLrdbONI9AV88WtzWgZoLnrjIvWybsGCi/s1600/RC2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJzETLJxq6LoubRZySKRjhl0DrmaYHa_dym7lWwFzWGkOqnF9WXWSTlf-TnyLXs1S91Miuj98YGdseXPM4Gen2gitRS7ASeTnG4lovwyrzQQiCLrdbONI9AV88WtzWgZoLnrjIvWybsGCi/s320/RC2.png" width="299" /></a></div>
<div>
<h2>
m9r Account Setup:</h2>
<div>
<ol>
<li>On the m9r web portal, click on <b>Identity 1</b></li>
<li>From the <b>Server Type</b> drop down select <b>RingCentral Office™</b></li>
<li>Set <b>Identity active</b> to <b>on</b></li>
<li>Enter your RingCentral User name in the <b>Account </b>field</li>
<li>Enter sip.ringcentral.com in the <b>Registrar </b>field</li>
<li>Enter sip:sip.ringcentral.com:5090 in the <b>Outbound Proxy</b> field</li>
<li>Enter your RingCentral Authorization ID in the <b>Authentication Name</b> field</li>
<li>Enter the provided RingCentral password in the <b>Password </b>field</li>
<li>Press <b>Save </b>to apply settings</li>
</ol>
</div>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjH_o9m6kcNPorVbwvArNQbAgJf0M88Ay3TjtD6z1wKHxDzfPudG4j_3ONf6tgqwhxYdpODHsvK9DBo8sWu-Mb4gMsI6qMBFl5iqH2n4H0YmxO5_7HzKbSIW4LVK7N3T_mItKOMnXJ9CZxt/s1600/RC3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="207" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjH_o9m6kcNPorVbwvArNQbAgJf0M88Ay3TjtD6z1wKHxDzfPudG4j_3ONf6tgqwhxYdpODHsvK9DBo8sWu-Mb4gMsI6qMBFl5iqH2n4H0YmxO5_7HzKbSIW4LVK7N3T_mItKOMnXJ9CZxt/s320/RC3.png" width="320" /></a></div>
<div>
<h2>
DTMF Payload Setup:</h2>
<div>
<ol>
<li>Click on the <b>Audio </b>tab at the top</li>
<li>In the <b>DTMF Payload Type</b> field, change the default value to 101</li>
<li>Press <b>Save </b>to apply changes</li>
</ol>
</div>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg446oFpm5YWNYuV-kyjyy2cxN8Zp5xd0fSijK_5nQHvsm0GoXfdqRJrSKLCAuCjf04cSgTjwh6zaqzoToYYv34ER5Pf9JXkDHfcz-_smS_PPlv-fGsfvKjfkxxtej7Lx0_IkuJr43n4LWs/s1600/RC4.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="273" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg446oFpm5YWNYuV-kyjyy2cxN8Zp5xd0fSijK_5nQHvsm0GoXfdqRJrSKLCAuCjf04cSgTjwh6zaqzoToYYv34ER5Pf9JXkDHfcz-_smS_PPlv-fGsfvKjfkxxtej7Lx0_IkuJr43n4LWs/s320/RC4.png" width="320" /></a></div>
<div>
<h2>
Handset Assignment:</h2>
<div>
<ol>
<li>Click on the <b>Handsets </b>tab</li>
<li>Select all handset IPEIs that you want to be associated with your RingCentral account</li>
<li>Press <b>Save </b>to apply changes</li>
</ol>
</div>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRZfcek5Bb2VyRYK6aJt_5km5yhN1WOo9d-loQA-X4pSxMdY2uGrptr-XTlhx9mqqdBsY_5UGebCwXmkFNtrKJDbuvtTlgZIhsN_OSYaA6oMCZrPg1mXTbox5abUyodCdKfrkJW91jjDE-/s1600/RC5.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="89" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRZfcek5Bb2VyRYK6aJt_5km5yhN1WOo9d-loQA-X4pSxMdY2uGrptr-XTlhx9mqqdBsY_5UGebCwXmkFNtrKJDbuvtTlgZIhsN_OSYaA6oMCZrPg1mXTbox5abUyodCdKfrkJW91jjDE-/s320/RC5.png" width="320" /></a></div>
<div>
<h2>
Verify Registration:</h2>
<div>
<ol>
<li>Click on Status > Registration</li>
<li>Ensure that your configured account display 200 ok indicating a successful registration with the RingCentral Office™ service</li>
<li>Congratulations!! You are now ready to use the snom m9r with the RingCentral Office™ service</li>
</ol>
</div>
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgomNql1doeldZVnRAvmNL8UA62gaJyIwuOuD8EDBfZWmc6r-dV0ThxtuHt3VvUtYNV1y8JJ_QWdBlVABcu-i68dOISlS2dKtobJVLKkNyIhRPHspxl2Q3y6-MIHO5VnS2hIY72xDqOW1Bk/s1600/rc6.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="211" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgomNql1doeldZVnRAvmNL8UA62gaJyIwuOuD8EDBfZWmc6r-dV0ThxtuHt3VvUtYNV1y8JJ_QWdBlVABcu-i68dOISlS2dKtobJVLKkNyIhRPHspxl2Q3y6-MIHO5VnS2hIY72xDqOW1Bk/s320/rc6.png" width="320" /></a></div>
<div>
<br /></div>
SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com5tag:blogger.com,1999:blog-4021538910772685248.post-45294877827786499532012-09-01T01:48:00.002-04:002012-09-01T01:48:23.263-04:00The m9r is out
<span style="font-family: Calibri;">The m9r is out for a while now. While it took some time to
get the m9 to where it is today (thus the blog name “the whole 9 yards”), the
introduction of the snom m9r was so smooth that it was practically unnoticed.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">The m9r was modified only in areas that have very low risk
of bringing in instability. More memory never hurts in the computer industry,
and on the handset side there were improvements with the handset plastic and
acoustic. Also the antenna design was improved, giving the m9 a longer range
than the m9 had before.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">I believe that is okay. Stability is very important for the
users of DECT phones; fancy features are expected on smart phones but for a
DECT device, customers essentially want no surprises. The m9r is essentially like
a facelift in the car industry, when they change the bumpers and throw in a few
more extras. <o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">The big question will be if we should come out with m9r
firmware releases that take advantage of the increased memory. For example, I
saw the comments on ZRTP: We did not include ZRTP on the regular builds because
it takes up too much memory for stable operations in the m9. But we could
include that in the m9r builds where memory is not such a problem. For now, we
do this only for special builds and prefer to keep both variants with the same
software. It does not only make our life easier, it also important for the m9
users that they continue to have access to the latest firmware.<o:p></o:p></span></div>
SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com6tag:blogger.com,1999:blog-4021538910772685248.post-36641097751033277532012-07-30T01:03:00.002-04:002012-07-30T01:03:33.581-04:00M9 and snom ONE<span style="font-family: Calibri;">More than two years ago, snom decided to add another product
to its portfolio: the snom ONE software, formerly known as pbxnsip. The product names had both single-digit numbers in it, and this seemed to be a good starting point for a close integration.</span><br />
<br />
<span style="font-family: Calibri;">The m9
supported the pbxnsip software already for a longer time; so supporting snom
ONE was a simple task. For a certain time, both server types were available;
however over time they were merged into the snom ONE server type.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">Having two products from the same company implies that the
interoperability works slightly better than with other vendors. For a DECT
handset, the potential for doing this is not as high as for a desktop phone, but
there are optimizations that should make the usage of the m9 as easy as
possible. <o:p></o:p></span></div>
<span style="font-family: Calibri;">For of all and probably most important, the plug and play mechanisms
of the snom ONE are supported in the snom m9. The m9 supports the multicast
discovery of the snom ONE, and both devices trust the snom Root CA, so that a certificate-based
client and server authentication and secure provisioning is possible. In other
words: Enter the MAC address of the m9 in to the extensions where handsets
should be deployed, plug the m9 in and you should be all set. There is only one
little glitch left, which is the assignment of the mobile parts to the extensions;
but most people should be able to figure this out when looking at the display
of the handset.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">The provisioning makes sure that the connection between m9
and snom ONE is as secure as possible. Both TLS and SRTP are being used by
default. The encryption on the wire is probably better than the encryption on
the air (DECT). The snom ONE also provisions the PIN for registering the
handset to the base; this is a common pitfall when the PIN is not four digits as
the DECT base supports only four digits.<o:p></o:p></span></div>
<span style="font-family: Calibri;">Because the m9 also sends RTCP-XR reports, the voice quality
reporting per each call should help monitoring the connection quality on the
wire. However as the connection in the air is digital, signal strength has not
been taken into account and this would IMHO be difficult to achieve. A weak
signal does not mean that the user experiences degraded voice quality. The
quality degradation is actually quite abrupt; to have a fair evaluation about
the bit error rate the handset would have to send quality reports back to the
base; which I believe is not a feature in DECT.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">On the feature side, there is not too much to provision. The
handsets don’t have any buttons that could be programmed. M9 users have to use
star codes to get things done. The only exception to this is calling the
mailbox. Establishing a conference is done locally on the base, so that one
does not count.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com2tag:blogger.com,1999:blog-4021538910772685248.post-2216687606677562792012-06-25T10:20:00.001-04:002012-06-25T10:20:49.424-04:00M9 and Asterisk<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">Asterisk is the most popular open source PBX. There must be
millions of Asterisk-based installations out there. When comparing Asterisk
with other PBX from Cisco, Avaya, Mitel, or others, the thing that is most
obvious to me is it level of interoperability that invited and still invites
many manufacturers of devices and software to integrate with Asterisk. This is
the counterpart of the closed system where the warranty ends if you bring your
own device.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">We see that many of the snom m9 devices are used in
environments that use some kind of Asterisk. While snom has its own PBX snom
ONE, snom devices are still highly interoperable with all kinds of PBX in the
market. It makes a lot of sense for snom to make the interoperability with
Asterisk as smooth as possible.</span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">The m9 has a slightly different concept than the desktop
phones: Instead of having a seemingly millions of different configuration options,
it has one drop-down per identity that determined the interoperability mode
with the used registrar. Instead of having to figure out how to set each option
right for your installation, the m9 comes with a pre-programmed list of
servers. When selecting Asterisk, a few things like ICE and presence
publication are automatically disabled. So just select the right dropdown and you should be all set picking the right settings for Asterisk. </span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">We even brainstormed what we
can do to improve the interoperability with Asterisk, but not much came to our
mind. Newer versions of Asterisk support TLS and SRTP; on the forums we saw
some hiccups with long TCP packets that seem to be fixed with the latest
Asterisk version. On the m9 side, it seems there is nothing else that we can do
to make this work better.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">One interesting development where the Asterisk and snom m9 combination
could become interesting is IPv6. Both Asterisk and the snom m9 are on the
leading edge when it comes to IPv6. I personally know about an Asterisk snom m9
IPv6 deployment; it seems that this is working well.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">When it comes to Asterisk interoperability, it seems that
the m9 is in a good shape and we are running out of ideas what to do next. Improvements are more of a general nature that
applies to all PBX systems. If anybody has an idea how the Asterisk integration
can be improved, it would be interesting to get that feedback.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com2tag:blogger.com,1999:blog-4021538910772685248.post-73274410529183523792012-06-14T16:51:00.003-04:002012-06-14T16:51:45.949-04:00Another IPv6 Day<span style="font-family: Calibri;">On June 6<sup><span style="font-size: x-small;">th</span></sup>, there was another IPv6 day. As the
snom m9 is one of the few devices that I know of which supports IPv6, that day was
a special day for us. We know that a few folks are using IPv6 with the m9, but
honestly it would be great to get more feedback if we are done with the IPv6
support.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">It seems the biggest change was that Google added an AAAA
record for the email server address. That screwed a lot of email clients up,
and I am not sure if Google kept the records or just had set a very long TTL,
so that the problem did not go away on the next day. Actually, if the m9 would
have been exposed to IPv6 and the SIP server also supports IPv6, the transition
should have been very smooth. The user should not have even noticed it. I don’t
believe many m9 users actually had that experience.<o:p></o:p></span></div>
<span style="font-family: Calibri;">My biggest concern is that the firewall manufacturers will advertise
NAT as a security feature also for IPv6 and the purchase departments are too
clueless to find out that this is nonsense. The idea of a 50 USD router with
the IPv6-ready logo sticker on the gift box scares me. Probably we only have to
wait until some smart-ass lawyer sues a router manufacturer because they
exposed “private” IPv6 address to the public, and a badly configured PC in the
LAN gets hacked (that’s why we have stickers on the microwave telling us not to
put mister hamster into the device). Then all legal departments of the router manufacturers
in the world will take over and mandate that addresses in the LAN are not
exposed to the public, evil internet. I even hear that they are now trying to
put that functionality into the Linux kernel, so they say, to make sure that at
least the NAT implementation is not as buggy as with IPv4. If that should
happen, the whole exercise with IPv6 was for nothing and we will still
associate VoIP with on way audio: Can you hear me? Maybe not hearing the other
side is a security feature, for some people. Not for me.<o:p></o:p></span><br />SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-9574592801182528012012-05-18T09:34:00.002-04:002012-05-18T09:34:49.891-04:00No more DECT from Polycom?!<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">Just one day after the news that the Polycom DECT handsets
are now certified for Microsoft Lync, Polycom sold the cordless unit to a
private equity firm for half the price that they paid five years ago. Polycom
was perceived as a major player in the DECT IP world, do we have to be
concerned that this is the beginning of the end of DECT?<o:p></o:p></span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">I don’t think that this move was so much about DECT. Most of
the price that Polycom paid for the unit was actually for WLAN-based
technology. I cannot agree more, WLAN-based handsets are <span style="font-family: "Calibri","sans-serif"; font-size: 11pt; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-font-size: 10.0pt; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin;">an </span><span style="font-family: "Calibri","sans-serif"; font-size: 11pt; mso-ansi-language: EN-US; mso-bidi-font-size: 10.0pt; mso-bidi-language: AR-SA; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-fareast;">endangered
</span>species. In an
age where it is almost impossible to get a smart phone without camera and WLAN,
making WLAN handsets is destined to a very small market niche. The list of
failed vendors trying to make a WLAN-based handset is long. Voice remains a
very important application in the LAN (wireless or not), and DECT continues to
provide a solution that fits the needs. Looking from the outside I would say
that the DECT handsets were so much embedded into the cordless unit that they
had no choice but to sell it off as well. <o:p></o:p></span></div>
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">Selling the business unit does not mean that the unit gets
shut down. It will be interesting to see what the next moves are in the WLAN
and in the DECT space. My guess: They just OEM a smart phone and put software
on it for the WLAN part, and continue what they did before on the DECT side.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-40858714780639037122012-04-25T13:14:00.001-04:002012-04-25T13:14:54.155-04:00Virtual LAN<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">Everybody is talking about virtualization today. Virtual
servers, virtual classes, virtual anything. There is one more thing: The
virtual LAN.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">It must have been around the end of the 1990s when they
introduced VLAN. It was a big topic, because many Ethernet devices could not
deal with it; it is not 100 % backward compatible with the good old LAN. The
core problem was that the packet got 4 bytes longer, and that could break the
MTU, so that the last bytes did not make it any more.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">Admins can just run a physical LAN cable and then split it
up into different “virtual” LAN, which behave pretty much like physical LAN. The
main difference is that that physically available bandwidth now needs to be
shared with the different LANs. This raises the question which packets get
routed first, in case that not everything fits into the LAN. With the introduction
of VLAN, you can also say bye-bye to the idea that there is a fixed bandwidth
like 100 MB/sec. That’s why they introduced priority bits, so that you can have
up to eight different priorities. And that’s something that is useful when it
comes to VoIP; because you want to make sure that voice packets don’t get
dropped when there is a lot of traffic.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">This actually works quite well. I remember someone called me
up on the VoIP phone, screaming “the LAN is down!!!” After a short moment, I asked
“how can you talk to me if the LAN is down”, and then I realized that we
actually were using the VLAN. It turned out that there was a loop in the LAN,
but fortunately on a lower priority than the voice VLAN, so that even under
such a bad situation the voice packets made it. Voice is more important than
data.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">VLAN typically have 12 bits, and 3 bits for the priority. There
is a lot of stuff around those bits, for example the question who is allowed to
be in a VLAN, what quality is allowed in which VLAN, and so on. Switches have
to work together with the devices, and if you want to have a waterproof system,
there is a lot of work to do to have everything set up properly. What most people
do is to pick just a VLAN number like 128, and just hope that nobody abused the
VLAN for bad stuff. In most LAN that is okay, the setup is easy and the gain
from that is good.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">However, talking about the cloud, VLAN are also available in
the cloud. When service providers offer metropolitan Ethernet, 4096 VLAN are
not enough anymore. So they came up with another VLAN type, which can have
millions of different VLAN, so that the service provider can offer a couple of
VLAN to their customer. IMHO that is very cool. The virtual LAN extended into
the Internet. Rent a DHCP server in the cloud! Fortunately, there is a backward
compatibility into the on-premises VLAN, so that existing devices don’t have to
worry about it. And the quality of service can also be guaranteed, so that
voice packets don’t drop.<o:p></o:p></span></div>
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;">
<span style="font-family: Calibri;">Of course everything works fine with the m9.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com1tag:blogger.com,1999:blog-4021538910772685248.post-52422686922307779582012-04-12T10:13:00.000-04:002012-04-12T10:13:38.301-04:00EULA?<span style="font-family: Calibri;">For those who update the m9 recently, you might have noticed that you have to accept the “end user license agreement” before you can actually do something in the web interface of the snom m9. What’s going on here?!<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Generally speaking, when customers purchase software, they have to accept to the terms and conditions for using that software. This is standard practice for software in the IT industry and there are actually no big surprises here. However, on a VoIP phone that is not so popular yet.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Some vendors prefer to ship a EULA paper. In my opinion, that is a waste of resources. If they are hidden in a stack of other paper documents in the gift box, it also does not help to make the situation more transparent.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The snom m9 is a product that is heavily geared towards software. Most of the value that comes with the device is software, and so it is logical that the software rules also apply to the device. However, it is still a little bit unusual to have to accept a license agreement on the first login.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">There are examples of modern devices that do the same thing. For example, when you purchase an Apple device, you have to go through the various steps of setting the device up. This includes the acceptance of the end user license. The good news about accepting the EULA is that you are actually officially allowed to use the software. I was always wondering if someone would be allowed to use it without a license agreement.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">It does not only allow the customer to use the software; it also makes clear under what circumstances that is allowed. For example, it would not okay to use the snom m9 software or some parts of it on a “clone” device (if that would ever become available). I think that is quite understandable: snom does not program all that stuff so that competitors purchases one device with legal software on it and then copy it onto their own platform. The EULA makes that clear.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The other thing is that the snom m9 does from time to time reach out into the Internet to check for provisioning data or to tell the snom server, what software versions are running on the device itself and on the registered servers. While the central provisioning (snom Active) has obviously the advantage that you can plug a device into the network without touching and if its configuration data, the reporting of software versions is important for making decisions where to focus development on. Many vendors don’t even mention that in their EULA, the snom m9 EULA clarifies that as well.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Other topics in the EULA circle around the standard lawyer topics warranty and liability. The warranty deals only with the software part (who can claim to have bug free software?), the hardware warranty is a different topic and depends on the country where the device was actually purchased. The liability part is a necessity in today’s business life to make sure than small glitches in the software do not end up in huge payments for the company. If you are running a company yourself, you will know the topic. Then there are other parts which you find in all EULA that discourage people from selling the product into countries where they should not be. Although it is hard to imagine for me how you would turn an m9 into a missile, from a legal point of view, it is better to have that covered in the EULA as well.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The acceptance of the EULA might seem to be another bureaucratic move. However in today’s business life it has become a necessity and the good news is that it is in electronic form: no trees needed to be chopped down to make it happen.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-28129395929612715832012-03-30T13:26:00.000-04:002012-03-30T13:26:19.745-04:00The handset weight<span style="font-family: Calibri;">You might that the weight of the handset is a simple topic. It is not. There are two groups that can just not be made happy with the same device.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Group number one believes that a handset should be as light as possible. This is because they don’t like to hold a heavy brick in their hands for too long. Exercise is a topic for the gym, and not everyone finds massive shoulder muscles attractive—especially on women. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The other group wants value, and from a psychological point of view it is understandable that more weight of a handset suggests there is more value inside. If it feels heavy, it must be good. Also it sounds much more massive when it drops on the floor. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Let’s take a look at the reasons behind the handset weight.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">A cordless handset must pass a test called the “drop test”. We know that from the crash test for cars: If you want to sell a car it has to pass it. When the handset falls on the floor, it must not break. It is okay if it opens, as long as the user can still put it together. But plastic breaking off is not okay. The drop test is easier to pass if the device if the device is not so heavy, especially on inside components that don’t actually contribute to stability. A heavy battery can be a major problem for the drop test. What manufacturers do is to make certain parts like snap-ins stronger until it can pass the drop test. As a general rule, a lighter handset makes the drop test easier. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Weight generally speaking costs money. For example, devices have to be shipped from the factory into the warehouse, though that is not a major factor. Other cost factors are the plastic prices, which are also not a big point. We can say that more weight does mean more value, but not much.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">A heavy battery is an important factor in Wifi phones, so that they can actually survive the day in the world of MB/s. DECT phones are much less power hungry, and even a cheap battery with a weight of an ounce can survive a week without seeing the charging station. It is technically no big problem to make a light DECT handset with a battery strong enough.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">With the decision from Apple to make cell phones out of full metal, it has not become easier to convince people that light handsets are the way to go. I believe this is unfortunate. From a pure functional point of view, a paper-weight device would have been much “cooler” that a heavy device. My advice for the proponents for heavy handsets is to change the side regularly, so that both shoulder muscles end up with the same size. As for the m9, snom could resist to follow that trend and focus on the functionality aspect of the handset, where lighter is just better.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-35930578125221664902012-03-22T14:20:00.000-04:002012-03-22T14:20:25.931-04:00The memory monitor<span style="font-family: Calibri;">Memory in embedded systems is a limited resource. The m9 has just 16 MB RAM on the base station, and even the upcoming m9r has only 32 MB RAM. That used to be a lot in the 1990s, but today this is almost nothing. Because of this, the design of the m9 had to keep the memory usage in mind. After the motto “what you see is what you get” the m9 has a memory monitor that checks the memory usage of the last 24 hours.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">But what is free memory? That is a little bit hard to say in the Linux environment, because the operating system tends to keep things in memory that are not actually needed. In order to speed up later loading, this makes sense. But for the accurate measurement of how much memory is exactly free, the number might be misleading. The m9 reads every 6 minutes the file /proc/meminfo from the operating system, and then stores the number which is in the “MemFree” line. You get a picture like this:<o:p></o:p></span></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiskzFuuHEuMOY7F748QLSPeIlGa90xkJuN7iyweVji0qypDqdvf3cRiOWplrqtdVE8COkA9wB3lrgVzLlQazZXCPWdT1L45UV076jAm3hW_N8UAKIUZzqMEptzPmBpYwAs7hBaA3q_IDV/s1600/m9mem.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="166" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiskzFuuHEuMOY7F748QLSPeIlGa90xkJuN7iyweVji0qypDqdvf3cRiOWplrqtdVE8COkA9wB3lrgVzLlQazZXCPWdT1L45UV076jAm3hW_N8UAKIUZzqMEptzPmBpYwAs7hBaA3q_IDV/s320/m9mem.png" width="320" /></a></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">As you can see, the memory is not a one-way street down to zero. The operating system sometimes frees some memory too, and then the graph jumps up again. However, when the graph gets into the area where only a few hundred KB are available, things get tight. This might happen if you have a busy system, and for example all accounts use Microsoft Lync registrations. Well there is a reason why the m9r has more memory.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Anyway if the m9 should really run out of memory, it does some desperate measures. It actually writes a file with some booting information, so that on the next reboot you can see on the status screen why the device was rebooted. After the writing of the file, it does reboot. This is ugly, however just hanging there doing nothing would be even worse. <o:p></o:p></span></div><span style="font-family: "Calibri","sans-serif"; font-size: 11pt; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-font-size: 10.0pt; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin;">Once that the system is running, the probability that the system is running out of memory is relatively low. Most of the memory is taken during the provisioning and registration phase and after making the first couple of calls. After that, the device has only a few reasons to allocate more memory. The goal with the m9 and with every other embedded device is that it should be running forever without ever running out of memory. The biggest practical obstacle for this is the software update. Unfortunately, updating software that is actually running is very difficult and as with the most embedded systems, the m9 requires a reboot after a software upgrade.</span>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-36319229771097422772012-03-12T06:37:00.002-04:002012-03-12T06:37:42.763-04:00Voice over TCP<span style="font-family: Calibri;">In the last blog, I was talking about SIP and TCP and it would have been a great idea to use TCP as the default transport layer for SIP. When it comes to media, TCP has some disadvantages.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The overall problem is delay. Voice is an application where you want as little delay as possible. The only other application that I can think of is online shooter games, where you literally need a low latency to survive against your online enemies. If you are behind a slow DSL line, you’ll probably get shot down before you can even see what is going on.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">With voice you won’t get shot down, but the conversation gets bad when the delay is too long. The first obvious problem is that both parties start talking all the time, which makes a conversation very unnatural. The other big problem is that there is still some small echo coming back mostly from the handset cord from the other side. Even if it is very low, if you have a long delay, you can hear it and it feels uncomfortable. So with voice, you want as little delay as possible. 40 ms delay is great, 80 ms gets to the limit already.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The problem with TCP is that when packets get lost, the TCP subsystem has to repeat the last packet and that might take a long time. On the other side, when the packet finally arrives, the audio buffer has already an under run and it is better to just drop the packet and play the next one immediately. That is why it is better to use UDP for audio.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Video might actually be a different story. Packet loss for video is a much bigger problem than for audio. Because of the high compression for video, a lot packet really screws the screen up. For video it would make sense to use TCP transport layer even when there is a risk of packet loss.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">All that said, there is still an increasing demand to use TCP for voice as well. The problem is that in many environments, the firewall blocks UDP traffic. This is either because the firewall is not able to support too many UDP sessions, but maybe it is because the firewall should actually block voice traffic (for example in the hotel). Then TCP might still be a possibility. The price is an increased average delay, but if you have the choice between a conversation with a long delay and no conversation, you might choose the long delay.<o:p></o:p></span></div><span style="font-family: "Calibri","sans-serif"; font-size: 11pt; mso-ansi-language: EN-US; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-font-size: 10.0pt; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: "Times New Roman"; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-fareast; mso-hansi-theme-font: minor-latin;">The support for that is still weak (so far only in Microsoft Lync environments as far as I know). However as more and more environments support it, your m9 might eventually pick TCP transport layer for voice eventually.</span>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com2tag:blogger.com,1999:blog-4021538910772685248.post-77661532316542081522012-03-04T06:55:00.001-05:002012-03-04T06:55:47.987-05:00SIP, UDP and NAT<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Writing about SIP and NAT could fill another blog. This problem was neglected in the SIP standard. Maybe this was done to push the need for IPv6; however for sure whoever had this idea did not make our life easier over the last ten years. NAT remains a major pain in the neck for the whole VoIP world.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">For those who don’t know NAT: This is “network address translation” and it deals with problem that there are less IPv4 addresses in the world than there are telephone numbers in the USA. The trick is to abuse the port numbers for addressing purposes. Essentially what it does is to put 16 bit behind the 32 bit IPv4 address, so that we have 48 bits for addressing a service in the Internet. That is the same number of bits that we have for Ethernet addresses, where so far that number was sufficient. That trick worked well enough to keep the service providers upgrade to IPv6. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The other major problem in SIP was that it mandated the support for the UDP transport protocol. This is not only a pain in the neck for the poor programmers who have to deal with message repetition all the time (and which may explain the poor code quality found in many products). This is also a problem for the message size. Try to send a UDP packet with more than 1500 bytes; you will get a lot of “funny” effects. This is called UDP fragmentation. The problem behind it is that the packet cannot be sent in one packet over the network, so it has to be split and reassembled on the other side. While the splitting up usually works, most of the cheap routers available in the real world don’t reassemble the packets and even many SIP devices are not able to do the same job. In other words: If you have a very long name and you name is included in the SIP packet, your phone will probably not ring. Okay, most people don’t have names with 1000 characters; however with the advance of SIP there are so many extensions that make the packet longer. And you end up with packets that don’t make it through NAT. Nice. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Life could have been so easy. All that the SIP authors should have done would be to use TCP transport layer. Then on the signaling side we would not have fragmentation problems and even NAT would work without major glitches. The argument that servers don’t scale well with TCP is frankly from another world, looking at HTTP and Email traffic today (all on TCP). <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The m9 supports UDP (including fragmentation, thanks to Linux), TCP and TLS. Whenever you can, my suggestion is to use TCP or TLS to minimize the trouble with NAT. Especially when operating the m9 behind a cheap router. Luckily, most SIP server software today supports TCP. Some of them even don’t support UDP any more (like Microsoft Lync), which is good news.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">For the media side, even if SIP would have used only TCP, NAT would have always been a problem. For media, you want short delays. That means you want to send the packet directly between the devices if possible. And that means you have to use UDP. So even if your signaling is working okay, you would still have to fear that your voice connection would not make it. There is a solution for that called ICE, but that is a topic for another long blog post.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com1tag:blogger.com,1999:blog-4021538910772685248.post-68725069558252423402012-02-22T10:25:00.000-05:002012-02-22T10:25:34.943-05:00Where is my handset?!<span style="font-family: Calibri;">Mobility is a feature, but it can also be a problem. Where did I put the handset? Because the handset does not have a cord to the base station, it is easy to displace it. The m9 has a couple of features to locate the handset.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The first one you might have seen in the web interface. There is a button called “locate handsets”. What this button does it to call all registered handsets. So if still both of your ears work properly, you will be able to figure out where your handsets are (an amazing feature of the brain to locate audio sources in the room).The problem with this procedure is that it is quite disturbing, especially at night. If you belong to those who use the m9 at home, you want another way to locate your handset in the dark.<o:p></o:p></span></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhULXWKQxPwoiPKeGSEMUGLS0l7_Fq7jt_nT3LIpkyjULEjzcQW_8s7qKQnZaT89kN37TktVjHIkZExhDX3KSxgbiE9qacwEMvOY34Zki1q4KA70siAX7Djvg2nrzfLtbO1Dx_4g_VJuHes/s1600/Capture.GIF" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="226" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhULXWKQxPwoiPKeGSEMUGLS0l7_Fq7jt_nT3LIpkyjULEjzcQW_8s7qKQnZaT89kN37TktVjHIkZExhDX3KSxgbiE9qacwEMvOY34Zki1q4KA70siAX7Djvg2nrzfLtbO1Dx_4g_VJuHes/s320/Capture.GIF" width="320" /></a></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The answer is that the handsets shortly turns the handset key backlight on, so that you can see it. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">This can be disturbing. The answer to that problem is to just put you handset down with the keyboard to the table, and then the visual disturbance should be minimized. You can also turn the blinking off from the handset menu. I believe there was a bug in the old versions; hopefully it was fixed in the meantime. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">It is debatable what should be the default. Apart from the visual disturbance, it actually does suck battery power. Right now the default is to it on. I assume that is a kind of feature advertisement. For those who don’t need it, it is probably a good idea to turn it off.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The other way to locate your specific handset is to just call it from another phone.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-67814126948678115302012-02-16T16:53:00.000-05:002012-02-16T16:53:44.283-05:00What’s a link-local URL?!<span style="font-family: Calibri;">IPv6 is still pretty much unknown in the IT world. When m9 customers log into the web interface and navigate on the status screen, they are stumbling upon a thing called the “IPv6 Link-Local URL”.<o:p></o:p></span><br />
<br />
<div class="separator" style="clear: both; text-align: left;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxwFjy8riMg8US5z3ZgNgqF6tqeAWXVvFajcHdfBuNThJVWcPstHZaLIuhAfoRuRbP9LOx43QoE69w-61Tuf0cGC8CVr76oDt-p37LOz9yszBBLYMiP-Gm91mZ7I5l-Qv2oDYcQBMrXof2/s1600/M9_ipv6_2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxwFjy8riMg8US5z3ZgNgqF6tqeAWXVvFajcHdfBuNThJVWcPstHZaLIuhAfoRuRbP9LOx43QoE69w-61Tuf0cGC8CVr76oDt-p37LOz9yszBBLYMiP-Gm91mZ7I5l-Qv2oDYcQBMrXof2/s320/M9_ipv6_2.png" width="251" /></a></div><div class="MsoNormal" style="margin: 0in 0in 10pt;"><br />
</div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Generally speaking, link-local means that the address is only visible on the link, which means something like “interface” or “LAN”. For example, if your device would have to Ethernet ports, you could have two links, and you could actually have the same link local address on each of the links. It would not generate an IP address conflict, because the LAN will not route packets that are link local. While you usually have different MAC addresses for each physical interface, this case will be rather improbable. However, when VLANs are coming into the game, it is actual quiet probably that you will have the same link-local address twice on the device—one time for the regular LAN and another time for the VLAN. Hint: This will still not happen with the m9, because when a VLAN is used, the whole device will move into that VLAN.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Link-local addresses can actually also happen on IPv4. Those addresses use those 169.254.x.x addresses that you might have found on your computer when the DHCP server was not responding. They are not as popular as they are on IPv6. In IPv6 you actually need link-local addresses to get a “real” IPv6 address. DHCPv6 uses the link-local address in order to grab more IPv6 addresses.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">We put the link-local IPv6 address on the status screen for two reasons. First of all, we want to let everybody know, that the device has an IPv6 address and they can try this out just by clicking on the link. The other thing is that this address does not change—it depends on the MAC address, so it is pretty constant. That means if you store the link, you can always log into the device without having to know what the IPv4 address is or even without having an IPv4 address. We even wanted to print the link-local URL on the label on the bottom of the base station, so that people can just enter that link to access the device.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Generally speaking, in IPv6 it is absolutely normal to have more than one IP address. Apart from the link local addresses, IPv6 routers may send advertisements around (called RA—router advertisements) which announce subnets. The device may grab an address in the subnet and use it, without the involvement of a central server like a DHCP server. This is called stateless configuration. The problem with the stateless configuration is that is does not include a DNS server, which is also pretty important in IPv6 (who wants to enter those long IP addresses). That’s when the m9 sends out the DNS requests to a special DNS multicast address, called “all link local DNS servers”. Then when someone answers, it tries to stick to it. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The m9 always tries to grab another IP address from a DHCPv6 server. As stated before, DHCPv6 is quite different from DHCPv4, especially the fact that is was designed for multiple (redundant) DHCPv6 servers in the local link (this should make sure that the network is very robust when server should go down). At the end of the DHCPv6 process, there is still an IP address—an IPv6 address. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">If you have IPv6 RA or DHCPv6, you would find the additional addresses also on the status screen right below the link local address. If you want to get more information about the IPv6 configuration on your m9, you can still use the Diagnostics screen, for example to probe the /proc/net/if_inet6 file.</span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com1tag:blogger.com,1999:blog-4021538910772685248.post-22458771900904836192012-02-13T06:43:00.000-05:002012-02-13T06:43:21.257-05:00The M9R<span style="font-family: Calibri;">Soon the m9r will hit the market. This is not just a regular internal product update, which is quite common in the IT industry and usually invisible to the user, the letter “r” suggests that it is more than that.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">First of all, the letter probably stands for “range”. The m9 handset uses a new chip set which has an improved antenna performance. That means the range will be improved. Though the majority of customers will not really need this, it addresses those who are on the edge. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The other thing is that it will support the “repeater”. Even with the improved range, you can still double the distance by using a repeater in large offices and warehouses. Though I honestly think that the good old m9 also supports the router. Maybe the m9r is because the router is so close, we can already smell it.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Then there is more memory (which also has the “r” in it). More memory is always good to have, though the software does not need it at this point. But you never know what future software updates bring, and it never hurts to have more memory. Especially the handset has more memory; we were always very tight with memory there. Try to program something with a color display if all you have is 64 KB RAM. I believe now it is 128, still not the same of what you have on your smart phone, but at least twice as much as before. And also the base has now 32 MB RAM, so that we can probably take it easier with adding memory hungry features.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The other reason for the letting is the improved speaker (the letter at the end). This results in a better handsfree mode and a better playback for the ring tone.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Another thing that was changed is that the combo now has only one handset. This is sad because most people won’t realize they can register more than one handset per station. I guess the overall marketing rationale behind it was to get the overall price down. People can be very short-sighted when comparing prices.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The m9r continues exactly from where the m9 was. Regarding the maturity of the product this time it means there will be no big surprises. So the bottom line is that the m9r is a hardware upgrade, not a software upgrade.</span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com1tag:blogger.com,1999:blog-4021538910772685248.post-61912769975902631202012-02-06T15:16:00.000-05:002012-02-06T15:16:38.546-05:00Hosted plug and play<span style="font-family: Calibri;">Today I have a business idea.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">When I bought a Kindle from Amazon, I was pleasantly surprised that I did not have to set anything up. The only thing I needed to tell the device was the password for my Wi-Fi access point (it would have been scary if that step was also not necessary any more). But apart from that, take it out of the box, it was already charged, and as soon as the Wi-Fi password was on the device, I was ready to do my first purchase. Okay, go figure why this device cost only 199 USD.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Anyway, why don’t we do the same thing with the m9? Broadband is available widely, and all it would take would be someone who gets access to snom Active and sell the m9 on Amazon. After scanning the MAC address, all that would be necessary to set up a DID for the device, enter the according provisioning data into snom Active, maybe perform a test run to make sure everything is all right, and put the device into the hands of the parcel-service-of-your-choice. Even people who don’t know what VoIP is would be able to use this device as a telephone.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">It does not even have to be a real DID. For example, callcentric offers “virtual” DID numbers that cannot be dialed from the PSTN. This reduces costs for the service and makes it possible to just try the service out. Customers are still able to call each other on the network. This could make sense for people who have parents in far-away countries. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Ideally, the person who sells the m9 would already have the customer’s credit card number, so that recurring revenues AKA telephone charges could be charged every month. There are a lot of service providers that could do that. This would address a different customer base that the people who are using a softphone on their PC or smart phone. Think about grandma.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-74642457746929935052012-01-26T22:34:00.000-05:002012-01-26T22:34:05.203-05:00Why power over Ethernet makes sense<span style="font-family: Calibri;">Imagine a world where every country would have its own Ethernet connector. In this world mean that every switch would have a version for each country, possibly its own pin assignment, maybe even different speeds for the data. Vendors would have to produce for each country, keep inventory for each country and possibly also get certified with the Ethernet watch for each country. There are some people who see positive things with this, but at the end of the day it would mean that mediocre companies could lock competition out and I just can’t spot anything positive in this. <o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">This world is a reality in the world of power plugs. There are plug for the USA, for Australia, for the UK, for Germany, for Switzerland, for France, and possibly even more countries in the world and they are all incompatible. Isn’t that crazy? I guess the standards were done at times when politicians thought that locking down their country would be a good thing.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">There are other areas today where the industry purposefully introduced such country specific localization. Remember the last time you bought a DVD on your trip to far-away-country and wanted to play it back at home. Didn’t work! The DVD companies don’t like it when you purchase your DVD in China and play in back in Germany. This happened even without politicians I believe. It was just a way to maximize the turnover with countries where people are willing to pay more and countries where people on average are willing to pay only less.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">What does that all have to do with the m9? There are two things here as well.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The first is the power plug. The m9 also has to deal with the problem that different regions have different power plugs. So far we have three regions: USA, Australia and the rest of the world. For USA, the m9 comes with the two-bar power plug that we all know. Australia comes with the old UK-style power plug (also known from your last trip to Hong Kong) and some special certifications if you want to sell the device in Australia (like the lower ring tone). The rest of the world comes with a number of plugs that you can use in your specific country. snom also uses this to differentiate the price (like everyone in this industry does). So next time when you buy an m9 in the USA, don’t be surprised if it does not fit into the power plug in Europe. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The second thing is the frequency. USA could not allocate the same spectrum like most of the other countries. I am not sure if that was really a technical problem, or the USA wanted to make sure that there would be a different price level possible in the USA area. Anyway, that’s why there are two versions of the m9 handset today. snom had no choice, just follow the industry.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">What happened in the cell phone industry might also soon happen in the VoIP world. Like practically all cell phones today use USB for charging the device, vendors will stop sullying power supplies and instead point to Power over Ethernet. This will make the global supply easier; actually it will enforce more global competition, it will be more difficult to lock devices to a specific region, and at the end of the day customers will benefit from a global standard with a huge volume behind it. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">PoE can not only be used for powering DECT base stations, it can actually be used for a lot more devices. I think they are working on powering laptops on PoE, of course desktop phones and video camers. But even things like LED lights start to use PoE. When you build a new house, consider running an CAT5 cable to the ceiling instead of a regular power cable. It might all help to get the volume up and the prices down.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">I was personally never a fan of PoE. But thinking about it, I might actually become a fan these days.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com4tag:blogger.com,1999:blog-4021538910772685248.post-68352997404180017012012-01-19T08:48:00.002-05:002012-01-19T08:48:58.563-05:00The year of the hosted PBX<span style="font-family: Calibri;">So I have Verizon FiOS at home for more than half a year now. For those who are not familiar with that offering: This is a triple-play solution with TV, Internet and phone which comes to my home over a fiber. TV works beautifully, we can enjoy video on demand and the phone includes a flat rate for domestic (US) calls. <o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The phone service comes “of course” in the form of a analog telephone line. That part is disappointing. So they dig a fiber to my home, all just to convert everything into analog and then back to digital (practically all phones are digital today anyway)? That’s stupid. Anyway, still understandable because my home has an analog telephone line in each room, and typical Verizon customers don’t like to rip this out of the wall and replace it with Ethernet. So do I. What I did was getting a cheap analog DECT handset and connected to the line in the basement. All the telephone lines are useless in my house. DECT goes through walls.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">But of course that’s not all. Guess what, I also have a couple of m9 handsets in my house.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">They are registered to various locations. Practically for all snom offices, I have a registration. Some of the registrations are even using Lync; others are using snom ONE. My home deployment even stands the “wife test”: She actually uses it. If I would count the minutes, I would actually say that she uses the m9 more than the analog DECT line. Number one on her telephone usage list is the cell phone, no surprises here.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Anyway, the surprising thing is that the voice quality for our VoIP at home service is out of question rock solid. I should have started measuring the QoS reports, but it feels like we never missed a single packet. FiOS has a large upload capacity (a few MBit per second), which is a problem in other installations where uploading data has only very limited bandwidth. I think that is the difference to the situation a few years ago. People were dreaming about hosted PBX, and the concept hade a lot of sense; but the bandwidth was simply not widely available. That has changed.as the Apple folks would say “the times, they are changing”. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Essentially I am a user of hosted PBX with the snom m9. It works great, and it makes a lot of sense. This is something people will find out this year.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com2tag:blogger.com,1999:blog-4021538910772685248.post-44246541204676115102012-01-10T08:48:00.000-05:002012-01-10T08:48:02.243-05:00Happy New Year 2012!<span style="font-family: Calibri;">Time is racing, especially in the IT industry. 2011 was what it was, there were a lot of innovation but the overall economic environment wasn’t that great. Here are my predictions for 2012.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">My first prediction is that the m9 will finally have a repeater that you can buy. Seems like the repeater had to go more than just the whole 9 nine yards and there are still eleven months to go in 2012. My hope is that it would not take so long.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">My other prediction is that IPv6 will become a topic for VoIP. IPv6 had to go probably a hundred yards and back and forward and back again. But the pressure to move leave IPv4 behind is getting so big that people don’t have a choice any more. Check out </span><a href="http://ipv6.he.net/statistics"><span style="color: blue; font-family: Calibri;">http://ipv6.he.net/statistics</span></a><span style="font-family: Calibri;">, they have made some neat applications that show you the current picture. Hopefully people will realize that the m9 had IPv6 from day one and it is a great toy to try VoIP over IPv6.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Any my third prediction is that Microsoft Lync will take off on voice. I don’t know how many yards it did go, but for sure it was also a lot. When we started using it a couple of years ago (then known as LCS and OCS), there were many features missing to the degree of not being usable. Today, it is a different picture and people are realizing it. Certified or not, I am using my m9 on Lync every day and I am a happy user. Maybe the m9 even gets certified or tested or whatever the right description for that is. I am sure there are potentially more out there, and amid some dark projections for the business in 2012, I am sure that 2012 will be a good year for Lync and also for the snom m9.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">I wish you all a happy new year 2012!<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-16314349969891660862011-12-16T15:44:00.002-05:002011-12-16T15:44:15.762-05:00Simple transfer like in the good old days<span style="font-family: Calibri;">In the old days we were using a DECT system for the company (there was no VoIP at this time). I don’t recall ever putting a call on hold ever in my life before, but I do recall that I did a transfer. However not by using buttons on the handset, just physically: It was more a handover than a transfer. I just walked over to the person that should get the call and gave him my handset.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">While that sounds antic, it was very productive (probably because this was a small office). While walking I could still talk, thanks to the cordless nature of DECT. Then before the transfer, I could visually verify that the transfer target was ready to take the call. Then the handover was also very simple, just physically pass the device into the hand of the target. The only problem was that after he finished the call, I wanted the handset back. This probably explains why DECT handsets get displaced to easily (the m9 has a function to locate all handsets to address this problem).<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Key systems also used to be very productive. Unfortunately those systems were not in the favor of the IETF standardization committee and it is impossible to implement that with the existing standards. Seems like in the old days life was sometimes easier.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Anyway. Maybe nobody needs these features anymore because you cannot walk into the other person’s office any more if you are working from home. That’s something you could not do in the good old times!</span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-8671078835559951592011-12-08T09:33:00.002-05:002011-12-08T09:33:50.740-05:00Why software updates take forever<span style="font-family: Calibri;">When you update the base station, it takes just a minute to download the software and install it. However, when it comes to the handset software update, it takes much longer. This is surprising at first glance, especially because the handset has just something like 768 KB Flash memory.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The reason for that lies in the DECT protocol. DECT has many advantages when it comes to the robustness of the voice transmission over the air and the lifetime for the battery. Voice is being transmitted at a rate of 32 kBit/s in the core DECT specification, which is enough for a good audio quality. However, when performing a software update, the constant bitrate of the voice channel becomes the problem: 768 KB times 8 bit divided by 32 kBit is 196 seconds, which is 3:17 minutes. Add the overhead for securing the channel with checksums, acknowledgements and so on and you get ten minutes for updating the firmware over the air.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">We can actually be happy that the handset has just 768 KB memory. Imagine you wanted to update a 1 GB Flash over the air! It would take 4 days to update the software, if nothing goes wrong during that time. This also answers my question if it makes sense to have an Android based DECT handset: You need to have WiFi on the handset along with DECT. Wifi for the software updates and other miscellaneous data transfers and DECT for the voice calls. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Now it also becomes obvious why we included a USB connector in the handset. In the factory or even in the warehouse later, making a software update over the air for a large amount of handsets is not an option. Then it is much easier to connect the handset through USB and do the software update in a few seconds.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">This also explains why you need to manually update the handset. If we would automatically update the handset after a base firmware update, users would face an unpredictable outage for up to nine times ten minutes (1:30h). And if the handset is low on battery, it could get stuck in limbo during the writing of the software. This could drive people mad, including our support department. Therefore, we thought it is better to leave the software update initiation to the user and he can make the decision it is to update the software on the handset.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-81331788934761729262011-11-30T15:19:00.000-05:002011-11-30T15:19:09.819-05:00It is cloudy (with a chance of meatballs?)It does make a lot of sense to register the m9 in the cloud. For many small offices, most of the calls with go to an external number anyway and in all these cases, you do need a working internet connection anyway. Microsoft Lync hosted is one of the hottest topics out there right now. Many people say that Lync is primarily geared at the fortune 500 companies, but why not use it in a restaurant, a shop or in a dental practice? The technology behind Lync is complex; but the frontend to the user is actually pretty simple and users can enjoy many of the powerful features that come with Lync. So it is time to give it a test drive!<br />
<br />
First, we made sure we are running version 9.5.6 (or higher). Old versions had problems with some DNS failover, so you have to be sure to run that version. You can check on the wiki on how to perform software upgrades (see http://wiki.snom.com/Snom_m9/Firmware/Release). You can check this on the status screen of the m9 and should see something like this:<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjerqdDvVcReUaEeclphTjEHKoXMsMfS5xnG-JGIC1lSA2O7-GVDqcmE3uiFMDOVbuYmX1ghG8rYaSrY4AgoQ9jI1ZfPiI_NCAyy1F5Eg9-5oh4Y4M_haMKM_pRscgpImhNhcFz2FKKTsZe/s1600/pic1.png"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjerqdDvVcReUaEeclphTjEHKoXMsMfS5xnG-JGIC1lSA2O7-GVDqcmE3uiFMDOVbuYmX1ghG8rYaSrY4AgoQ9jI1ZfPiI_NCAyy1F5Eg9-5oh4Y4M_haMKM_pRscgpImhNhcFz2FKKTsZe/s1600/pic1.png" /></a><br />
Before you can register, you must either upload the Root CA for the certificate that SBC is using or just accept all certificates. You can do this also from the web interface of the m9:<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijykq6-kTyrLKONdodqSoiao6SUvleB4aQqcyCZGpZ8BBUhof_grR0gx0gTy4Fzw3E_vm_ErhyOCatA1CrYiwkWG-ptMU1IxvPy8d-eJ5aiDFqMMemqyPUNTxAk63-IF3_ZBHtG0ec16Ix/s1600/pic2.png"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijykq6-kTyrLKONdodqSoiao6SUvleB4aQqcyCZGpZ8BBUhof_grR0gx0gTy4Fzw3E_vm_ErhyOCatA1CrYiwkWG-ptMU1IxvPy8d-eJ5aiDFqMMemqyPUNTxAk63-IF3_ZBHtG0ec16Ix/s320/pic2.png" /></a><br />
Make sure that you select the right server type and that you want RTP encryption. In our example, we are using identity 6, but of course you can pick any other identity. Just make sure that you have a handset assigned to the identity if you pick something else than identity 1.<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVIUcMFxQ9P1LU0uoRF2zMTspApYxK1yniFoz988nCOVd_GuiDAwZ-rmFmzNEMUvY7vmBs8vdBYwSY0vWypv_3-aUgZk3WJsJAkTk9RZPhG-7Iv7fL3a7GHKsJlZO-Lqi0-sxEm_DmJYRu/s1600/pic3.png"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVIUcMFxQ9P1LU0uoRF2zMTspApYxK1yniFoz988nCOVd_GuiDAwZ-rmFmzNEMUvY7vmBs8vdBYwSY0vWypv_3-aUgZk3WJsJAkTk9RZPhG-7Iv7fL3a7GHKsJlZO-Lqi0-sxEm_DmJYRu/s320/pic3.png" /></a><br />
Then it is time set up an account for Lync. Fill in the information provided below and make sure that you activate the identity. The outbound proxy is “sip:sip.mshosted.net:5061;transport=tls”, it did not fit into the screen shot. You don’t have to fill in the mailbox, this will be automatically be filled in after the registration was successful.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgc6YTr4jyvM7N7Z5yWZWqJbjO80fT24njq-5fV9Z4V6chaeDoXWFBs1deUkKnbNDBEdoshzV_PoFImt75vdYkjAdeDZBxkKxWC6lCOrekZo72CLGWJCS6MsNMKw_NbMX-SZ0gGcJZCe6et/s1600/pic4.png"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgc6YTr4jyvM7N7Z5yWZWqJbjO80fT24njq-5fV9Z4V6chaeDoXWFBs1deUkKnbNDBEdoshzV_PoFImt75vdYkjAdeDZBxkKxWC6lCOrekZo72CLGWJCS6MsNMKw_NbMX-SZ0gGcJZCe6et/s320/pic4.png" /></a><br />
You can check on the status page (registration tab) if the registration was successful. You should see “200 ok” on the page. After that, should are able to make a call.<br />
<br />
<strong>Important disclaimer:</strong> The snom m9 has not been "officially" tested with Microsoft Lync. Use it at your own risk and fun.SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com1tag:blogger.com,1999:blog-4021538910772685248.post-70146580317781390632011-11-21T13:13:00.002-05:002011-11-21T13:13:50.178-05:00Yealink and DECT?<span style="font-family: Calibri;">I remember that Yealink had a DECT phone “W52”. It is not unusual that Yealink takes a look at what snom does, and then comes out with something similar. It looked like they did this also after snom came up with the m9.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">Anyway, when I searched for Yealink and DECT, there was a press announcement and you can even buy it on the internet. However the price seemed to be unusually high, so it seems that Yealink abandoned the product. Is that right? Maybe someone out there can comment on this.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">If they really abandon the product, this raises questions. Was the volume not high enough to keep the product alive? Does Yealink instead plan to come out with a WiFi phone to address cordless, even though snom did not do this yet? I can hardly imagine that Yealink ignores the cordless space. Let’s see, maybe there is a W53 coming around the corner.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0tag:blogger.com,1999:blog-4021538910772685248.post-64618955386768901692011-11-08T10:08:00.000-05:002011-11-08T10:08:18.800-05:00Routers and NAT<span style="font-family: Calibri;">IPv4 remains to be a pain in the neck. The biggest problem is that there are not enough addresses, and people need to do dirty tricks to keep the network up and running.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">One of the biggest problems is that routers have only a limited number of NAT UDP table entries. The problem is this: When a client in the private network sends a UDP request to the public Internet, the router has to remember from which private IP address and port the packet came from. It associates that address/port with a port on the public interface of the router. Obviously you can have up to 64 K ports on a router doing this trick.<o:p></o:p></span></div><span style="font-family: Calibri;">However, there are at least two problems. The first one is that most devices have a limited table size. For example it is not unusual to have just 32 table entries. So if there are 32 devices in the private network sending out a UDP packet, the router will have to drop old table entries to accommodate the new entries. Then when a response for an old port association will come back from the internet, the router will drop the packet.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">The problem is even bigger.<o:p></o:p></span></div><span style="font-family: Calibri;">Because this works okay when you use UDP for DNS. DNS is pretty much stateless here, and if the NAT table should have dropped the connection already, the DNS client will just repeat the request and the whole thing takes a little longer. But when we start using SIP registrations, dropping the NAT becomes random and sometimes (probably most of the times) it works fine, and then sometimes it does not work fine and you are missing incoming calls. That’s when people get frustrated. I don’t even blame them: It is very difficult to trouble shoot this problem. DNS and other UDP-based services work okay, but SIP traffic just gets dropped randomly. It is easy to point fingers at the SIP devices, but now you know, there is not much the device can do.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">What people do is making the registration interval shorter. I have seen registration intervals of five (5) seconds! This starts a kind of battle for the shortest registration duration, all contributing to a huge waste of bandwidth. It is almost like denial of service, but it keeps the service calls for the providers low. On the m9, I must say we were very hesitant to add support for STUN (market demanded it for those providers who cannot afford the luxury of a session border controller); but at least we made the default refresh interval very short to have a good chance to win in the battle for the ports, hehe. <o:p></o:p></span></div><span style="font-family: Calibri;">Is TCP the answer? Not really. In the real world, the number of TCP connections is also limited for the cheap routers and it becomes as erratic as with UDP. I have seen cases…<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 10pt;"><span style="font-family: Calibri;">This is madness.<o:p></o:p></span></div><span style="font-family: Calibri;">I can’t wait until we turn off IPv4 and use IPv6 instead. Lets hope for better routers. Cheers.<o:p></o:p></span>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com3tag:blogger.com,1999:blog-4021538910772685248.post-23667706464689950092011-11-04T09:32:00.002-04:002011-11-04T09:32:50.551-04:00Hello snom Active!<span style="font-family: Calibri;">There is a new service available from snom, called “snom Active”. <o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0in 0in 0pt;"><span style="font-family: Calibri;">This is a central provisioning system for installations where other provisioning is not available, e.g. no option 66. What happens is it goes to a central provisioning location and is maintained from that service. So if the device does not have a provisioning location setup yet, it will connect to the public Internet and download its configuration from there.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 0pt;"><span style="font-family: Calibri;">This kind of provisioning service was already from snom; however it was not a very well-known feature because it was very difficult and cumbersome to use. The new snom Active makes it possible to log in on distributor and VAR level and manage devices in bulk or individually. There are templates available; the whole configuration can be set up by snom Active (the previous snom provision mechanism was just a redirect service). <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 0pt;"><span style="font-family: Calibri;">New is also that the snom Active checks the client certificates from the devices. The m9 has certificates built-in, snom Active will actually verify that the device with the Mac address therefore it really is that device and not just a web browser in the internet trying to steal some passwords. Because snom Active trusts snom based certificates, this service is really plug and play and secure.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 0pt;"><span style="font-family: Calibri;">Use cases are like this: A VAR can manage the devices for different devices, so that they will automatically always fetch the right configuration, even if the customer decides to “play” with the settings. A factory reset will always get the devices back to the state they were during installation. If changes become necessary, they can be done on snom Active, not on the device. This solves some problem with firewalls where it is difficult to get access to the device.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 0pt;"><span style="font-family: Calibri;">Another use case is that a distributor sells the m9 preconfigured for a service provider to residential customers. For example, let’s assume that distributor D makes a deal with service provider S, and provides a DID number for each device that he ships. Then the customer who receives the device plugs the device in the network, and voila the devices fetches the configuration, sets up the registration and the customer can start making the first phone call without even knowing what an IP address is. This also makes a lot of sense for promotional purposes, because many service providers are already handing out prepaid accounts for trial use—once the small prepaid account is used up, customers are redirected to a subscription service where they can sign up for the real service; all on the phone. I believe this is really a killer feature that might be an inroad into residential customers, talking about customers that expect the simplicity of a PSTN installation.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0in 0in 0pt;"><span style="font-family: Calibri;">Please note that this service requires version 9.4.12 on the m9, because the previous versions did not check the location for snom Active.<o:p></o:p></span></div>SIP SIP SIPhttp://www.blogger.com/profile/16901301353101600663noreply@blogger.com0