<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Mi Brain-Training Personal &#187; Parallel Forking</title>
	<atom:link href="http://saghul.net/blog/tag/parallel-forking/feed/" rel="self" type="application/rss+xml" />
	<link>http://saghul.net/blog</link>
	<description>Para que no se me olviden las cosas...</description>
	<lastBuildDate>Mon, 06 Feb 2012 10:49:34 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Parallel forking, RFC3326 y los p*t*s fabricantes</title>
		<link>http://saghul.net/blog/2010/01/29/parallel-forking-rfc3326-y-los-pts-fabricantes/</link>
		<comments>http://saghul.net/blog/2010/01/29/parallel-forking-rfc3326-y-los-pts-fabricantes/#comments</comments>
		<pubDate>Fri, 29 Jan 2010 22:23:40 +0000</pubDate>
		<dc:creator>saghul</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Asterisk]]></category>
		<category><![CDATA[Parallel Forking]]></category>
		<category><![CDATA[RFC3261]]></category>
		<category><![CDATA[RFC3326]]></category>
		<category><![CDATA[SIP]]></category>
		<category><![CDATA[VoIP]]></category>

		<guid isPermaLink="false">http://saghul.net/blog/?p=1045</guid>
		<description><![CDATA[Una de las cool features que SIP soporta desde un principio es el Parallel Forking. La idea es sencilla, podemos tener nuestra cuenta de usuario registrada desde diversas ubicaciones y cuando nos manden un INVITE el proxy se encargará de mandarlo a todas las ubicaciones a la vez, y el que primero conteste la llamada [...]]]></description>
			<content:encoded><![CDATA[<p>Una de las <em>cool features</em> que SIP soporta desde un principio es el <strong>Parallel Forking</strong>. La idea es sencilla, podemos tener nuestra cuenta de usuario registrada desde diversas ubicaciones y cuando nos manden un INVITE el proxy se encargará de mandarlo a todas las ubicaciones a la vez, y el que primero conteste la llamada se la queda. De esta manera solo tenemos que gestionar una identidad,en lugar de tener varias cuentas SIP en plan &#8220;saghul_laptop&#8221; y &#8220;saghul_hardphone&#8221;.</p>
<p>Como no podía ser de otra manera Asterisk no soporta parallel forking, pero veremos más delante cómo algo tiene que decir en el tema del post.</p>
<p>En el diagrama de abajo podéis ver el flujo SIP de una llamada de Alice a Bob a través de un proxy (las respuestas provisionales se han omitido para simplificar):</p>
<p style="text-align: center;"><a href="http://saghul.net/blog/wp-content/uploads/2010/01/parallel_forking1.png"><img class="size-full wp-image-1050 aligncenter" title="parallel_forking" src="http://saghul.net/blog/wp-content/uploads/2010/01/parallel_forking1.png" alt="parallel_forking" width="487" height="447" /></a></p>
<p style="text-align: center; ">
<p>Bob se encuentra registrado en 2 ubicaciones, por lo que los dos terminales comienzan a sonar. Bob contesta en la oficina, por lo que el proxy genera un CANCEL al INVITE que va a casa, para que el terminal deje de sonar. Hasta aquí todo va bien, pero al volver a casa Bob verá que tiene X llamadas perdidas, llamadas que en realidad ha atendido desde la oficina. ¿Cómo solucionamos esto? ¡El <a href="http://www.rfc-editor.org/rfc/rfc3326.txt" target="_blank">RFC3326</a> viene al rescate!</p>
<p>E RFC3326 define una nueva cabecera para el método CANCEL: &#8220;Reason&#8221;. Mediante esta cabecera podemos indicar al terminal la causa de la cancelación:</p>
<p><code>Reason: SIP ;cause=200 ;text="Call completed elsewhere"</code></p>
<p>De esta manera el terminal puede saber si el CANCEL ha sido debido a que el llamante ha decidido cancelar la llamada o si ha sido el proxy el que ha generado el CANCEL porque la llamada ha sido contestada en otra ubicación. ¿A que mola?</p>
<p>OpenSIPS añade esta cabecera a los CANCEL que genera desde la versión 1.6 y Kamailio si no lo hace ya lo hará pronto (he visto esta <em>feature request</em> propuesta por un tal ibc <img src='http://saghul.net/blog/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' />  ). Sorprendentemente ¡Asterisk también soporta esto! Es decir, si haces un Dial(SIP/saghul&amp;SIP/manwe&amp;SIP/ibc) los CANCEL generados para los que no cojan la llamada tendrán esta cabecera presente. Es el parallel forking de los pobres, pero mola que Asterisk lo soporte.</p>
<p>¿Cual es el problema entonces? Pues que <strong>los fabricantes no implementan este RFC</strong>, que tiene 8 páginas, ¡8 jodidas páginas! Por lo que veo Snom es el único que lo soporta desde su versión 7 del firmware, así que si alguien lo prueba que me lo comente pliz <img src='http://saghul.net/blog/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  Y si encontráis otro terminal que lo implemente ¡comentad también!</p>
<p>Sin la implementación de este RFC el <em>parallel forking</em> pierde todo el carisma e incluso puede que gente lo vea como algo molesto. Por lo que a mi respecta voy a implementar el soporte para esto en cierto softphone, pero manda huevos que mi Cisco 7960 de Jack Bauer no lo haga&#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://saghul.net/blog/2010/01/29/parallel-forking-rfc3326-y-los-pts-fabricantes/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>

