On Wed, 2009-10-28 at 11:16 +0000, shouldbe q931 wrote: > > It would be much easier for me to to run a tcpdump on the sipXecs box > than it would be on the Avaya one, and I would be quite happy to.
That's unlikely to help - the message that we need to see never gets to the sipXecs box, so it probably won't be visible. > With the limitation of not being able to use an AA as a method to get > to "extensions" that are not directly "dialable" from the Avaya, my > only interest in debugging this is to resolve a possible bug in > sipXecs, possibly by proving a bug onto Avaya. I'm quite happy to do > this, but it's no skin off my nose if it doesn't work. > > As the AA can "transfer" to an extension correctly, but the "transfer" > to the conference fails, my feeling is that sipXecs is sending a > different "transfer" for the two cases. As a for instance, could it be > that the SIP message is different for the two cases ? I strongly suspect that what's happening is that the Avaya is trying to route the new call leg (toward the transfer target) based only on the user part of the address (the part to the left of the '@') and ignoring the domain part. Since the target when transferring to a conference is an alphabetic string (the conference name) rather than a numeric one, it may be confused. This would be analogous to my attempting to decide how email to be routed to you by using just 'shouldbeq931' and ignoring the 'googlemail.com' - it may seem as though that's so fundamental an error that it's not possible, I assure you that we've seen it before on other systems. However - all of that is speculation. We can see in the progress NOTIFY messages that the Avaya is sending that call _somewhere_ (that's returning Busy). You need to find out why it's doing that (it might help to find out where that is). I assure you that other than the fact that the target address (the Refer-To header value) is different, there's no difference in how the sipXecs AA is executing the two transfers. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
