Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Organization: SipXecs Forum In-Reply-To: <CAMgKNJWM52QdgtXvx_yptfpQe0qecu4+cMOnRepq=lgretj...@mail.gmail.com> X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <63025> Message-ID: <[email protected]>
Thanks Tony, Absolutely nothing would make me happier than to have someone point out a simple solution to this problem, where I had over complicated it. Exactly as you have suggested, I believed the problem was with a dialplan/route on the Patton gateway. I put in other dialplan entries on the patton, but it would not respect them (I put in an entry for the exact number I was dialling, 4495, and it simply ignored the route. In fact, through a fair bit of troubleshooting, I found that the route table wasn't being evaluated there... I opened a ticket with Patton engineers, and spoke to them back and forth for about a week, until we determined the problem. The route table on the Patton is not being evaluated, because the REFER-TO comes in already qualified for the mailto:'@voip.royalroads.ca' for which it has a route. Any URI ending in anything OTHER than it's IPAddress/hostname is sent to the SipXecs server. We (the Patton Engineers and I) tried using functions of the Patton gateway to strip the URI, but without success. Patton insists that the issue needs to be resolved before the REFER-TO reaches the gateway, and I have come to agree. Why, when I dial '4495', should the INVITE reach the gateway as '994495' (around which the routes on the gateway are developed), but when I TRANSFER a call to '4495', the REFER-TO reach the gateway as '4495'? The behaviour is inconsistent. Direct dialed calls are 'transformed' by the dialplan, but REFER-TO transfers are not. If sending the mailto:'[email protected]' were a valid configuration, why does the SipXecs server send the call as mailto:'[email protected]' when a call in initiated? I suggest that it is because the mailto:'[email protected]' format is CORRECT, but it is an oversight in the code that 'REFER-TO' packets are not updated per the same rules as 'INVITE' packets. Please understand, I do not wish to be argumentative, and am simply pointing out what I have already tried. I have already spent significant time with Patton support trying to sort out the issue there, before referring the issue here. Cheers, and VERY respectfully, ...Steve... _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
