Thanks Tony. You're correct, I would not like to hear 'use Polycom handsets', as the same issue exists for me using Grandstream, Snom, and Counterpath softphone UAs, but specifically because I have already deployed over 100 Grandstream handsets in production, and have another 370 on hand, ready to deploy.
It seems that you and I are at an impasse with a difference of opinion regarding a SIP Proxy server. The SipXecs proxy server ALREADY checks REFER-TO requests against the permissions, to see if a user is ALLOWED to forward to the number attempted, which is what results in the authentication packets before the REFER-TO is passed on. It WELL within the scope of the proxy to update/modify the packet when if forwards the REFER-TO request after it has taken the time and network packets to challenge and authenticate the transfer request. The SipXecs proxy does not blindly forward the REFER-TO request, rather it creates a NEW request, and sends it on. Adding an SBC, or reconfiguring the Patton to act as a B2BUA, simply to overcome a single transfer issue, doesn't seem even close to reasonable. You told me I was over complicating it already :) Cheers, ...Steve... From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Wednesday, September 07, 2011 2:41 PM To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] Transfer troubles : REFER-TO not routed/modified according to the dialplan you don't. you do if you don't have something parsing or rewriting it correctly., or is incapable of doing it. sipx is a proxy. if you are connecting as an unmanaged gateway, this should work fine. at the same tine I ha e seen this dine with older necessary pbx systems and have not heard of call transfer issues. you could also set this up as a siptrunk or as a b2bua in the patton with the patton essentially registering to sipx. I would not curry favor with you in suggesting to use a polycom handset as the sipx ua, which is the only way I have seen it done. sometimes the least common. component (ua) poses the greatest difficulty. you might inquire of patron whether they can make you a b2ua on the patton to be the middle ma. between the two systems. On Sep 7, 2011 5:33 PM, "Steve Beaudry" <[email protected]<mailto:[email protected]>> wrote: > 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]> > > [mailto:[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]><mailto:[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]><mailto:[email protected]<mailto:[email protected]>>> >> X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <63116> >> Message-ID: >> <[email protected]<mailto:[email protected]><mailto:[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]><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]><mailto:[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/
