Search results for query: *

I am getting a call rejected error when I make a call over our SIP trunk from a IP or POT phone. I have no issues however with the digital phones using the SIP trunk which is very weird. Am I supposed to do some thing to make this work? I thought it would be the same setup for all the phones...

To make it more clear. I am using in this case my SIP Line as my PSTN connection, so when a user dials 9,1-XXX-XXX-XXXX they use a SIP Line. ARS Entry is: Code=1N; Telephone number=1N"IPADDRESSofSIPProvider" Feature=Dial, Line Group ID = 1 (same as SIP LINE)

I know of course that IPO 56xx sets are H323, but do the calls shuffle if calls are made from IP Phone to SIP Trunk so not to use VCM resources?

Thats silly that they would not come out with the feature with the ability to do that. Seems like a pretty easy thing to code in. oh well.

You could make a "fake" user in the main location and set up an unconditional forward to the other extension or direct number in the remote site. add the fake user to the hunt group. That should work.

I have seen this mentioned but not a resolution. Does any one know how to remove the "@xxx.xxx.xxx.xxx from caller ID as it is very annoying, especially in voicemail. I have to tackle this tomorrow so any insight will be great.

Thanks technicaluser4. That idea worked. I change my 1N to include "@sipprovider.com" . Actually we used the ip address and that worked.

We had to implement incoming call routes the following way to make it work. For incoming number we used -1718XXXXXXX. The dash forces IPO to read DNIS from left to right. When we removed it does not work. Hope this helps a bit.

We tried it the Tel URI option ticked and not ticked. it still sends out the same way as TEL:+1718XXXXXXX. I am going to try to kill the sip line and re-create. It seems no one else really has this issue. Maybe it is a fluke. Ill let you know. Thanks all!

Thats embarrassing! Not your fault though. This is either something really easy to fix or a deep coding issue.

We have set up a SIP Trunk on our 406 unit for testing. Incoming calls work perfectly, the issue is out going. Since the Softswitch is ours we are able to view the invite messages to diagnose the issue. Basically the invite is being sent from the IP Office to the softswitch with: invite TEL...