So does anyone have any other thoughts about this? I’ve done some searching
through the bug tracker for Asterisk but haven’t seen anything related to
refer’s failing. Does anyone know of a specific issue number for this? If
not, is this a valid bug to submit? Also, does anyone remember an Asterisk
version that this worked on?
On Fri, Mar 4, 2011 at 1:35 PM, Louis Carreiro wrote:
> Ha! Thanks Vip!
> Sorry about not including my version numbers too. On my production box I’m
> using 1.8.3 (that’s the debug from the original email). On my demo box I
> just build I’m using 1.8 SVN-trunk-r309404 and that’s what generated these
> logs. I’m not sure if this is a chan_sip.c problem or if this is a dial
> plan problem.
> So digging in a bit deeper, Asterisk is receving the real REFER message.
> The “REFER-TO:
> 3Bto-tag%3D8be38bb187>” is accurate and in chan_sip.c it knows how to
> manipulate it. It does grab the “from-tag” and “to-tag” and parses the
> data. On one of the lines below you can see it says “Looking for Call
> ID: firstname.lastname@example.org:5060 (Checking From)
> –From tag 15826bef52 –To-tag as41bacc0b”. Then it moves on to bridging
> the peers/channels together. It’s not until later that I get the final “
> SIP/2.0 481 Call leg/transaction does not exist” which doesn’t make sense
> to me. Also, the Lync client says “Call was not transferred because
> [Original Extension] cannot be reached and may be offline.”
> <-------- SNIP --------->