Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Organization: SipXecs Forum In-Reply-To: <CAMgKNJWQao0SctwLUTHgeO610cdARSWkxW22LTgU8n=uyay...@mail.gmail.com> X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <63116> Message-ID: <[email protected]>
Hi Tony, So, in reading, re-reading, and re-evaluating things based on what you and others here have said, I think I've realized that the scope of affected transfers is smaller than I thought (although, still critical for us). The issue only occurs when a call comes in through the patton gateway, to a SipXecs extension, which is subsequently transferred/forwarded to an extension that is only reachable back via the Patton gateway. I believe I've seen this referred to as a 'hairpin' call. As you mentioned, you thought the difference (routing looking, and therefore the URI transition) should happen during the INVITE. This certainly works in all cases where the call is initiated on the SipXecs server (ie. using one of the SipXecs registered endpoints), but in this case, the PATTON is responsible for creating the INVITE in response to the transfer, not the SipXecs server. You can see this behaviour at line 521 of the 'External to VoIP DID transferred to Nortel extension.txt' file I attached earlier. The Patton is doing exactly as it is instructed in the REFER-TO request, and attempting to transfer the call to mailto:'[email protected]'. On the somewhat separate topic of preceeding 4-digit extension numbers with a '99' when dialed, you're right, in hindsight, we could have done without it. This was as much to help with our Nortel dialplan as anything. It does not affect the current issue (the transfer doesn't work if I try to transfer to 994495 either), and I simply pointed it out to give another indication as to where the trouble existed. I should also point out that this works quite well, and is well within the realm of 'correct configuration', done via the standard interface, regardless of whether it's how you would do it or not. It is completely transparent to the end user. What I'm hearing from you is, the SipXecs server does NOT lookup/translate/modify numbers in REFER-TO packets, because it is believed that any translation can be handled during the resulting INVITE. I believe that, in the case of 'hairpin transfers', where the SipXecs server is NOT responsible for creating the INVITE resulting from a REFER-TO, this approach falls short. ...Steve... _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
