>> [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 _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
