No not anymore. The new SBC has 2 interfaces one facing SIPX and the other is facing ITSP From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Tony Graziano Sent: Wednesday, March 14, 2012 8:54 PM To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] Signaling issues on new install Your environment in an all gateway environment because your SBC has only one interface. It has nothing to do with the original post. On Mar 14, 2012 8:27 PM, "S.K.- G" <skhan...@gmail.com> wrote: We are experiencing similar problems, started after the phone registration were moved to an external SBC(ACME 3820),,,,,,,,,,,. We were working on changing our deployment by updating our core network design, just completed the change this morning, our call flow became: Polycom >> SIPX>> SBC>> ITSP .. All Polycom registration are done through the SBC.. We are having the following issues: 1. The MWI stopped to update itself. 2. The MOH has also stopped to play . 3. The caller ID setting on the "unmanaged Gateway" that is supposed to override the users CLID is not taking in place and not working .. Also the CLID is showing the extension number no matter what the setting was on the extension caller ID settings. 4. The call forwarding is still OK ; however, the attended AND Unattended transfer failed to work. Obviously, This external registration of the polycom phones has severely affected other features and ACME support are asking us to resolve our SIPX issues ..I know I need to support my findings with Traces but will do so after our firewall is deployed in place ;). Is there by chance a way to treat ACME 3820 as a "MANAGED" gateway? Can we use ACME 1000 for it? Regards Saad Khankan From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Tony Graziano Sent: Tuesday, March 13, 2012 6:57 PM To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] Signaling issues on new install With other SBC's, it holds the refer locally and negotiates between the two (UA and ITSP), and thats what the Acme needs to do in this case. The UA (phone) knows how to handle REFER, and if sipxbridge is handling the trunking or remote users, it also holds the refer and doesn't transmit it to the provider. On Tue, Mar 13, 2012 at 6:22 AM, Emilio Panighetti <emilio...@me.com> wrote:
Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Organization: SipXecs Forum In-Reply-To: <CAMgKNJVaKB4cG3Q6jFMM=hqPoV+=k3jo=WieGqzFb=4-ok-...@mail.gmail.com> X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <66564> Message-ID: <10404.4f5f1...@forum.sipfoundry.org> Tony Thanks for getting back to me. The SBC is an Acme Packet. The way we have it set up; in relation to sipXecs is as follows: The SBC has 'access'; 'peer' and 'core' realms. When an IP phone registers; it does it through the 'access' realm; which performs NAT traversal and routes the call to sipXecs via its core realm. sipXecs sees the device as not behind NAT. When calling voicemail or conference bridge on sipXecs; there is only one session going from the IP phone though the SBC to sipXecs. When I dial a PSTN number; the call has the same flow as above except that sipXecs proxies the INVITE to the SBC on its 'peer' realm. The SBC in turn transparently delivers the call to the appropriate PSTN trunk. sipXecs sees the peer realm as a gateway; as in there are no registrations. The SBC is configured to anchor media from the IP phone to sipXecs, but it doesn't anchor media on the peer realm. So let's say we have a call established as: IP Phone -> [SBC access] -> [SBC core] -> sipXecss -> [SBC peer] -> SIP Trunk provider media is anchored at the SBC: The IP phone sees [SBC access] media address and everything else after that sees media coming from [SBC core]. Both of these are routable IPs; so this suits the needs. Now the IP phone initiates an unattended transfer to another PSTN number. the REFER shows the same path as above; but [SBC peer] is configured to reject the REFER because [SIP Trunk provider] does not allow the REFER method; so the REFER cannot be completed. My expectation; after using other software like FreeSHITCH; was that sipXecs would consume the REFER and in turn generate another INVITE towards PSTN number [SBC peer]. Seems I'm mistaken in my expectation here. For MOH; what I, perhaps naively; though it would happen is that if sipXecs receives a ReINVITE originated from the IP phone where its SDP contains 'a=sendonly'; it would ReINVITE the PSTN leg to its IVR which is playing MOH. Once the IP phone sends another ReINVITE with 'a=sendrecv'; sipXecs then forwards that SDP so its IVR in no longer on the call. my questions in regards to sipXecs is what is the expected behavior in this case when it receives a REFER or the On-hold signal from the IP phone. Thanks _______________________________________________ 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 ~~~~~~~~~~~~~~~~~~ Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 Ask about our Internet Fax services! ~~~~~~~~~~~~~~~~~~ LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
