asterisk users - Feb 2005 - setting caller id number and using sip type=peerfor incomming calles.

> > To get around this i updated CVS HEAD and changed the sip entity
from
 > > type=user to type=peer (yes peer!) (type=friend works too but im
making
 > > a point) the client now must register to set his outbound caller*ID
 > Number.
 > 
 > Yes, that is normal. SIP has difficulty separating the remote party
 > identification from the authentication identification (although it
can
 > be done).

I see..
> > this seems to be working but it hardly seems correct, i mean using a
 > > peer for inbound calls when the docs all say it is for outbound
calls.
 > 
 > In CVS HEAD, soon _all_ SIP entries will be type=peer, because it's
more
 > logical this way.
 > 
you mean amalgamating user and peer so there will eventually only be one
type for both incoming and outgoing calls, (hopefully have an option to
disable enable in/out bound calls).

As long as it is the way it is supposed to be working I will quit
complaining :)

 > > im not up on the sip protocol but wouldn't it be better if, when
 > > receiving an unknown connection (ie when caller*ID number is set to
a
 > > pstn number) it first sends an authentication request to the
client, on
 > > return it checks that username/secret against its list of users. if
it
 > > still doesn't find it then drop it into the guest account.
 > 
 > I believe it can already be configured to work that way, if you
disable
 > access to "guest" connections (I've not tried it, though).
Remember
also
 > that it works this way because there are number of providers out
there
 > (Broadvoice being one) that will _not_ authenticate when they send
you a
 > call, only when they register.

Now that's a bit of a bitch :/ but at the moment registration will have
to do.
But it would still be nice to have the ability to have a client that
doesn't have to register, ie they have multiple servers that can dial
though us and set caller id number.
If I get time I might tinker with this myself for some fun :).


Thanks for your reply.

Morgan Gilroy wrote:
> you mean amalgamating user and peer so there will eventually only be one
> type for both incoming and outgoing calls, (hopefully have an option to
> disable enable in/out bound calls).
Yes, exactly (and there will be other settings as well, to identify the 
type of peer (network, trunk, endpoint) for other reasons).
> Now that's a bit of a bitch :/ but at the moment registration will have
> to do.
> But it would still be nice to have the ability to have a client that
> doesn't have to register, ie they have multiple servers that can dial
> though us and set caller id number.
> If I get time I might tinker with this myself for some fun :).
That's coming too, but in a different way. Actually if your remote peer 
can send you Remote-Party-ID headers now, you can set "trustrpid=yes"
in
your peer definition and the CLID/CNAM will come from that instead of 
the From header, so the From header can contain only authentication 
information.

If the remote peer is Asterisk, it cannot currently send 
Remote-Party-ID, but watch Mantis for a patch in a few days to enable it :-)