[asterisk-users] Psst... Top secret information: Codename Pineapple

[Olle E Johansson]

14 okt 2006 kl. 09.44 skrev Brian Candler:

> On Fri, Oct 13, 2006 at 07:00:54PM -0500, Eric ManxPower Wieling  
> wrote:
>>>>> * Phones = stations, regardless of where they are
>> Asterisk = SIP Server, Phone = SIP Client
>>
>>>>> * Trunks = trunks to other SIP servers, bilateral
>> Asterisk and the other server is "peer to peer"
>>
>>>>> * Services = services you register for, like BroadVoice, Voop  
>>>>> or FWD.
>>>>>   (where asterisk acts as a "phone")
>>
>> Asterisk = SIP Client, Other End = SIP Server
>
> Hmm, but I don't see how these ideas map to formal SIP concepts  
> (RFC 3261).

Let's try to clarify then.

"phones" are devices that connect to Asterisk. They register with  
Asterisk acting as a
SIP location server/registrar and use Asterisk as the outbound SIP  
proxy. They get
calls from Asterisk and place calls to Asterisk. The phone use one of  
the SIP domains
that are hosted within your Asterisk server. (this is like the  
current "friend")

"service" is when Asterisk is the UA, acting as a phone towards  
another SIP server
- we register with a SIP location server/registrar to get incoming  
calls. We place
calls, masquerading as a phone (using the registrars domain).
Currently, this is a mixture between a peer (matched on IP for  
incoming calls) and a
register= statement. In some cases, two peers and a register= statement.
Very confusing.

"trunk" is when we exchange traffic with another server. We send  
calls to their
SIP domain and receive calls to our SIP domain. We may use realm based
authentication for the incoming part of the trunk (not based on caller
ID/From: header) and a combination of SIP domain and ACLs.
This is currently handled by defining sip peers for outbound calls and
separate SIP peers for inbound calls - where we match on IP. The
problem with the IP matching is when a trunking partner use several
SIP servers to connect to us, we need to define one peer per server
instead of just matching on domain and then authenticate.

In all cases, we're a SIP user agent client/server in SIP terminology.
In fact, we're a super-SIP ua called a B2BUA. I am trying to avoid
"sip client" since the whole user/peer client/server concept does not
really match SIP.

In some cases, we're the SIP registrar/location server and in other
we're configured as the outbound proxy, even though we are not
a proxy.

I hope I did not add to the confusion by this confusing message.
/O


---
* Olle E. Johansson - oej at edvina.net
* Asterisk Training http://edvina.net/training/ - Stockholm, Sweden,  
November 13-17