Incoming Call Route - SIP Trunk

[dbal640]

Hello All,

We have a SIP trunk with about 4 DID's and 2 TF coming over it. We would like all but one TF to answer to our main IVR application. I'm trying to route one of the TF# 855-405-9160 but to no luck; it goes into the IVR with the other lines. I've tried to setup a SIP URI with this number in it and then set an incoming call route with this number to the appropriate extension. Anyone see what I'm missing?

Thanks!

 

[amriddle01]

Are the TF numbers actually presented to the system? Normally they are pointed to a normal DID number (by the provider) and then you route that, but with SIP they can do either, again... depending on provider



"No problem monkey socks

 

[dbal640]

I was told there are just sending down the trunk. That's why I was wondering how to setup as I'm used to assigning to a DID.

The sip log attached was when I called the TF#.

 

[dbal640]

Any ideas?
What I think may be happening is the first URI is picking up all the traffic and it's not routing the 2nd URI. Does it matter what order I have them in? Should I put in a URI for all of the DID's?

 

[Billx1]

Here is what I think is happening:

The provider is sending the Toll Free DID in the "To:" area.....Not in the request URI area...

INVITE sip:935692489@172.16.1.199:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 208.73.146.95:5060;branch=z9hG4bK2qcrfi20dgj042tpn3c1.1
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Call-Id: pcst1377543261942301273113@192.168.201.111
Contact: <sip:9034395922@208.73.146.95:5060;transport=udp>
Content-Disposition: session; handling=required
Content-Length: 306
Content-Type: application/sdp
CSeq: 1 INVITE
From: <sip:9034395922@192.168.101.111:5060;pstn-params=808482808882;cpc=ordinary>;tag=gK044afa6a
In-Reply-To: 2097414747_130396737@64.152.60.74
Session-Expires: 7200;refresher=uas
Supported: timer
------------>>>>>> To: <sip:8554059160@192.168.101.100>
Max-Forwards: 70


Try changing the "Call Routing Method" in the SIP Line tab (of your SIP Trunk/Line)
from "Request URI" to "To Header".

Call Routing Method: Default = Request URI. Release 6.0+.
This field allows selection of which incoming SIP information should be used for incoming number matching by the system's incoming call routes. The options are to match either the Request URI or the To Header element provided with the incoming call.

If that works, then also try the other DID Numbers to see if they work.

There were no examples of any other incoming calls in your SIP Trace to see where the provider sends the other DIDs'.

I would like to believe they are all sent the same way.

I hope this helps you.

 

[dbal640]

Changing it to 'To Header' fixed the issue.

Thanks for all your help!!!

 

[Billx1]

OK

I am glad to hear that this solved the trouble.