[Asterisk-Dev] 302 Moved Temporarily: Uses and methodology
John Todd
jtodd at loligo.com
Thu Jan 20 22:35:48 MST 2005
It strikes me that a somewhat inelegant but useful way of allowing
Asterisk to be a clever program for large scale SIP services would be
to utilize the "302 Temporarily Moved" feature of SIP in order to
allow Asterisk to produce custom messages based on some set of
dialplan or script results.
Granted, I could do this simply with a UDP listener, but that would
require running something on a different port, and not integrating
well with Asterisk. Maybe I want to have some calls answered by the
local Asterisk server, some calls to be redirected somewhere else.
With a 302, I could get this functionality provided by a set of
GotoIf applications or other criteria. Therefore, it would be ideal
to have the "302" message be produced by Asterisk, perhaps as an
application.
Currently, examining the source code of chan_sip shows that there is
some minimalist support for 302 messages that are sent back to
Asterisk in the case of an INVITE. However, I was unable to locate
a spot in the code which addressed generation of such messages. Am I
simply missing this code? chan_sip is getting deep.
The more I think about this method, the more it becomes perhaps
useful. Instead of using re-INVITEs in order to forward a call to
another gateway or proxy, would it not make more sense just to use a
302 message to force a User-Agent (SIP client) to request a new,
re-written number? This would allow for quick call routing to happen
with some interesting side effects: re-writing the called number and
gateway without the user being involved in the transaction, which
might also solve some nasty NAT problems. It might not, also - I
admit I haven't thought the whole thing out.
Would this best be written as an application? I don't believe that
other IP-based protocols have a method that is exactly similar to the
302 method that SIP uses (other than maybe IAX2?) so it's portability
across other protocols is suspect. It may be best as a standalone
application...
Imagine this logic to quickly re-route your SIP clients to different
locations based on the number that they're calling. (Yes, each
gateway would have to have a complete authentication database for all
customers, but that isn't that hard anymore.)
exten => _1410.,1,SIPRedirect(${EXTEN}@bwi1.md.foo.com)
exten => _1212.,1,SIPRedirect(${EXTEN}@jfk1.ny.foo.com)
This would eliminate any state machine on your "primary" Asterisk
call router. It's not an attempt at being a SIP proxy, but it's
getting close to that functionality in a terrible, awful, hackish
way... but totally RFC compliant as best as I can tell. And it would
be extremely handy for using Asterisk as a tool in SIP environments
where getting into the guts of the software is more difficult to do
call routing...
"Well, I can do this just with Dial. Why do I need to redirect?"
Good question. 1) It might solve some NAT issues, without RTP media
proxying. 2) It might solve instances where the calls are charged
based on where the source IP address is, since it forces the UA to be
the only (and not lr'ed) source of the request. 3) It could be used
for entirely re-writing the number being called, which may be passed
back as a new call into the larger and more uncontrolled layers of
proxies (think "*69" services here in the USA and you'll figure out
what I'm getting at.)
Thoughts, ideas, or bounty-hunters welcome.
JT
More information about the asterisk-dev
mailing list