Avaya SM Call routing 2

[prei11y92]

Hello,

I have my Aura 6.3.4 environment up and working **for the most part**, I am not able to get calls to route inbound to SM. From SM CLI - traceSM I get the following message -> "cannot determine routing domain" ?? . Do I need an inbound routing adaptation ? I can definitely see the calls hitting SM, from the traceSM logs.

out bound or originating side, all calls work fine. EXT, AAR, ARS, UDP are working fine once the calls leave CM, and then route to the various trunks I have setup.

Love to get my inbound working, I have gone thru several Avaya App notes for various configs similar to what I have but nothing is jumping out at me.

Any one have any cheat sheets or other tips of what to try I am would be psyched for the assistance.

Thanks - PR

 

[redphone]

The domain in the Request URI & To Headers are unknown to SM. Have you added the domain name in System Manager? Home / Elements / Routing / Domains

You may need to add an Adaptation to change the domain name to one known by CM (Sig Group Far-end Domain). But it still needs to be added to the known domains in System Manager.

 

[prei11y92]

Redphone,

As always thanks for your reply, You are great resource to this community.

I have my domain name as aura.com and that is working fine, in the routing / domain tab. on out bound calls, CM appends all the sip calls with a properly formed uri, E.164-> xxx-xxx-xxxx@aura.com this is working perfectly to outbound pstn calls.

I do agree with you, I am pretty sure that I have a sip adaptation issue on my inbound calls
I tried to follow the "SM6ASBC_VzB_IPCC.pdf" (

http://downloads.avaya.com/css/P8/documents/100113361)

from the avaya dev connect site. In this well written app note, it does speak of the different inbound and outbound call treatments. I know this app note is not to be followed verbatim, but it does speak of inbound call conversion / digit conversion for calls destined to SM.

I have created a adaptation rule and just winged it the best I can (that is scarry), according to the Avaya app note "SM6ASBC_VzB_IPCC.pdf" (

http://downloads.avaya.com/css/P8/documents/100113361)

it walks one thru the steps to setup an inbound call adaptation. I must be doing something wrong. Ugh..

any insight would be great.

 

[redphone]

The internal domain is fine, what I am referring to is the domain used by your SIP provider. Using the App Notes you provided as an example, your aura.com is equivalent to avaya.com mentioned on pg 40. What I am referring to would be the equivalent to adevc.avaya.globalipcom.com also on pg 40, known by the Service Provider. Does the inbound Invite from your provider have a domain name in the Request-URI? If it is an IP address, it will not work. It has to be a domain name.

 

[prei11y92]

hi red phone,

I am not able to make any progress on the above, I really think I need an adaptation setup, I am messing around with all the ingress possible options, I am getting a 403 forbidden (invalid domain in the from: header

I am playing wound with various adaptions to see what is the right combo to get this working now.

thanks - PR

 

[prei11y92]

I keep getting an 404 error message. I have created a few different SIP adaptations and still no luck on in bound calls. I know for a fact that my inbound SIP call server only sends me a uri of xxx-xxx-xxxx@IP.com, I am not able to get it to come inbound as a @domain.com. I am not sure if there are any cheat sheets for SM routing out there. All the Avaya app notes seem to confuse the matter even more as there are numerous ways to perform ingress call SM routing.

I have followed the help pages closely and there appear to be numerous ways to perform digit conversion. Any help would be appreciated.

Thanks = PR

 

[prei11y92]

I have created some Avaya adaptations and my calls appear not to be using the adaptation, is there any reason for this, I have the adaptations assigned and still getting 404 not found error messages between CM and SM 100 ? anyone have any thouhgts on this. traceSM is running, still not finding anything conclusive at this point.

Thanks - PR

 

[redphone]

Make sure there are routing policies and dial patterns for the inbound number.

Can you post the details of the inbound INVITE? SM will not apply any Adaptations until it accepts the INVITE. If it is for a domain it does not know about, it will try to forward the INVITE to the right domain. And if the domain is invalid, or cannot be resolved via DNS, it could return a 404 error. Also post the details of the response from SM. In the above posts two separate codes are mentioned 403 and 404.

 

[prei11y92]

Hi Red Phone,

Here is the traceSM call out put for the call I am having issues with.

call flow is Gateway -> SBC -> SM -> Feature Server(CM) -> SM -> Phone.

originating call is 508-367-6584
destination is 781-443-7245 , a SIP 9641G provisioned on SM.
IP address = 192.168.2.130 for Acme SBC
IP address = 192.168.2.110 for ECB User Agent Sip Peer
IP address = 10.232.50.102 for SM100 (Sip Interface)
IP address = 10.232.50.103 for CM
Internal Domain = aura.com
Domain name for ECB sip peer = 192.168.2.110 there is no fqdn associated with this entity

Thanks - PR

--------------------
INVITE sip:7814437245@10.232.50.102:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.2.110:5068;branch=z9hG4bKf6iouo10agsa460g20s1.1
Via: SIP/2.0/UDP 192.168.2.130:5060;branch=z9hG4bK89kfkc30708g3oo2r1t1.1
From: <sip:5083676584@192.168.2.110>;tag=gK025753b8
To: <sip:7814437245@10.232.50.102>
Call-ID: 436363972_88080727@68.68.118.39
CSeq: 14856 INVITE
Max-Forwards: 8
Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:5083676584@192.168.2.130:5060;transport=udp>
P-Preferred-Identity: <sip:5083676584@68.68.118.39:5060>
Supported: timer,100rel
Session-Expires: 10800
Min-SE: 90
Content-Length: 329
Content-Disposition: session; handling=required
Content-Type: application/sdp
Cisco-Gucid: 351192d001e367e198b6000000000000
Record-Route: <sip:SD34ss6+skl6vuu1ta5rpfmopl86rrnh2-fhvjmk3008jq3@192.168.2.110:5068;lr;transport=tcp>
Record-Route: <sip:SD34ss6+skl6vuu1ta5rpfmopl86rrnh2-fhvjmk3008jq3@192.168.2.110:5060;lr;transport=udp>

v=0
o=Sonus_UAC 4221 22242 IN IP4 192.168.2.130
s=SIP Media Capabilities
c=IN IP4 192.168.2.130
t=0 0
m=audio 32762 RTP/AVP 0 8 18 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=sendrecv
a=ptime:20

--------------------
com.avaya.asm SIPMSGT
--------------------
18/12/2013 08:13:16.673 <--
octets: , Body Length:
ingress: [NO TARGET]
egress: { L10.232.50.102:5060/R192.168.2.110:8200/TCP/0xa }
APMsgContext: {
OOD Req: false, TH: true, instance: true, isSIPS req'd: false, closeOnSend: false, targeted: true, loose target: false, DNS pending: false, toSD: false, flow token: "448", resp retries: 0, req retries: 0,
}
--------------------
SIP/2.0 100 Trying
Call-ID: 436363972_88080727@68.68.118.39
CSeq: 14856 INVITE
From: <sip:5083676584@192.168.2.110>;tag=gK025753b8
To: <sip:7814437245@10.232.50.102>
Via: SIP/2.0/TCP 192.168.2.110:5068;branch=z9hG4bKf6iouo10agsa460g20s1.1
Via: SIP/2.0/UDP 192.168.2.130:5060;branch=z9hG4bK89kfkc30708g3oo2r1t1.1
Content-Length: 0


--------------------
com.avaya.asm SIPMSGT
--------------------
18/12/2013 08:13:16.677 <--
octets: , Body Length:
ingress: [NO TARGET]
egress: { L10.232.50.102:5060/R192.168.2.110:8200/TCP/0xa }
APMsgContext: {
OOD Req: false, TH: true, instance: true, isSIPS req'd: false, closeOnSend: false, targeted: true, loose target: false, DNS pending: false, toSD: false, flow token: "448", resp retries: 0, req retries: 0,
}
--------------------
SIP/2.0 404 Not Found (cannot determine routing domain, check SM ports)
Call-ID: 436363972_88080727@68.68.118.39
CSeq: 14856 INVITE
From: <sip:5083676584@192.168.2.110>;tag=gK025753b8
To: <sip:7814437245@10.232.50.102>;tag=560393293739322_local.1387275728070_76268_84840
Via: SIP/2.0/TCP 192.168.2.110:5068;branch=z9hG4bKf6iouo10agsa460g20s1.1
Via: SIP/2.0/UDP 192.168.2.130:5060;branch=z9hG4bK89kfkc30708g3oo2r1t1.1
Record-Route: <sip:rw-7d3b6d42@10.232.50.102;lr;transport=TCP>
Record-Route: <sip:SD34ss6+skl6vuu1ta5rpfmopl86rrnh2-fhvjmk3008jq3@192.168.2.110:5068;lr;transport=tcp>
Record-Route: <sip:SD34ss6+skl6vuu1ta5rpfmopl86rrnh2-fhvjmk3008jq3@192.168.2.110:5060;lr;transport=udp>
Av-Global-Session-ID: 2840ef10-67e6-11e3-94c5-000c29753491
Server: AVAYA-SM-6.3.2.0.632023
Contact: <sip:10.232.50.101:15060;transport=tcp>
Content-Length: 0


--------------------
com.avaya.asm SIPMSGT
--------------------
18/12/2013 08:13:16.788 -->
octets: , Body Length:
ingress: { L10.232.50.102:5060/R192.168.2.110:8200/TCP/0xa }
egress: [NO TARGET]
--------------------
ACK sip:7814437245@10.232.50.102:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.2.110:5068;branch=z9hG4bKf6iouo10agsa460g20s1.1
CSeq: 14856 ACK
From: <sip:5083676584@192.168.2.110>;tag=gK025753b8
To: <sip:7814437245@10.232.50.102>;tag=560393293739322_local.1387275728070_76268_84840
Call-ID: 436363972_88080727@68.68.118.39
Max-Forwards: 8
Content-Length: 0


--------------------
com.avaya.asm SIPMSGT
--------------------
18/12/2013 08:13:16.974 -->
octets: , Body Length:
ingress: { L10.232.50.102:5060/R192.168.2.110:8200/TCP/0xa }
egress: [NO TARGET]
--------------------
INVITE sip:7814437245@10.232.50.102:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.2.110:5068;branch=z9hG4bKgevsia20f850768fq0a0.1
Via: SIP/2.0/UDP 192.168.2.130:5060;branch=z9hG4bKa91iou30bof1dog296c1.1
From: <sip:5083676584@192.168.2.110>;tag=gK025756bd
To: <sip:7814437245@10.232.50.102>
Call-ID: 436363974_72820619@68.68.118.39
CSeq: 9788 INVITE
Max-Forwards: 4
Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: <sip:5083676584@192.168.2.130:5060;transport=udp>
P-Preferred-Identity: <sip:5083676584@68.68.118.39:5060>
Supported: timer,100rel
Session-Expires: 10800
Min-SE: 90
Content-Length: 330
Content-Disposition: session; handling=required
Content-Type: application/sdp
Cisco-Gucid: 353fa7b001e367e19037000000000000
Record-Route: <sip:SD34ss6+skl6vuu1ta5rpfmopl86rrnh2-fhvjmk3008jq3@192.168.2.110:5068;lr;transport=tcp>
Record-Route: <sip:SD34ss6+skl6vuu1ta5rpfmopl86rrnh2-fhvjmk3008jq3@192.168.2.110:5060;lr;transport=udp>

v=0
o=Sonus_UAC 17120 31653 IN IP4 192.168.2.130
s=SIP Media Capabilities
c=IN IP4 192.168.2.130
t=0 0
m=audio 32766 RTP/AVP 0 8 18 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=sendrecv
a=ptime:20

--------------------
com.avaya.asm SIPMSGT
--------------------
18/12/2013 08:13:16.975 <--
octets: , Body Length:
ingress: [NO TARGET]
egress: { L10.232.50.102:5060/R192.168.2.110:8200/TCP/0xa }
APMsgContext: {
OOD Req: false, TH: true, instance: true, isSIPS req'd: false, closeOnSend: false, targeted: true, loose target: false, DNS pending: false, toSD: false, flow token: "448", resp retries: 0, req retries: 0,
}
--------------------
SIP/2.0 100 Trying
Call-ID: 436363974_72820619@68.68.118.39
CSeq: 9788 INVITE
From: <sip:5083676584@192.168.2.110>;tag=gK025756bd
To: <sip:7814437245@10.232.50.102>
Via: SIP/2.0/TCP 192.168.2.110:5068;branch=z9hG4bKgevsia20f850768fq0a0.1
Via: SIP/2.0/UDP 192.168.2.130:5060;branch=z9hG4bKa91iou30bof1dog296c1.1
Content-Length: 0


--------------------
com.avaya.asm SIPMSGT
--------------------
18/12/2013 08:13:16.978 <--
octets: , Body Length:
ingress: [NO TARGET]
egress: { L10.232.50.102:5060/R192.168.2.110:8200/TCP/0xa }
APMsgContext: {
OOD Req: false, TH: true, instance: true, isSIPS req'd: false, closeOnSend: false, targeted: true, loose target: false, DNS pending: false, toSD: false, flow token: "448", resp retries: 0, req retries: 0,
}
--------------------
SIP/2.0 404 Not Found (cannot determine routing domain, check SM ports)
Call-ID: 436363974_72820619@68.68.118.39
CSeq: 9788 INVITE
From: <sip:5083676584@192.168.2.110>;tag=gK025756bd
To: <sip:7814437245@10.232.50.102>;tag=6005493760698497_local.1387275728070_76269_84841
Via: SIP/2.0/TCP 192.168.2.110:5068;branch=z9hG4bKgevsia20f850768fq0a0.1
Via: SIP/2.0/UDP 192.168.2.130:5060;branch=z9hG4bKa91iou30bof1dog296c1.1
Record-Route: <sip:rw-7d3b6d42@10.232.50.102;lr;transport=TCP>
Record-Route: <sip:SD34ss6+skl6vuu1ta5rpfmopl86rrnh2-fhvjmk3008jq3@192.168.2.110:5068;lr;transport=tcp>
Record-Route: <sip:SD34ss6+skl6vuu1ta5rpfmopl86rrnh2-fhvjmk3008jq3@192.168.2.110:5060;lr;transport=udp>
Av-Global-Session-ID: 286f2b00-67e6-11e3-94c5-000c29753491
Server: AVAYA-SM-6.3.2.0.632023
Contact: <sip:10.232.50.101:15060;transport=tcp>
Content-Length: 0

 

[redphone]

The Invite has an IP address in the Request-URI, so it is unable to determine the routing domain. SM can insert the domain based on the port to which it receives SIP messages. From your trace, it appears as though the INVITE is sent to UDP port 5060. So add this port to the SM SIP Entity and select a default domain for it.

Home / Elements / Routing / SIP Entities

Select the SM Entity; scroll down to Ports section and add the following:

Port        Protocol          Default Domain
5060          UDP                aura.com

The 404 error message also hints to this:
SIP/2.0 404 Not Found (cannot determine routing domain, check SM ports)

 

[prei11y92]

OK resolved the issue PHEW

http://WWW that

stumped me.
in this Avaya app note (

http://www.onestreamnetworks.com/PDFs/avaya_onestream_cm_sm_sbce_2013.pdf)

this app note paralleled my setup fairly close, I discovered a few config issues.
the largest being that I did not specify in SMGR /routing/sip entities - the Port number on the SM Sip Entity config page, at the very bottom of the page I had not assigned 5060 / TCP. Once, I committed the changes and let replication do its thing, next thing you know inbound calls are working fine. SM needed to specifically be told to use what port, hence the 404 error message I was getting. I thought that parameter applied to the tcp /tls Failover ports, I said to myself I am not doing any failover so I don't need to specify the ports.
UGh that was 4 days I will never get back again of lost time.

glad this is put to rest. Redphone - thanks for your input, it was helpful

- PR

 

[prei11y92]

Redphone,

your recent Posting is spot on and came into Tek Tips the very instant I figured out the issue from an Avaya app note I was looking at.

Thanks for your response they came in handy!!