So if I get a call it always goes to the same trunk 900 on CM from SMGR with Routing Policy that has a procr and entity link already established. I want the call on 901, but not sure how to make it so? Sig has far-end node name, far end Domain and listen ports, What ties the trunk to SMGR.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations dencom on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
What tie's the incoming trunk between CM and SMGR? 2
- Thread starter Saiyan656
- Start date
-
1
- #2
dialtonebone
Technical User
CM accepts SIP calls from Session Manager, not System Manager.
Domain based routing, less limited:
Inbound SIP to CM will start looking at the lowest signal group first for a matching domain until it finds the first match. Build your signal groups so that you have a domain for each service that needs a specific trunk.
SIP Port based routing, maxes out CM max SIP ports value:
Create a link and sig+trunk group combo with a unique port for each unique trunk group
Domain based routing, less limited:
Inbound SIP to CM will start looking at the lowest signal group first for a matching domain until it finds the first match. Build your signal groups so that you have a domain for each service that needs a specific trunk.
SIP Port based routing, maxes out CM max SIP ports value:
Create a link and sig+trunk group combo with a unique port for each unique trunk group
- Thread starter
- #3
Thanks Randy for the clarification! I am using Domain routing. I think what is happening is that since my sig has company.com and my sig tie incoming is using a sub domain abc.company.com it going to the path of company.com. So should I change my sub domain coming in to abc.company.co or abc.company.org? Something that is not going to link to main domain by default.
Here's how CM picks what sig group takes a call:
If the near/far IP/port are the same - like many sig groups to a SM
CM will use the lowest numbered sig group where the entirety of the far end domain fits in the invite.
That means your most explicit subdomains should be the lowest numbered (like inbound.ivr.you.com) and your most general domains - like you.com being the highest numbered.
If sig group 1 has domain you.com and sig 2 has inbound.ivr.you.com, an invite to 1234@inbound.ivr.you.com or @ivr.you.com or @you.com all get grabbed by sig 1 because the entirety of you.com fits.
If the near/far IP/port are the same - like many sig groups to a SM
CM will use the lowest numbered sig group where the entirety of the far end domain fits in the invite.
That means your most explicit subdomains should be the lowest numbered (like inbound.ivr.you.com) and your most general domains - like you.com being the highest numbered.
If sig group 1 has domain you.com and sig 2 has inbound.ivr.you.com, an invite to 1234@inbound.ivr.you.com or @ivr.you.com or @you.com all get grabbed by sig 1 because the entirety of you.com fits.
- Thread starter
- #5
Almost there with you..Ok so you say lowest number Sig number? Are you talking sig number 1-999 or you talking lowest domain like company.com via abc.company.com as a higher sub domain?
So I should make abc.company.com sig 10 and company.com sig 99 reverse current sig number to make it work?
So I should make abc.company.com sig 10 and company.com sig 99 reverse current sig number to make it work?
-
1
- #6
You got it.
Where ip/port/near/far match many sig groups, CM answers the call on the sig group with the lowest actual number - like sig 10 if sig 10's far end domain fits completely within the domain of the invite.
sig 999 should be company.com. sig 1 should be most.subdomains.within.company.com.
If you have 100 sig groups to SM all with domains/subdomains of company.com and sig group 1's far end domain is company.com, everything incoming from SM will hit sig group 1
Where ip/port/near/far match many sig groups, CM answers the call on the sig group with the lowest actual number - like sig 10 if sig 10's far end domain fits completely within the domain of the invite.
sig 999 should be company.com. sig 1 should be most.subdomains.within.company.com.
If you have 100 sig groups to SM all with domains/subdomains of company.com and sig group 1's far end domain is company.com, everything incoming from SM will hit sig group 1
- Thread starter
- #7
- Thread starter
- #8
Still same issue. So I made abc.company.com sig 10 and company.com sig 99. When I get the invite it shows abc.company.com and also in the CM trace, but still goes to company.com sig/trunk 99. I check spelling and all looks good.
Also both sig's are in same ip-network-region with authoritative domain:company.com - not sure if this does anything? I am out of ideas and document on web is not to good. Using port 5061 throughout.
Also both sig's are in same ip-network-region with authoritative domain:company.com - not sure if this does anything? I am out of ideas and document on web is not to good. Using port 5061 throughout.
authoritative domain is the domain the region can provide service for. Important for SIP phones, less so for trunks.
network region shouldn't terribly matter - that'd come into play once the sig group is picked.
What's the other end? Is abc.company.com in the INVITE and TO and FROM and PAI headers?
network region shouldn't terribly matter - that'd come into play once the sig group is picked.
What's the other end? Is abc.company.com in the INVITE and TO and FROM and PAI headers?
- Thread starter
- #10
What's the other end? Is abc.company.com in the INVITE and TO and FROM and PAI headers? No
see below:
To: sips:xxxxxx@abc.company.com
From: sips:xxxxxx@company.com (my 9611 phone reg to same system across SM routing)
PAI: sips:xxxxxx@company.com ("")
see below:
To: sips:xxxxxx@abc.company.com
From: sips:xxxxxx@company.com (my 9611 phone reg to same system across SM routing)
PAI: sips:xxxxxx@company.com ("")
The invite has a URI in it to. like, INVITE 1234@abc.company.com with a TO, FROM and PAI after.
What's the other end of the call? Maybe an adaptation on it's entity to override domains to be all abc.company.com?
That says the match is on PAI, so that would explain it!
What's the other end of the call? Maybe an adaptation on it's entity to override domains to be all abc.company.com?
That says the match is on PAI, so that would explain it!
- Status
Similar threads