sundance-communications.com/forum Forums TDM Business Telephone Systems Samsung Telephones & Systems OS7200S: 2 strange problems

I have a client (medical offices) with 2 locations. Each location has a PRI from Paetec with MPLS with SIP trunk handoff. Each site is equipped with an OS7200S (4.46d) & an OAS card (MGI channels). I have 2 problems:

1) No MOH on SIP trunks only: Moh works on SPnet trunks, copper trunks, interoffice & BGM. Have verified SIP carrier options: Hold Reinvite on, & PBX type PBX managed 2. (Also tried Server & PBX 1 with no change.) Paetec ran wire shark and is seeing hold reinvite. MP card is connected to 192.168.1.5 and OAS card is 192.168.1.6. Wireshark looking for hold reinvite on 192.168.1.5. Doesn't the audio come from MGI channel (192.168.1.6)? Is this where the problem lies. Samsung says it is a carrier issue (what a surprise)

2) IP phones have no audio: Currently both 830 & 831 are set to Private and no public IP address is entered. When I change it to private it with public and enter public ip address, the SIp trunks get shut down. The carrier sees the PUBLIC IP addres instead of the 192.168.1.5. So, I've restored settings to Private only with no Public IP address. Paetec is unable to add in the public IP address from their records for SIP trunks to allow traffic.

Not sure if anyone has a suggestion to resolve these issues.

Also wondering if we convert from SIP trunk handoff to PRI handoff and install (2) PRI cards if both problems would be resolved.

Thank you in advance for your feedback!

Hold re-invite from the MP card is correct, as it is responsible for all signalling.

Check you MOH settings for the SIP trunks.
Are these incomming SIP? if so check DID for MOH option.

The private/public behaviour is correct.
Why does the carrier need to see the internal ip address for the SIP trunks rather then the public ip?

You could try re-enabling private with public and then play with the sip peering option in the SIP Options MMC

Just thought of a possible solution

In private IP trunk MMC (PM Sent) add the ip address of the sip server(s)m this will make the OS use the private network to get there rather then public

Thanks for taking the time to reply. The MOH is an external device located at the customer's premises. I've verified teh MOH designation in the DID table is the external unit as well as in the TRunk configuration section in Port common data(IT 2.4.2) is also configured for the external MOH unit. I've tried setting these to tone instead, and still have silence.

The ITSP carrier tells me that they register the SIp trunking using their private IP address on their MPLS/ADtran router. They have confirmed that when I add in the public ip address, they have no way of routing the calls because the Samsung outputs the public ip address not the private. In 838, Samsung tech support had me do a broadcast of the Private IP address; 192.168.1.255. This also had no change

I would put the sip server in rather then a broadcast.

I was under the impression from samsung here that ranges/broadcast arn't supported (which is annoying).

In regards to your MOH issue, are calling ringing in direct to a handset or going via upfront AA?

I have Samsung here looking into an issue on OS7030 where calls comming in on SIP trunks are answered by upfront AA and then transfered to extension, the caller doesn't get MOH, so I wonder if the same issue occurs in the OS7200s

I think Paetec is unique in wanting to see the private IP, since the SIP connectivity is actually first communicating on their 'private' MPLS Paetec network.

This was a real pain for us at one job so they were able to make it a DHCP registration for us instead.

On ANY of these SIP jobs, Broadvox or whoever, set up your service as DHCP, not static, if you have the choice. If you end up needing to test the service at some point you then have totally flexibility. It isn't tied to a specific IP.

For instance, we have Broadvox SIP at our office. Let's say a customer's SIP service goes down at a site and won't re-enable. The first step we would take, that can be all done remotely, is disable the SIP service at the customer's site.

Then we enter their information as SIP service #2 at our office and try it. It is fails, we know there is a Broadvox issue. It is works at our office, we know we have a site equipment or internet/router issue.

BTW, if you don't have SIP service, but have a Samsung 7000-series system, Samsung will give you (as in DEALERS only) access to their SIP server in Texas for testing.

Following. I'm also having dead air on VM transfers.