Avaya SIP trunk to third party adjunct drops call after 3 seconds, does not send ACK

[SchuylerJ]

thread690-1743513

Hey there,

I've been scrubbing the forums for a couple weeks and I see some similar issues to what I am facing.

Here's the scenario:

Avaya CM 7.0, Third Party SIP Application, Avaya SM 7.0.1

Basically, I have set up a direct SIP trunk to our Third Party application from CM. The third party application is listening on port 5060 for traffic, then launches the application. (both are on the same network).

However, the call hits the trunk, hits the application, then the call is terminated (after 3 seconds). The trace on the application side looks like this: (See attachment 1)
It is sending the ACK then several 200 trying before sending the BYE. The CM never responds to the ACK from the application. I've tried about every config of the trunk and signalling group that I can find, adjusted the minimum refresh timers, adjusted codecs, all with no success.

The kicker is that in another system running CM 5.1 we have the EXACT same configuration and the application works fine. Could this be an issue with the newer releases of CM/SM?


Has anyone seen this issue?

Thanks!

 

[kyle555]

What's the SDP look like in that 200OK? If something in there isn't kosher, that could be why CM ain't answering.

Look for capro stuff, cSIPDialog stuff and cUASIP stuff in CM's /var/log/ecs and you'd see if it logged some error there that could explain why it didn't answer.

Are you using SA8965? If so, is it enabled on that SIP trunk?

And, what patch load on CM?

And, why not go thru SM in between? CM isn't exactly meant to go direct to other stuff.

 

[montyzummer]

This is probably not issues with settings on the sig group if it stays active (it could be but unlikely) , as Kyle points out look in those locations for logs and specifically the SDP, also look at port ranges in the IP newtwork region , i have set up quite a few direct SIP trunks into a range of other systems and have not really ever had an issue , a more comprehensive trace would be better , can you post a full PCAP so it can be analyzed , as im sure we will be able to see what the issue is ... or atleast make an educated guess.

Again as kyle points out a session manager will also be a good way to go , do you have session manager in your environment ?


ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[SchuylerJ]

Hey Kyle,

Thanks for the response. I included the full SDP for the 200 ok, looks ok to me, nothing popping out.

I've tried through SM as well, same result. It's odd to me that this works with the IDENTICAL settings in an older version of CM (5.1) and with the new lab (CM R17.00, SM 7.0.1, SMGR 7.0) we get this problem. I don't see any errors in the /var/logs/ecs.

We aren't using SA8956 SIP Shuffling. Should I be?

Thanks again, it's much appreciated, this is driving me crazy.

 

[kyle555]

And I've been working an issue for a week or two about CM not answering 20OKs causing calls to drop. Can't get into it much, but if you got SIP stations or bridged appearances or something, speak up now!

 

[SchuylerJ]

Thanks guys,

I included 2 pcaps. One from the old system that's a good call, one from the new that doesn't work. Anything you see that's wonky? I can provide the CM trace as well if you'd like to see that side.

 

[SchuylerJ]

No SIP stations, using a soft phone (1XC). Tried a couple different versions and a hard phone, same results

 

[kyle555]

Avaya needs to turn on 8965 if you want it, and it's not recommended but sometimes required to interop nice with other things, but it ultimately introduces problems on other call flows. Don't use it unless you need it, basically.

Anyway, in packet 502, CM 5.2 sends an invite with SDP with RFC2833 DTMF as media type 127. Its asking for media to be sent to .72. It's max forwards is 71 which is funny cause RFC standard is 70 max!

It goes to some Dialogic SIP thing on .79, dialogic answers with SDP in the 180 ringing asking for media to be sent to .79
A 200OK goes to CM from Dialogic with SDP, CM acks, call is setup

I'll presume from that PCAP that of the 2 calls in it, it wasn't the one with g711A offered that was "busy here"

Anyway, I'd look at far end sip domain in the sig groups and authoritative domain in the network regions if it's impossible to look at a pcap from the busted 6.x.
Also, was 8965 ever on in your switch? found a fun bug where if it ever was, and you left that config on a trunk, that if you turn the special app off without disabling the config on the trunks, that it does something really weird and lots of unanswered 200OKs played in.

Let me see the full 200OK that CM never answered and just make darn sure your sig groups and domains are kosher. Or, just turn off shuffling on the sig group and the SDP will be all that much simpler pinning things to a gateway if that's possible.

 

[kyle555]

And, because in your jpg of the 6.x system you're using subdomains, I reiterate that you should check all that stuff in your sig groups and NRs. Maybe make the application on testdomain.com and build out a new NR/sig/trunk in testdomain.com and see if that played in at all.

 

[montyzummer]

One thing i forgot about the sig group , if it is turned on turn off "initial IP-IP Direct Media? " , but as Kyle points out your domain an sub domains could be playing a part , and yes lets have a full trace with forced DSP used and DSP turned off , with just the failed call scenario

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[SchuylerJ]

Hi Kyle,

you were right, mixup in the domain. I had to put the .79 in the far end domain to make it work (even though they are all on the same authoritative domain of mutare.com).

Weird. Thanks again for your help!!!!

 

[montyzummer]

Hang on unless im going mad you are using PCMA Mu-law on one invite and PCMA Alaw on the other , thats obviously on the codec sets , can you confirm that you have the protocols matching at both ends and on both kits.

ACSS (UC/SBCE/SM/SME)

Not that they mean a thing anymore , get a brain dump pass the test crash the system.

 

[kyle555]

glad to help!

*that's why you use SM - it can normalize different domains across different servers so you're not guessing about entering an IP address as your domain.

Rule of thumb: Avaya loves SIP domains. Don't use IPs!

 

[SchuylerJ]

Hi Kyle,

Just checking to see if you're still on here. Got the trunk up and functioning between CM and the Adjunct direct by using the IP address as the far end domain.

Now I'm trying to route this through SM to the adjunct and not having any success. Admittedly I'm not a SMGR pro.

I have a trunk between SM and CM where I am routing the call to when dialed.

In SM I have built the 3rd party adjunct as a sip entity (SIP trunk as type).

I built a dial pattern and routing policy and I'm hitting the third party box, but then all i'm getting is 200oks with no ack.

I think the issue is in the domain as it was for a CM straight connection, I had to use the IP address as the far end domain name. However in SM I can't use IP addresses as a SIP domain, only FQDN (which doesn't work in the signalling group in the direct trunk from CM)

Both traces are attached, CM to 3rd party (SAM) and SM to SAM.

here's my trunks: (CM to SM)
splay trunk-group 1 Page 1 of 21
TRUNK GROUP

Group Number: 1 Group Type: sip CDR Reports: y
Group Name: SMGR COR: 1 TN: 1 TAC: 100
Direction: two-way Outgoing Display? n
Dial Access? n Night Service:
Queue Length: 0
Service Type: public-ntwrk Auth Code? n
Member Assignment Method: auto
Signaling Group: 1
Number of Members: 20
Here's the CM to SAM:
display trunk-group 2 Page 1 of 21
TRUNK GROUP

Group Number: 2 Group Type: sip CDR Reports: y
Group Name: SAM from CM COR: 1 TN: 1 TAC: 102
Direction: two-way Outgoing Display? y
Dial Access? n Night Service:
Queue Length: 0
Service Type: public-ntwrk Auth Code? n
Member Assignment Method: auto
Signaling Group: 3
Number of Members: 5
Signalling groups: CM to SM
display signaling-group 1 Page 1 of 3
SIGNALING GROUP

Group Number: 1 Group Type: sip
IMS Enabled? n Transport Method: tcp
Q-SIP? n
IP Video? n Enforce SIPS URI for SRTP? y
Peer Detection Enabled? y Peer Server: SM
Prepend '+' to Outgoing Calling/Alerting/Diverting/Connected Public Numbers? y
Remove '+' from Incoming Called/Calling/Alerting/Diverting/Connected Numbers? n
Alert Incoming SIP Crisis Calls? n
Near-end Node Name: procr Far-end Node Name: SM
Near-end Listen Port: 5060 Far-end Listen Port: 5060
Far-end Network Region: 1

Far-end Domain: mutare.com
Bypass If IP Threshold Exceeded? n
Incoming Dialog Loopbacks: eliminate RFC 3389 Comfort Noise? n
DTMF over IP: rtp-payload Direct IP-IP Audio Connections? y
Session Establishment Timer(min): 3 IP Audio Hairpinning? n
Enable Layer 3 Test? y Initial IP-IP Direct Media? n
H.323 Station Outgoing Direct Media? n Alternate Route Timer(sec): 6

CM to SAM Sig group:
display signaling-group 3 Page 1 of 3
SIGNALING GROUP

Group Number: 3 Group Type: sip
IMS Enabled? n Transport Method: tcp
Q-SIP? n
IP Video? n Enforce SIPS URI for SRTP? n
Peer Detection Enabled? y Peer Server: Others
Prepend '+' to Outgoing Calling/Alerting/Diverting/Connected Public Numbers? n
Remove '+' from Incoming Called/Calling/Alerting/Diverting/Connected Numbers? y
Alert Incoming SIP Crisis Calls? n
Near-end Node Name: procr Far-end Node Name: SAM
Near-end Listen Port: 5060 Far-end Listen Port: 5060
Far-end Network Region: 1

Far-end Domain: 192.168.1.79
Bypass If IP Threshold Exceeded? n
Incoming Dialog Loopbacks: eliminate RFC 3389 Comfort Noise? n
DTMF over IP: rtp-payload Direct IP-IP Audio Connections? y
Session Establishment Timer(min): 3 IP Audio Hairpinning? n
Enable Layer 3 Test? y Initial IP-IP Direct Media? n
H.323 Station Outgoing Direct Media? n Alternate Route Timer(sec): 15

I also attached the SMGR config.

Any ideas? Thanks again.

 

[SchuylerJ]

One upload at a time it seems

 

[SchuylerJ]

SM to SAM trace

 

[kyle555]

Oy.

OK, so in SM you can have "adaptations" - you apply them to SIP entities. Check the SM admin guide and ctrl-f for odstd.

You can osrcd, odstd, iosrcd and iodstd - override source or destination domain and override incoming source and destination domain.

Basically, that means I can have the potato.com and tomato.com sip servers connected to SM and if I apply the adaptations correctly, make everything the tomato.com server wants to send to the potato.com server have SM overwrite the domains between them and have that be transparent to my servers.

I haven't tried it, I don't recommend it, but I don't see why you can't override domains to IPs in adaptations you build and apply to your entities like that Mutare box that just doesn't seem to want to play nice with regular SIP domains.

 

[SchuylerJ]

I'll give that a shot, thanks Kyle, I'll post my results.

 

[SchuylerJ]

OK,

So here's the update. I was able to change the header with an adaptation. I used the following parameters:
odstd=192.168.1.79 iodstd=192.168.1.79 fromto=true reduceRtHdrs=true osrcd=mutare.com

Now my trace looks (to me) identical to the WORKING trace from CM to SAM direct however it still just rings then 200ok until timeout at 30 seconds.

I do see the record route which goes from .79 (SAM server) to .215 (Security module of the SM) to 208 (SM) to 206 (CM) but the Ack doesn't seem to come back.

If you compare the attached trace with the prior one in the thread (CM to SAM) they look correct with the IP addresss in the to headers.

I'm baffled.

 

[kyle555]

I`m not seeing both legs before and after the adaptation, but I`d figure to Mutare you`d want to iosrcd and iodstd to domain.com and odstd and osrcd to IP. Ideally, you`d want SM to pitch to IP and receive on the domain.

It`s still only going to change the from/to headers - maybe not the via's or historys or the diversions or the PAIs like . Depending on what Mutare wants or is looking for, you might be a bit stuck.

But they do a lot with Avaya - I'm surprised there's no interop doc. Though, I've never seen a SIP trunk to Mutare - It's always been something like LDAP/IMAP/trusted server access to a voicemail system.


Anyway, in the 200 back from Mutare to SM, it's from "you@mutare.com" to 5999@192.168.1.79. I can't exactly see what SM pitched to CM (and a traceSM of the same flow would likely show both legs off the SM), but either you're not doing both adaptations just right, or that Dialogic SIP stack needs to speak to 1 thing and 1 thing only, or need some kind of tweak to play nicely with domains.

Maybe a little hack - and I got this to work on a CUCM once - is to point your Mutare/dialogic SIP think to the domain and use a DNS SRV record for SIP that resolves mutare.com to the IP of the SM100 to kind of trick it into using domains.