<br><font size=2 face="sans-serif">Hi All</font>
<br>
<br><font size=2 face="sans-serif">I have recently downloaded Asterisk
and was so impressed I thought I would setup a home server and I went out
and got myself a couple of cisco 7940's. (and a sipaura 3000!). thanks
to various posts on this list and the voip-info site I have managed to
get chan_sccp setup and working with the 7940's but the I tried to get
the messages, services and softkeys working. It seems this is where some
sort of black magic needs to be used as I cannot find any way of getting
them to work.... which leads me to the main question....</font>
<br>
<br><font size=2 face="sans-serif">Is it better to use chan_sccp or SIP?
I know these phones can work in either mode I was just wandering which
is the better format and which has the most functions implemented?</font>
<br>
<br><font size=2 face="sans-serif">Its a simple home environment that I
am planning but it would be good to be able to use the softkeys to transfer
calls and to pickup messages.</font>
<br>
<br><font size=2 face="sans-serif">Thanks in advance,</font>
<br>
<br><font size=2 face="sans-serif">Sam</font>
<br>
<br><font size=2><tt>Kevin Walsh <kevin@cursor.biz> wrote on 27/08/2004
13:59:09:<br>
<br>
> Michael Manousos [manousos@inaccessnetworks.com] wrote:</tt></font>
<br><font size=2><tt>> > Kevin Walsh wrote:</tt></font>
<br><font size=2><tt>> > > Michael Manousos [manousos@inaccessnetworks.com]
wrote:</tt></font>
<br><font size=2><tt>> > > > a) The transmitter detected silence
and sent nothing but the last CN</tt></font>
<br><font size=2><tt>> > > > packet was lost. According to
the above interpretations, the receiver</tt></font>
<br><font size=2><tt>> > > > will try to conseal a packet loss,
which is wrong.</tt></font>
<br><font size=2><tt>> > > > </tt></font>
<br><font size=2><tt>> > > </tt></font>
<br><font size=2><tt>> > > I would propose that after x lost packets,
Asterisk should treat</tt></font>
<br><font size=2><tt>> > > all further lost packets as CN. The
proceeding x packets should be</tt></font>
<br><font size=2><tt>> > > interpreted as RTP packet loss and
run through the concealment routine.</tt></font>
<br><font size=2><tt>> > ></tt></font>
<br><font size=2><tt>> > Well, no matter what kind of concealment
algorithm is used, just the</tt></font>
<br><font size=2><tt>> > first one or two packets will be concealed.
The rest losses will result</tt></font>
<br><font size=2><tt>> > in no-playback. No CN interpretation, just
absolute silence.</tt></font>
<br><font size=2><tt>> > </tt></font>
<br><font size=2><tt>> That's true - unless there's some logic to say
that after x lost</tt></font>
<br><font size=2><tt>> packets, the line state should switch to CN generation
instead of</tt></font>
<br><font size=2><tt>> silence.</tt></font>
<br><font size=2><tt>> <br>
> The line state would switch back once a fresh RTP packet is received.</tt></font>
<br><font size=2><tt>> <br>
> > > ></tt></font>
<br><font size=2><tt>> > > > b) The transmitter sent an RTP
packet, that packet was lost and the</tt></font>
<br><font size=2><tt>> > > > last packet correctly received
at the receiver was a CN packet. Again,</tt></font>
<br><font size=2><tt>> > > > following the above interpretation,
the receiver will do nothing (or</tt></font>
<br><font size=2><tt>> > > > more accurate, will play some
background noise), while it should</tt></font>
<br><font size=2><tt>> > > > conseal the packet loss. </tt></font>
<br><font size=2><tt>> > > > </tt></font>
<br><font size=2><tt>> > > In this case, there is nothing to conceal
anyway, as the last received</tt></font>
<br><font size=2><tt>> > > data was a CN packet. In this
case, the CN state should be continued</tt></font>
<br><font size=2><tt>> > > until an RTP packet is received and
the line state can be changed.</tt></font>
<br><font size=2><tt>> > ></tt></font>
<br><font size=2><tt>> > Exactly. So the receiver, in case of no-receiption,
should go back and</tt></font>
<br><font size=2><tt>> > see what was the last packet correctly received
and act as I described</tt></font>
<br><font size=2><tt>> > above. </tt></font>
<br><font size=2><tt>> ></tt></font>
<br><font size=2><tt>> Maintaining an audio state flag (CN/RTP) would
be the key here.</tt></font>
<br><font size=2><tt>> <br>
> > > </tt></font>
<br><font size=2><tt>> > > The difficult part to handle would
be late or out-of-sequence RTP</tt></font>
<br><font size=2><tt>> > > packets. These should be ironed
out by the jitter buffer. Late,</tt></font>
<br><font size=2><tt>> > > lost and juggled packets are to be
expected when dealing with UDP.</tt></font>
<br><font size=2><tt>> > > </tt></font>
<br><font size=2><tt>> > Actually this is not so difficult, if there
is a jitter buffer.</tt></font>
<br><font size=2><tt>> ></tt></font>
<br><font size=2><tt>> Right.</tt></font>
<br><font size=2><tt>> <br>
> -- </tt></font>
<br><font size=2><tt>> _/ _/ _/_/_/_/ _/
_/ _/_/_/ _/ _/</tt></font>
<br><font size=2><tt>> _/_/_/ _/_/ _/
_/ _/ _/_/ _/ K e v
i n W a l s h</tt></font>
<br><font size=2><tt>> _/ _/ _/
_/ _/ _/ _/ _/_/ kevin@cursor.biz</tt></font>
<br><font size=2><tt>> _/ _/ _/_/_/_/ _/
_/_/_/ _/ _/</tt></font>
<br><font size=2><tt>> <br>
> _______________________________________________</tt></font>
<br><font size=2><tt>> Asterisk-Users mailing list</tt></font>
<br><font size=2><tt>> Asterisk-Users@lists.digium.com</tt></font>
<br><font size=2><tt>> http://lists.digium.com/mailman/listinfo/asterisk-users</tt></font>
<br><font size=2><tt>> To UNSUBSCRIBE or update options visit:</tt></font>
<br><font size=2><tt>> http://lists.digium.com/mailman/listinfo/asterisk-users</tt></font><font COLOR="#0000ff"><b>
<p>Winckworth Sherwood</b></font> <font FACE="Verdana" SIZE="2">Solicitors and
Parliamentary Agents
<br />DX 148400 WESTMINSTER 5 : 35 Great Peter Street, London SW1P 3LR
Telephone 020 7593 5000 Fax 020 7593 5099
</font></p>
<p><b>Confidentiality</b>
<br />This email message and any attachments are confidential; they may be subject
to legal professional privilege and are intended for the named recipient only.
If you are not the named recipient, please return the message and enclosures
immediately and delete them from your system.</p>
<b>
<p>Caution</b>
<br />Before advice received only by email (whether by attachment or otherwise) may
be relied on, the authenticity of the communication must be verified by means
independent of email.
<b>
<p>Regulation</b>
<br />The firm is regulated by the Law Society. </p>
<p><b>Partners</b>
<br />A list of partners is available for inspection at each office of the firm and
on the firm's website at</font>
<a HREF="http://www.winckworths.co.uk">www.winckworths.co.uk</a></p>
</font>