<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rss version="2.0"><channel>
  <title>VOIPProducts.org</title>
  <link>http://www.voipproducts.org/rss/voipp_rss.xml</link>
  <description>You are viewing a feed that contains technical and generic articles about Voice over IP.</description>
  <author>robert@voipproducts.org</author>
  <atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" href="http://feeds.feedburner.com/Voipproducts" type="application/rss+xml" /><item>
    <title>VoIP and Caller ID</title>
    <link>http://www.voipproducts.org/articles/cid.html</link>
    <description>Caller ID (a.k.a Caller Line Identification, CLI, CID or Calling Number identification) is a process that allows a person receiving a call to identify the number of the caller.  Depending on the scenario and implementation&lt;img src="http://feeds.feedburner.com/~r/Voipproducts/~4/fzrHljVImAc" height="1" width="1"/&gt;</description>
    <pubDate>Tue, 28 August 2008</pubDate>
    <author>voipex@voipproducts.org (VoIPeX)</author>
  </item>
  <item>
    <title>Stun Protocol details</title>
    <link>http://www.voipproducts.org/articles/stunprotocol.html</link>
    <description>As seen in previous article, STUN protocol plays an important role in VOIP implementations; to discover the presence of NAT and to learn and use the bindings allocate to the client by the NAT&lt;img src="http://feeds.feedburner.com/~r/Voipproducts/~4/NMbJDxeHsBA" height="1" width="1"/&gt;</description>
    <pubDate>Tue, 15 July 2008</pubDate>
    <author>robert@voipproducts.org (Robert Abela)</author>
  </item>  
  <item>
    <title>STUN Protocol and VOIP Part 2</title>
    <link>http://www.voipproducts.org/articles/stunvoip2.html</link>
    <description>As seen in Part 1 of this article, STUN enables a SIP entity running behind a NAT to discover its public IP and what type of NAT is running on the gateway it is connected to.  It also enables the SIP entity to discover which port external SIP entities can connect to&lt;img src="http://feeds.feedburner.com/~r/Voipproducts/~4/hjz3rlAd82M" height="1" width="1"/&gt;</description>
    <pubDate>Tue, 10 June 2008</pubDate>
    <author>robert@voipproducts.org (Robert Abela)</author>
  </item>
  <item>
    <title>STUN Protocol and VOIP Part 1</title>
    <link>http://www.voipproducts.org/articles/article006.html</link>
    <description>STUN stands for Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs).  Typically it is used in several different network implementations and scenarios, one of which is in VOIP implementations&lt;img src="http://feeds.feedburner.com/~r/Voipproducts/~4/u5xt6sQTk0Y" height="1" width="1"/&gt;</description>
    <pubDate>Thu, 22 May 2008</pubDate>
    <author>robert@voipproducts.org (Robert Abela)</author>
  </item>
  <item>
    <title>Session Description Protocol (SDP) and VOIP Part2.</title>
    <link>http://www.voipproducts.org/articles/article005.html</link>
    <description>When a SIP based VOIP call is established, the audio or video sent between 2 SIP entities or more is streamed.  Since many different codecs are supported by different devices or software, and each individual SIP entity taking part in the call does not know the IP address&lt;img src="http://feeds.feedburner.com/~r/Voipproducts/~4/RUJV3xyB-XI" height="1" width="1"/&gt;</description>
    <pubDate>Thu, 1 May 2008</pubDate>
    <author>robert@voipproducts.org (Robert Abela)</author>
  </item>
  <item>
    <title>Session Description Protocol (SDP) and VOIP Part1.</title>
    <link>http://www.voipproducts.org/articles/article004.html</link>
    <description>When media is streamed in a SIP based VOIP call, being audio, or video, or both, one of the requirements is for the participants to know details about the media stream, i.e. transport address, transport protocol, codec, ports and other session description metadata.  SDP, also known as Session Description Protocol is the protocol used with SIP (session initiation protocol) to advertise such information.&lt;img src="http://feeds.feedburner.com/~r/Voipproducts/~4/qHSIvjEEPHw" height="1" width="1"/&gt;</description>
    <pubDate>Fri, 18 Apr 2008</pubDate>
    <author>robert@voipproducts.org (Robert Abela)</author>
  </item>
    <item>
    <title>Direct SIP explained (Direct SIP URI dialing).</title>
    <link>http://www.voipproducts.org/articles/article003.html</link>
    <description>If your telecom solution is running an IP PBX, it is possible to have your telephone "number" identical to your email address.  People using SIP based VOIP phones can call you by using your email address as dialing property.  Such solution is called direct SIP or direct SIP URI (Uniform Resource Indicator) dialing.&lt;img src="http://feeds.feedburner.com/~r/Voipproducts/~4/o_9j0Jm4cr0" height="1" width="1"/&gt;</description>
    <pubDate>Sat, 04 Apr 2008</pubDate>
    <author>robert@voipproducts.org (Robert Abela)</author>
  </item>
  <item>
    <title>Busy Lamp Field (BLF). How does it work?</title>
    <link>http://www.voipproducts.org/articles/article002.html</link>
    <description>Busy lamp field, BLF for short, is a light on an IP phone which tells you whether another extension connected to the same PBX is busy or not. This has to be configured manually from the phone user and it is usually done by making use of the web interface. When configured, the phone subscribes to a resource list available on an IP PBX to be notified with such information about other extensions. BLF works through the SIP protocol by making use of SUBSCRIBE and NOTIFY messages. In a normal scenario, the phone is the subscriber and the IP PBX is the notifier.&lt;img src="http://feeds.feedburner.com/~r/Voipproducts/~4/Tigv6P0SDh0" height="1" width="1"/&gt;</description>
    <pubDate>Fri, 14 Mar 2008</pubDate>
    <author>robert@voipproducts.org (Robert Abela)</author>
  </item>
  <item>
    <title>Why do we need secure VOIP? - SIP over TLS and SRTP.</title>
    <link>http://www.voipproducts.org/articles/article001.html</link>
    <description>Sooner or later VOIP will be one of the targets for malicious users who are always looking for new sources from where to get confidential data. By capturing VOIP calls malicious users can listen to calls and gather other information about the calls as explained later in this article. Telephone conversations with finance companies and banks, where security and PIN codes are exchanged can be a gold mine for such users.&lt;img src="http://feeds.feedburner.com/~r/Voipproducts/~4/CWqo3PZLIdA" height="1" width="1"/&gt;</description>
    <pubDate>Sat, 23 February 2008</pubDate>
    <author>robert@voipproducts.org (Robert Abela)</author>
  </item>
</channel>
</rss>
