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" <[email protected]> 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:* [email protected] [mailto: > [email protected]] *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 <[email protected]> > wrote:**** > > > Content-Type: text/plain; > charset="utf-8" > Content-Transfer-Encoding: 8bit > Organization: SipXecs Forum**** > > In-Reply-To: <CAMgKNJVaKB4cG3Q6jFMM=hqPoV+=k3jo=WieGqzFb= > [email protected]> > X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <66564> > Message-ID: <[email protected]> > > > > 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 > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/**** > > > > **** > > ** ** > > -- > ~~~~~~~~~~~~~~~~~~ > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > 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: [email protected]**** > > ** ** > > Helpdesk Customers: http://myhelp.myitdepartment.net**** > > Blog: http://blog.myitdepartment.net**** > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
