[Asterisk-Users] sip call using name in sip.conf

[John Todd]

At 7:31 PM -0700 on 5/22/04, Randy Bush wrote:
>  >> [foo]
>>>  type=friend
>>
>>  I do not beleive that will work for type=friend.  If you use separate
>>  type=peer and type=user blocks in sip.conf it may work.  Expecially
>>  if you also specify a port in the Dial().
>>
>>  Else, use the hostname (or a const).
>
>hmmm.  then, how do i let it be dynamic if it has two
>blocks in sip.conf, one for inbound and one for out?
>i.e, how does it register its ip address in both?
>
>randy

Short answer: you can't.

Long answer: there might be other ways around this, but I haven't 
really sat down and tried to do it the "right" way.

Longer answer: Yes, you can, but boyyyy is it ugly.

It appears that you have a situation where you have two Asterisk 
servers.  One * (we'll call it #1) is on a static IP address, while 
the other (#2) "moves around" and is dynamically allocated by DHCP or 
some other method.

You have a group of numbers that you'd like to always route from #2 
to #1 when dialed.  This isn't a problem, since #1 has a static IP 
address, and you can just reference it with the "host=1.2.3.4" entry 
in your peer statement in sip.conf.

Now, going the other way around is more difficult.  #1 doesn't know 
the IP address of #2.  There is the concept of "register=>" in 
sip.conf, but that only registers _individual user-agents_ and does 
not allow one server to know that another server is at a particular 
IP address.  REGISTER typically is not used for server-to-server 
notification of layer 3 presence (though maybe it is - it's possible 
that is supported in the RFC, but I'm too lazy right now to go 
digging.  It's not supported in Asterisk, so that's the point here.) 
So, you're out of luck I think.

There is one way to do this the way you want, and to even talk about 
it makes my hair stand on end.  You _could_ put the "real" called 
number into the caller ID name (SetCIDName) and then send it to a 
single registered extension. That registered extension would take the 
call in on the other side, parse out the $CALLERIDNAME value and then 
set an ${EXTEN} based on the results and proceed with the dial path. 
Errrrrrgh - I need to go take a shower now.

NOTE: You'd of course have to route all of your RTP through #1 in 
order for it to get to #2, and re-invites and all that neat stuff 
will fail, because you're "tunnelling" SIP over SIP.


Last note: you might be able to write a hack that pulled this data 
out of the SIP database, kind of like a very strange adaptation of 
"default-network" in IOS - beacon routes.  Here's another one of my 
hypothetical program descriptions for this mythical application:

app1*CLI> show application GetHostIP
   -= Info about application 'GetHostIP' =-

[Synopsis]:
Terrible kludge to get IP address of remote Asterisk servers.

[Description]:
   GetHostIP(proto/username): Looks up the given name in the protocol 
username list and returns the IP address of where that username is 
currently registered in variable ${DYNAMICADDR}.  Useful for setting 
up "beacon" accounts that register from dynamically-addressed 
Asterisk hosts so one can trunk calls to them.  Currently supports 
IAX/IAX2/SIP protocols.
app1*CLI>


I just come up with the ideas, I don't program 'em.

JT