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" <steve.beau...@royalroads.ca> 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: sipx-users-boun...@list.sipfoundry.org [mailto: sipx-users-boun...@list.sipfoundry.org] 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" <steve.beau...@royalroads.ca <mailto:steve.beau...@royalroads.ca>> wrote: >> >> Content-Type: text/plain; >> charset="utf-8" >> Content-Transfer-Encoding: 8bit >> Organization: SipXecs Forum >> In-Reply-To: <CAMgKNJWQao0SctwLUTHgeO610cdARSWkxW22LTgU8n= uyay...@mail.gmail.com<mailto:uyay...@mail.gmail.com>> >> X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <63116> >> Message-ID: <f68c.4e67d...@forum.sipfoundry.org<mailto: f68c.4e67d...@forum.sipfoundry.org>> >> >> >> >> 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:'4...@voip.royalroads.ca<mailto:4...@voip.royalroads.ca>'. >> >> >> >> 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 >> sipx-users@list.sipfoundry.org<mailto:sipx-users@list.sipfoundry.org> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
