How to register sip client to yate

Can anybody help and answer to my questions?

what cell/voip phones will work with yate?

I need a new cell phone (that I can purchance and use in the US), I see some now 
will do VoIP.  I have not figured out if they can be set to talk to whatever 
server i want (like my yate box) or if they are hardcoded to only work with the 
provider's server.

Here are a bunch of articles I have been reading:

http://linuxdevices.com/articles/AT7937511405.html

http://linuxdevices.com/news/NS9944179386.html
http://linuxdevices.com/news/NS4367004471.html
http://linuxdevices.com/news/NS4156227772.html
http://linuxdevices.com/news/NS3547076080.html
http://linuxdevices.com/news/NS4837234991.html

Those are the VoIP + Linux based articles - I must have just read about 50 
different articles.

Carl

RE: SS7, T38, OpenH323 (was: YATE and SS7)

We do not intend to support Digium cards as they have no hardware 
or firmware support for sending messages as required by the ITU and ANSI 
SS7 (MTP2 described in Q.703). If someone wants to do a software only 
implementation similar to chan_ss7 in asterisk it will be quite easy but 
we don't trust it to work properly (and it doesn't - check the 
asterisk-ss7 list). At least the very least the support should be 
available in kernel.

There are no current plans for T38 support. It would be nice to have but 
the spandsp library on which we base to provide fax support does not 
support the features to implement T38.

As far as I know the limitations on OpenH323 on Windows are quite 
different from Linux. Craig has an article about call density and the 
conclusion is that on Windows there is a hard limit of about 1024 threads 
that will limit the maximum number of call legs to about 500.

Of course the CPU usage is not counted, nor the maximum rate of call
cleanups that is severely limited by the OpenH323's architecture. No
patching will help. However, doing 100-200 calls is feasable especially on 
a multiprocessor machine. It is more important to have many processors 
than to have fast but fewer ones.

I hope these informations will be of help to you and anyone else.

Regards,

Paul Chitescu

On Wed, 10 May 2006, Vlasis Hatzistavrou  <at>  Kinetix Tele.com wrote:
> Hello Paul,
> 
> Thanks for your reply. The plan about SS7 that you described sounds very
> promising. Will Yate support Digium cards for SS7, too?
> 
> One more question: are there plans for T38 support? For the moment we have
> used Yate for production for SIP-H323 conversion (as well as for H323 to
> H323 calls) and it seems to perform quite well, servicing 30-40 simultaneous
> calls with no apparent problems. We plan to slowly increase the load and see
> how it behaves.
> 
> Since we have tested Yate for production on Windows only, I would like to
> ask if the 50 simultaneous calls limit applies to Yate 0.99 for the Windows
> installation as it comes from CVS or if we have to apply any patches to
> PWLib too.
> 
> Best regards,
> Vlasis Hatzistavrou.
> 
> -----Original Message-----
> From: Paul Chitescu [mailto:paulc@...] 
> Sent: Τρίτη, 9 Μαΐου 2006 8:41 μμ
> To: yate@...
> Subject: Re: [yate] YATE and SS7
> 
> SS7 support in Yate is a work in proggress and right now there is very few 
> code written. The direction is towards a stable and flexible stack rather 
> than rapid development.
> 
> Initially we will have just ISUP call control over E1/T1 lines and then we 
> will add implementations for other protocol stack components so Yate will 
> be usable as SSP, SCP or STP (well, with some performance penalty for 
> going through userspace).
> 
> We will support Sangoma A104 cards which have firmware capabilities to 
> support automatic FISU/LSSU repeat. A101 and A102 cards may have problems 
> with equipments that follow the standard strictly as there may be 
> multiple successive flags between messages.
> 
> As the hardware access layer is quite thin it will be easy to add new 
> hardware. V35 on Linux supported drivers should pose no problems.
> 
> We will also support SIGTRAN in various configurations (peer to peer, 
> signalling gateway, application server) at different layers. This requires 
> kernel support for SCTP (available in Linux kernels 2.6 and recent 2.4). 
> Later we may add support for other SCTP drivers and libraries in Yate's 
> Socket class.
> 
> Paul Chitescu
> 
> On Tue, 9 May 2006, Vlasis Hatzistavrou wrote:
> > Hello,
> > 
> > I noticed in a few files from the YATE source code that SS7 is mentioned?
> > Does YATE support SS7 signaling? If yes, which interface cards support
> > it with YATE?
> > 
> > Best regards,
> > 
> > Vlasis Hatzistavrou

RE: SS7, T38, OpenH323 (was: YATE and SS7)

Hello Paul,

Thanks for your reply. I understand about T38 fax, not being there because
spandsp is still not ready. 

However, I was referring to T38-passthrough, for VoIP to VoIP calls, between
SIP and H323. I believe that spandsp is not needed in this case, since we
are not talking about sending faxes between VoIP and TDM call legs...

Best regards,
Vlasis Hatzistavrou

-----Original Message-----
From: Paul Chitescu [mailto:paulc@...] 
Sent: Κυριακή, 21 Μαΐου 2006 3:45 μμ
To: yate@...
Subject: RE: [yate] SS7, T38, OpenH323 (was: YATE and SS7)

We do not intend to support Digium cards as they have no hardware 
or firmware support for sending messages as required by the ITU and ANSI 
SS7 (MTP2 described in Q.703). If someone wants to do a software only 
implementation similar to chan_ss7 in asterisk it will be quite easy but 
we don't trust it to work properly (and it doesn't - check the 
asterisk-ss7 list). At least the very least the support should be 
available in kernel.

There are no current plans for T38 support. It would be nice to have but 
the spandsp library on which we base to provide fax support does not 
support the features to implement T38.

As far as I know the limitations on OpenH323 on Windows are quite 
different from Linux. Craig has an article about call density and the 
conclusion is that on Windows there is a hard limit of about 1024 threads 
that will limit the maximum number of call legs to about 500.

Of course the CPU usage is not counted, nor the maximum rate of call
cleanups that is severely limited by the OpenH323's architecture. No
patching will help. However, doing 100-200 calls is feasable especially on 
a multiprocessor machine. It is more important to have many processors 
than to have fast but fewer ones.

I hope these informations will be of help to you and anyone else.

Regards,

Paul Chitescu

On Wed, 10 May 2006, Vlasis Hatzistavrou  <at>  Kinetix Tele.com wrote:
> Hello Paul,
> 
> Thanks for your reply. The plan about SS7 that you described sounds very
> promising. Will Yate support Digium cards for SS7, too?
> 
> One more question: are there plans for T38 support? For the moment we have
> used Yate for production for SIP-H323 conversion (as well as for H323 to
> H323 calls) and it seems to perform quite well, servicing 30-40
simultaneous
> calls with no apparent problems. We plan to slowly increase the load and
see
> how it behaves.
> 
> Since we have tested Yate for production on Windows only, I would like to
> ask if the 50 simultaneous calls limit applies to Yate 0.99 for the
Windows
> installation as it comes from CVS or if we have to apply any patches to
> PWLib too.
> 
> Best regards,
> Vlasis Hatzistavrou.
> 
> -----Original Message-----
> From: Paul Chitescu [mailto:paulc@...] 
> Sent: Τρίτη, 9 Μαΐου 2006 8:41 μμ
> To: yate@...
> Subject: Re: [yate] YATE and SS7
> 
> SS7 support in Yate is a work in proggress and right now there is very few

> code written. The direction is towards a stable and flexible stack rather 
> than rapid development.
> 
> Initially we will have just ISUP call control over E1/T1 lines and then we

> will add implementations for other protocol stack components so Yate will 
> be usable as SSP, SCP or STP (well, with some performance penalty for 
> going through userspace).
> 
> We will support Sangoma A104 cards which have firmware capabilities to 
> support automatic FISU/LSSU repeat. A101 and A102 cards may have problems 
> with equipments that follow the standard strictly as there may be 
> multiple successive flags between messages.
> 
> As the hardware access layer is quite thin it will be easy to add new 
> hardware. V35 on Linux supported drivers should pose no problems.
> 
> We will also support SIGTRAN in various configurations (peer to peer, 
> signalling gateway, application server) at different layers. This requires

> kernel support for SCTP (available in Linux kernels 2.6 and recent 2.4). 
> Later we may add support for other SCTP drivers and libraries in Yate's 
> Socket class.
> 
> Paul Chitescu
> 
> On Tue, 9 May 2006, Vlasis Hatzistavrou wrote:
> > Hello,
> > 
> > I noticed in a few files from the YATE source code that SS7 is
mentioned?
> > Does YATE support SS7 signaling? If yes, which interface cards support
> > it with YATE?
> > 
> > Best regards,
> > 
> > Vlasis Hatzistavrou

SIP<->SIP Demensioning

Hey all,

I'm trying to use Yate in an environment that currently uses a series of 
OpenSER proxies. We have about 12,000 ports of TDM capacity that are 
converted to SIP ports via Lucent APX8000's. We really need B2BUA 
functionality over straight proxying because statefulness will help 
track and control certain resources.

While I don't expect Yate to be as fast and as resource efficient as a 
stateless proxy like OpenSER, I can't seem to push it very far in ports 
or calls per second. I've read several mailing list entries talk about 
port limits with H323 and increasing file handlers. But:

1) Is there a current design limitation on the number of concurrent SIP 
channels?
2) When we tax yate, its slow to respond, is this a raw processing usage 
issue or a open descriptor issue?
3) Will running many instances of Yate on the same machine help over a 
single instance?
4) Will yate make use of multi-processor environments?
5) How should the maxworkers= setting be adjusted? Are there other such 
tweakable settings?
6) Under Linux 2.6.x, what file descriptor or other OS variable settings 
will help Yate speed/processor/memory wise?

Thanks, David

yaypm 0.2 problems

Hi.

I tried to use the yaypm 0.2 from the bug tracker, but ran into the following problem:

Initializing module PyModule
<PythonInterpreter:GOON> Can't load yaypm module:
Traceback (most recent call last):
  File "/home/igor/tree/lib/yate/scripts/yaypm/__init__.py", line 26,
in ? from twisted.internet import reactor, defer
  File
"/home/igor/tree/lib/python2.4/site-packages/twisted/__init__.py", line
22, in ? raise ImportError, "you need zope.interface installed
(http://zope.org/Products/ZopeInterface/)" ImportError: you need
zope.interface installed (http://zope.org/Products/ZopeInterface/)
<PyModule:WARN> Interpreter not initialized

The error message is confusing, because twisted and zope.interface is
installed and working great when I try to use them in a standalone python.

Also yaypm cannot be imported in a standalone python, because yateproxy
is imported unconditionally in yaypm/__init__.py but is only available
when running the embedded interpreter.

Any ideas?

Igor

Re: SS7, T38, OpenH323 (was: YATE and SS7)

Hi,

chan_ss7 in Asterisk has some issues, but it works. For me
and for number of others in production environment. Sending
SS7 messages should not differ from sending plain audio for
a PC - both streams are data streams. For sure a kind of
builtin hardware support would be nice, to offload main CPU
and ensure proper functioning. IMHO having chan_ss7
operational is far better than just talking about creation
of a different and very promisiong implementation. As I
see, there is even no concept for that.

Regards,
Anton.

On 21 May 2006 17:45, Paul Chitescu wrote:
> We do not intend to support Digium cards as they have no
> hardware or firmware support for sending messages as
> required by the ITU and ANSI SS7 (MTP2 described in
> Q.703). If someone wants to do a software only
> implementation similar to chan_ss7 in asterisk it will be
> quite easy but we don't trust it to work properly (and it
> doesn't - check the asterisk-ss7 list). At least the very
> least the support should be available in kernel.
>
> There are no current plans for T38 support. It would be
> nice to have but the spandsp library on which we base to
> provide fax support does not support the features to
> implement T38.
>
> As far as I know the limitations on OpenH323 on Windows
> are quite different from Linux. Craig has an article
> about call density and the conclusion is that on Windows
> there is a hard limit of about 1024 threads that will
> limit the maximum number of call legs to about 500.
>
> Of course the CPU usage is not counted, nor the maximum
> rate of call cleanups that is severely limited by the
> OpenH323's architecture. No patching will help. However,
> doing 100-200 calls is feasable especially on a
> multiprocessor machine. It is more important to have many
> processors than to have fast but fewer ones.
>
> I hope these informations will be of help to you and
> anyone else.
>
> Regards,
>
> Paul Chitescu
>
> On Wed, 10 May 2006, Vlasis Hatzistavrou  <at>  Kinetix

Tele.com wrote:
> > Hello Paul,
> >
> > Thanks for your reply. The plan about SS7 that you
> > described sounds very promising. Will Yate support
> > Digium cards for SS7, too?
> >
> > One more question: are there plans for T38 support? For
> > the moment we have used Yate for production for
> > SIP-H323 conversion (as well as for H323 to H323 calls)
> > and it seems to perform quite well, servicing 30-40
> > simultaneous calls with no apparent problems. We plan
> > to slowly increase the load and see how it behaves.
> >
> > Since we have tested Yate for production on Windows
> > only, I would like to ask if the 50 simultaneous calls
> > limit applies to Yate 0.99 for the Windows installation
> > as it comes from CVS or if we have to apply any patches
> > to PWLib too.
> >
> > Best regards,
> > Vlasis Hatzistavrou.
> >
> > -----Original Message-----
> > From: Paul Chitescu [mailto:paulc@...]
> > Sent: Τρίτη, 9 Μαΐου 2006 8:41 μμ
> > To: yate@...
> > Subject: Re: [yate] YATE and SS7
> >
> > SS7 support in Yate is a work in proggress and right
> > now there is very few code written. The direction is
> > towards a stable and flexible stack rather than rapid
> > development.
> >
> > Initially we will have just ISUP call control over
> > E1/T1 lines and then we will add implementations for
> > other protocol stack components so Yate will be usable
> > as SSP, SCP or STP (well, with some performance penalty
> > for going through userspace).
> >
> > We will support Sangoma A104 cards which have firmware
> > capabilities to support automatic FISU/LSSU repeat.
> > A101 and A102 cards may have problems with equipments
> > that follow the standard strictly as there may be
> > multiple successive flags between messages.
> >
> > As the hardware access layer is quite thin it will be
> > easy to add new hardware. V35 on Linux supported
> > drivers should pose no problems.
> >
> > We will also support SIGTRAN in various configurations
> > (peer to peer, signalling gateway, application server)
> > at different layers. This requires kernel support for
> > SCTP (available in Linux kernels 2.6 and recent 2.4).
> > Later we may add support for other SCTP drivers and
> > libraries in Yate's Socket class.
> >
> > Paul Chitescu
> >
> > On Tue, 9 May 2006, Vlasis Hatzistavrou wrote:
> > > Hello,
> > >
> > > I noticed in a few files from the YATE source code
> > > that SS7 is mentioned? Does YATE support SS7
> > > signaling? If yes, which interface cards support it
> > > with YATE?
> > >
> > > Best regards,
> > >
> > > Vlasis Hatzistavrou

--
With Best Regards,
Anton

--------
Anton V. Gnitko
Technical Director
Eastera Co. Ltd.
+992 372 270101
+992 372 213627
http://www.eastera.net

-------------------------------------------------------

Re: SS7, T38, OpenH323 (was: YATE and SS7)

Sorry, Anton, didn't want to offend anyone.

If chan_ss7 works for you then by all means use it. I never said that 
there isn't place under the sun for anything else, just that I intend to 
provide a specific solution and what are my reasons for that. I don't see 
why the project I'm working on would threaten anybody.

Paul Chitescu

On Sun, 21 May 2006, Anton wrote:
> Hi,
> 
> chan_ss7 in Asterisk has some issues, but it works. For me
> and for number of others in production environment. Sending
> SS7 messages should not differ from sending plain audio for
> a PC - both streams are data streams. For sure a kind of
> builtin hardware support would be nice, to offload main CPU
> and ensure proper functioning. IMHO having chan_ss7
> operational is far better than just talking about creation
> of a different and very promisiong implementation. As I
> see, there is even no concept for that.
> 
> Regards,
> Anton.
> 
> On 21 May 2006 17:45, Paul Chitescu wrote:
> > We do not intend to support Digium cards as they have no
> > hardware or firmware support for sending messages as
> > required by the ITU and ANSI SS7 (MTP2 described in
> > Q.703). If someone wants to do a software only
> > implementation similar to chan_ss7 in asterisk it will be
> > quite easy but we don't trust it to work properly (and it
> > doesn't - check the asterisk-ss7 list). At least the very
> > least the support should be available in kernel.
> >
> > There are no current plans for T38 support. It would be
> > nice to have but the spandsp library on which we base to
> > provide fax support does not support the features to
> > implement T38.
> >
> > As far as I know the limitations on OpenH323 on Windows
> > are quite different from Linux. Craig has an article
> > about call density and the conclusion is that on Windows
> > there is a hard limit of about 1024 threads that will
> > limit the maximum number of call legs to about 500.
> >
> > Of course the CPU usage is not counted, nor the maximum
> > rate of call cleanups that is severely limited by the
> > OpenH323's architecture. No patching will help. However,
> > doing 100-200 calls is feasable especially on a
> > multiprocessor machine. It is more important to have many
> > processors than to have fast but fewer ones.
> >
> > I hope these informations will be of help to you and
> > anyone else.
> >
> > Regards,
> >
> > Paul Chitescu
> > [...]

Re: yaypm 0.2 problems

Igor napisał(a):
> Hi.
> 
> I tried to use the yaypm 0.2 from the bug tracker, but ran into the following problem:
> 
> Initializing module PyModule
> <PythonInterpreter:GOON> Can't load yaypm module:
> Traceback (most recent call last):
>   File "/home/igor/tree/lib/yate/scripts/yaypm/__init__.py", line 26,
> in ? from twisted.internet import reactor, defer
>   File
> "/home/igor/tree/lib/python2.4/site-packages/twisted/__init__.py", line
> 22, in ? raise ImportError, "you need zope.interface installed
> (http://zope.org/Products/ZopeInterface/)" ImportError: you need
> zope.interface installed (http://zope.org/Products/ZopeInterface/)
> <PyModule:WARN> Interpreter not initialized
> 
> The error message is confusing, because twisted and zope.interface is
> installed and working great when I try to use them in a standalone python.

Are You sure that standalone python and python that pymodule links with 
are the same?

> 
> Also yaypm cannot be imported in a standalone python, because yateproxy
> is imported unconditionally in yaypm/__init__.py but is only available
> when running the embedded interpreter.

Version from bugtracker is meant to work only in embedded interpreter. I 
am working on version that will work with extmodule as well.

Maciejk Kaminski