Sip and DID The docs claim the following.. 1

[Notsetinstone]

SIP Calls
For SIP calls, the following fields are used for call matching:

· Line Group ID
This field is matched against the Incoming Group settings of the SIP URI (Line | SIP URI). This must be an exact match.

· Incoming Number
This field can be used to match the called details (TO) in the SIP header of incoming calls. It can contain a number, SIP URI or Tel URI. For SIP URI's the domain part of the URI is removed before matching by incoming call routing occurs. For example, for the SIP URI mysip@sipitsp.com , only the user part of the URI, ie. mysip, is used for matching.

· Incoming CLI
This field can be used to match the calling details (FROM) in the SDP header of incoming SIP calls. It can contain a number, SIP URI, Tel URI or IP address received with SIP calls. For all types of incoming CLI except IP addresses a partial entry can be used to achieve the match, entries being read from left to right. For IP addresses only full entry matching is supported.

Matching based on the to field will not work for me. The only way I can get DID to work is a group fo each one in the SIP URI tab. This seems to go against what is written above.

The question is why can't I use one line group with multiple "to's" based on the ICR's Incoming number field
?

 

[tlpeter]

You should be able to use the ICR like you always do
So one incoming id (probably 17)
Then make multiple ICR with DDI number
If that does not work then your provider is not sending the right information


ACA - Implement IP Office
ACS - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[IPOfficeIreland]

this is a very common question:

create 1 sip trunk with 2 uris
1st uri use auth data or whatever your registration details are
2nd set to use User Data

In each user they now have a SIP tab - this is where you put your DDI number.

In incoming routes do exactly as normal, DDI number 201 line group as above, destination.

When a call is received the IPO looks at the SIP trunk settings and trys to match the UIR that it is receiving, 200 OK. The SIP settings detail @whatever part and the uri details look in the user tab, e.g. 201

The provider must send a DDI call as 201, etc so that you can distinguish between the various calls. Some providers just send every call to the main account which simply does not work.

For proper DDI working you will be recommended to have a trusted IP source with the provider rather than registration as depending on the server calls might not be able to be pointed at single IP, but various accounts instead. You can post traces here for pointers, but inevitably you will have to speak with the provider.

 

[Notsetinstone]

Thanks both for the input. It looks like the user sip tab has nothing to do with incoming, just out going. Please correct me if I am wrong.

The only way I was able to make DID work, to this point, is create other URIs on the trunk with DIFFERENT TRUNK GROUPS and route the call based on trunk group. I can see in monitor that the provider is sending the correct number in the to field, but the IPO is sending 404 not found. This is only resolved based on the URIs and different trunk groups.

 

[IPOfficeIreland]

No, it has to do with incoming and outgoing, as do the SIP URI settings.

You would only create multiple URIs depending on the config but for standard setup create 2.

1 for the main SIP account - non DDI - set to use Authentication Data and put the CLIP you want shown in Display Name, if different to registration name. You can use this trunk group for all outgoing calls if you prefer.

Next, create a new URI with new Trunk Group but this time set it to use User Data for all fields. If you don't want to show each users DDI for outgoing calls then put the DDI number to be shown in Display Name under User Tab, otherwise leave it up to each user to choose.

In the USER SIP field, SIP Name, this is where you put the digits from the provider, i.e. 201 (201@).

Set your outgoing rules to use the USER URI Trunk Group as needed.

ICR DDIs will also come in on the User URI Trunk Group.
Main Call will come in on Main URI Trunk Group.

To add more confusion, you could just have 1 TG with all set to Use User Data, create a virtual user and in SIP Tab put in the main account sip details. This means that the IPO will see a valid URI string (200 OK) and not return "not found", 404, accepting the call.

The main reason for doing it this way is you don't want to be creating a new URI for every DDI, if you do you will have to reboot every time. Changing USER sip info does not require a reboot. On that note, you can do a Merge config and it works, but I didn't say that

 

[Notsetinstone]

I agree, accoring to the doc I shouldn't have to do that. So are you saying that inbound DID is only controlled by The user Tab in your example?? What If I want a particular DID to go to a vm module or shortcode? Then I would have to set up more URIs right?

 

[IPOfficeIreland]

Sort of, the User SIP tab validates the URI so the IPO will accept the call. The call route, however, is still controlled in the ICR, e.g. to Voicemail. So you can create as many Virtual users with SIP tabs to match the DDI or create URIs to match, the User bit doesn't require restart, that's the advantage.

 

[Notsetinstone]

The SIP provider I am working with now is the 4th one. Each time I work with one, I hear the same thing, "Avaya does it different". SIP is very so different from PRIs and T1s that I couldn't really tell if that were true. I think I am starting to agree.

 

[djweis]

Just to add another, Avaya does it different. If it works at all consider yourself lucky.