[Asterisk-Dev] 302 Moved Temporarily: Uses and methodology

[Sergey Kuznetsov]

Hi John,


"302" message will be very useful if you are doing SIP cluster, in this 
case one * box will only accept the calls and have some logic to which * 
box in a cluster to redirect to complete the call,
or make direct redirection based on dialplan directly to the SIP phone. 
Therefore there is some possibility to off-load the box from the hard 
work. The only issue here you can't keep the CDR for that call.


All the Best!
Sergey



John Todd wrote:

>
> 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
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev