[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