Then by all means open a jira and ask the dev-list their opinions on this. i would maintain you would want to try to maintain a native dialplan (no "99" stuff). That works fine for sending a call to a gateway to get processed and simply place a call. Transfers are more complicated. You should dial 4495 and send 4495. You should also try a siptrunk with the same IP as the patton gateway and see if the siptrunk provides any different behavior for the dial rule of 4495 (or whatever number range makes sense for what you are doing).
I don't think the invite is correct (994495) but it does not matter in a normal "place a call" mode. Once we leave the proxy for another sipdomain, that's really a different beast. Have you tried this as a siptrunk? On Wed, Sep 7, 2011 at 7:25 PM, Steve Beaudry <steve.beau...@royalroads.ca>wrote: > <grin> Gee, thanks J (About what you did with the grandstreams). **** > > ** ** > > I know there is some sentiment against them, but other than this issue > (and one other one, whereby when a CALLER (not the called-party) puts a call > on hold, they’re unable to retrieve it, but only if the phone is configured > for VLAN tagging), we’ve been able to overcome any problems we’ve had with > them.**** > > ** ** > > In this case, I can hardly blame grandstream, as they’re following the > expected behavior. When a call is transferred, it is transferred to > ‘xxxx’@registered.domain. (where xxxx is the dialed transfer-to number).** > ** > > ** ** > > The only two places that COULD affect this are the gateway, and the > proxy. I now have people from both camps telling me it’s not their > problem. Go figure. Can’t say I expected any different. I still maintain > that the proxy is NOT acting consistently. If it receives ‘ > INVITE:4...@voip.royalroads.ca’, it modifies it to ‘ > INVITE:994495@10.60.0.10’. If it receives ‘ > REFER-TO:4...@voip.royalroads.ca’, it doesn’t modify it. I believe that > it shouldn’t matter WHICH operation is received, it should update the URI > consistently.**** > > ** ** > > …Steve… **** > > **** > > ** ** > > *From:* sipx-users-boun...@list.sipfoundry.org [mailto: > sipx-users-boun...@list.sipfoundry.org] *On Behalf Of *Tony Graziano > *Sent:* Wednesday, September 07, 2011 4:10 PM > > *To:* Discussion list for users of sipXecs software > *Subject:* Re: [sipx-users] Transfer troubles : REFER-TO not > routed/modified according to the dialplan**** > > ** ** > > sipx is a proxy. it is not a proxy for another sip system such as an > unmanaged gateway acting as its own domain. the gateway os not part of its > framework, so yeah, we're not agreeing but systemically it (the gateway) is > its own entity.**** > > ** ** > > aks patton about a b2bua function on it, that might be what you need to > use, because that way "it" becomes part of the sipx environment. OR use a > SBC, or be more creative.**** > > ** ** > > I know you didn't want to hear about the UA thing, but like ITSP's and > everything else, they are not all equal.**** > > ** ** > > What I didn't tell you is what I did with my first grandstreams (chuckle), > may they rest in piece(s)...**** > > On Wed, Sep 7, 2011 at 5:58 PM, Steve Beaudry <steve.beau...@royalroads.ca> > wrote:**** > > 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 J**** > > **** > > Cheers,**** > > **** > > …Steve…**** > > **** > > **** > > **** > > *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: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" <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/**** > > > > **** > > ** ** > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: tgrazi...@voice.myitdepartment.net > Fax: 434.465.6833 > > Email: tgrazi...@myitdepartment.net > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: helpd...@voice.myitdepartment.net > > Helpdesk Contract Customers: > http://support.myitdepartment.net**** > > ** ** > > Blog:**** > > http://blog.myitdepartment.net**** > > ** ** > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4*** > * > > ** ** > > Ask about our Internet faxservices!**** > > ** ** > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: tgrazi...@voice.myitdepartment.net Fax: 434.465.6833 Email: tgrazi...@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Contract Customers: http://support.myitdepartment.net <http://support.myitdepartment.net>Blog: http://blog.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet faxservices!
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
