[Asterisk-Users] Re: [Asterisk-Users] SIP config documentation

[Costa Tsaousis]

Hi again,

> Feel we need to document various solutions here.

Yes we do. I still have a filling that I don't exactly get it...


> Sorry, I was on the wrong topic, canreinvite has
> yes|no|update as keywords.
> with UPDATE a SIP method UPDATE is initiatied to change the media path.
> with YES, a new INVITE is issued within the current call. (a "re-invite")
> with NO, the call stays within asterisk.

Sorry for asking this, but in practice, what does these mean?
(yes I know I should look at the FRC... :)


> I'll add comments to the bug reports. We really need to think about how
> we steer the SIP channel forward. Asterisk is a multi-protocol PBX, so
> there's no sense in making the SIP channel a stand-alone SIP proxy that
> doesn't work with the rest of the PBX. If you don't want a PBX in the core
> of your SIP network, use a SIP proxy there and use Asterisk where it fits
> in. This way of reasoning means there are things that will never happen in
> the Asterisk SIP channel because of the multi-protocol architecture. We
> need
> to be clear on that while moving the channel forward. Having said that,
> there's a lot of things to do to make the SIP client and server within
> Asterisk more compliant and functional with the rest of the SIP world.

Olle, I think it is a mater of prioritization. If you put the switched
world in the first priority, yes we should keep numbers. If you put SIP
first, then we should use e-mail like addresses. After some time there
might be another protocol, say XYZ. If you put XYZ first, then you should
choose the method this protocol uses, etc.

I believe there are three possible paths for asterisk:

1. Stick to the switched world (as the common denominator for telephony).
This means that * can have any number of gateways on it, but always, it
will be a "switching-like" PBX with some VoIP functionality, build in
software.

Example: forget about SIP, H.323 and the like, focus on switched telephony
with the ability to place and receive calls via VoIP making them as
switching-friendly as possible, of course with limitations.

2. Open up the possible scenarios and let the administrator choose the
primary protocol. This means that although asterisk will not address in
its core artificially intelligent thinks such as callerid convertion, it
could be configured to follow either schema. In this case, the
administrator should have the means to configure some aspects of the
secondary protocols.

Example: Support a number of protocols as primary and configure asterisk
according to them. This means that various building blocks (like callerid
handling) will be multiplied, one variation per primary protocol and the
whole system will support only one protocol for such functions. When there
are interfaces with other protocols the administrator should make hard
decisions about the properties that cannot be converted automatically.

This is my case today. I want SIP as primary and I know I will have to
provide numeric callerids in the configuration when interfacing with other
protocols. What I need is a SIP PBX and IVR, not a SIP proxy. I cannot do
what I need with SER (at least not that easy...).

3. Build asterisk as a superset of all protocols, internally. In our case
this could mean that the callerid could be defined as:

callerid=TEXT <internet address> <number>

or even:

callerid=Your Name <sip:name at example.com> <h323:...> <mgcp:...>

or just provide directory services for callerid convertions between non
compatible protocols.

As a superset of all protocols, asterisk will be able to be a fully
functional member of each of the supported worlds and will be able to also
handle all the protocols as primary at the same time.

Path 3 is the perfect path. Path 2 is a good one. Path 1 demotes asterisk.
If it is going to be Path 1 I believe we, all, are going to use asterisk
as a secondary component in our telephony infrastructures that will
provide some valuable services, but it will never be the heart of it,
unless all that we need is a plain old switched-like PBX with some VoIP
functionality.


> We need to work together to handle the multi-domain scenario. Please
> send me whatever you have and let's continue discussing this so we get
> a solid architecture. I do want Asterisk to be in the forefront in
> preventing
> use of Asterisk as a open SIP spam relay to use mail terms. Mail servers
> are
> picky of which domains they server for inbound and outbound messages, in
> some
> cases also on what domain is used for outbound messages. We need to have
> configuration that follows this line of thinking for SIP. If someone is
> using
> our domain for outbound calls - authenticate. If someone is randomly
> placing
> calls to extensions in any domain they invent *into* our PBX, don't
> answer.

I agree with you, but still I think all these should be configuration
decisions, not implementation ones.

Regards,

Costa