You realize that in the case of a dialed call (if a SipXecs user picks up a grandstream phone and dials) to 4495, the SipXecs server DOES rewrite the headers, and the rules exist on the patton to route the call correctly?
I'm afraid that I don't understand why I should need an SBC simply to handle a transfer between two systems, when dialing back and forth between those systems works properly. From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Wednesday, September 07, 2011 2:27 PM To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] Transfer troubles : REFER-TO not routed/modified according to the dialplan I think its important to say that sipx and sipxbridge as an sbc is designed to handle pstn sip trunks. I think you expect sipx and an unmanaged gateway to do more than they should. I do think with the patton handles a refer properly. I don't think id expect sipx or the patton to rewrite the header, invite or refer. you would need an sbc to do that. at the same time if 4495 is dialed and sent to the patton I think a match rule can be in applied on it to make sure it gets handled properly. i expect the patton engineer you are speaking with can probably pull this off. On Sep 7, 2011 5:17 PM, "Steve Beaudry" <[email protected]<mailto:[email protected]>> wrote: > > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: 8bit > Organization: SipXecs Forum > In-Reply-To: > <CAMgKNJWQao0SctwLUTHgeO610cdARSWkxW22LTgU8n=uyay...@mail.gmail.com<mailto:[email protected]>> > X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <63116> > Message-ID: > <[email protected]<mailto:[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]<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]<mailto:[email protected]> > List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
