[Asterisk-Dev] SIP REINVITE

[BJ Weschke]

On 5/16/05, Olle E. Johansson <oej at edvina.net> wrote:
> BJ Weschke wrote:
> >  Server A (IP 192.168.1.1)
> >  Server B (IP(s) 192.168.1.2 [actual] 192.168.1.3 [vip])
> >  Server C (IP(s) 192.168.1.4)
> >
> >  All servers are Asterisk installs. All servers have SIP canreinvite=yes.
> >
> >  Server A calls Server B on his VIP. The call sets up fine, but the
> > 3rd of 4th step in the dial plan is to then transfer that call on to
> > Server C. Server B dials server C and then begins to attempt a native
> > bridge between Server A and C. Server A responds back with "SIP/2.0
> > 482 Loop Detected" assumably because the man in the middle has
> > different terminating/originating IP addresses and has sent an
> > improper invite back to A to start the briding process.
> Can you send me a packet trace of this?

 Sure. You want a raw packet trace, or just a "sip debug" trace from
*? I won't be able to get packet traces from server A right off the
bat, as that one is my carrier's and not my own, but my guess is the
problem originates with server B.

> 
> >  Does ANTHM's patch from a few weeks back to chan_sip fix this
> > problem, or is this still a "live" issue? If it is patched, who needs
> > the patch in the scenario above? Just server B? or Servers A and C
> > too?
> I haven't seen the loop detected issue, but understand where it's coming
> from. Anthm's patch is more to be seen as a proof-of-concept than
> something you want to use. I'm trying to continue the work based on his
> patch, but it will require a lot of changes to chan_sip.
> 
> I'm glad to see another person wanting to transfer calls from Asterisk
> to another SIP domain - I just had a question from a core developer on
> the theme "why would anyone want to do that?"... So I needed your mail
> to prove that's it is not only me and my customers that need that function.
> 
> Digging into how chan_sip handles transfers I'm amazed that it work with
> anything... ;-)
> 
> /Olle
> 

 Well, looking at the code, it looks that it was designed to work
under very simple circumstances. If we present any kind of complex
setup, the logic there is going to fall down. My guess is that if
server B used it's VIP as the originating IP as oppsed to it's native
IP when it makes that initial dial to server C, the logic in place now
would work when server B was told to bridge the two calls from Server
A to B and B to C together natively. That's a "quick and dirty" for
just my scenario, but I'd by interested in contributing time and
resources towards "doing it right" if that effort is underway already.

 BJ