Integration Issue SIP trunk settings?

[JJacobs313]

Using Avaya CM 6.3 with SM. and integration with separate company. There was no white sheet, it was just "set sip settings to default". Which we brought on a technician to program the integration. What we are seeing is when there is a call, everything works fine, but when a supervised transfer takes place (transferring that user into a conference line for example), the audio drops, then the call will drop around 30 seconds later. We are not seeing anything in the trunk that would be causing this.

Vendor is stating It appears any bridged (conference) call / supervised call that Avaya joins, fails due to a re-invite without SDP from the Avaya PBX. They are curious as to why Avaya is sending this second invite. The hired tech wasn't sure why we would be sending a second invite to them.

They also said this:
1. The immediate Re-INVITE without SDP from Avaya as soon as a call is successfully established. This message by itself does not cause the call to fail, although it may contribute or relate to the next error.
2. Revation LinkLive sends Re-INVITE with SDP and Avaya responds with “500 Internal Error” . This re-INVITE/500 response cause the call to fail.


One setting that the hired tech changed was Telephone Event Payload Type: 101, because he was seeing 101 come to us in the invite. But it made no difference. We are also seeing 482 loop detected, after turning loop detection off in the SM SIP entity. 415 unsupported media type, although we confirmed codecs.

Just wondering if there is anything in the trunk here that someone might know to change, since even the hired tech is stumped. Just a lot of pointing fingers at this point.

Group Number: 960 Group Type: sip CDR Reports: y
Group Name: CM to Revation COR: 1 TN: 1 TAC: 861
Direction: two-way Outgoing Display? n
Dial Access? n Night Service:
Queue Length: 0
Service Type: tie Auth Code? n
Member Assignment Method: auto
Signaling Group: 960
Number of Members: 96
Group Type: sip
TRUNK PARAMETERS
Unicode Name: auto
Redirect On OPTIM Failure: 5000
SCCAN? n Digital Loss Group: 18
Preferred Minimum Session Refresh Interval(sec): 3600
Disconnect Supervision - In? y Out? y
XOIP Treatment: auto Delay Call Setup When Accessed Via IGAR? n
TRUNK FEATURES
ACA Assignment? n Measured: none
Maintenance Tests? y
Numbering Format: public
UUI Treatment: service-provider
Replace Restricted Numbers? n
Replace Unavailable Numbers? n
Modify Tandem Calling Number: no
Show ANSWERED BY on Display? y
PROTOCOL VARIATIONS

Mark Users as Phone? n
Prepend '+' to Calling Number? n
Send Transferring Party Information? n
Network Call Redirection? n
Send Diversion Header? n
Support Request History? y
Telephone Event Payload Type: 101


Convert 180 to 183 for Early Media? n
Always Use re-INVITE for Display Updates? n
Identity for Calling Party Display: P-Asserted-Identity
Block Sending Calling Party Location in INVITE? n
Enable Q-SIP? n

SIGNALING GROUP

Group Number: 960 Group Type: sip
IMS Enabled? n Transport Method: tls
Q-SIP? n
Enforce SIPS URI for SRTP? y
Peer Detection Enabled? y Peer Server: SM



Near-end Node Name: procr Far-end Node Name: slh-xx100
Near-end Listen Port: 5061 Far-end Listen Port: 5061
Far-end Network Region: 1

Far-end Domain: rev.xxx.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
LIMIT SIGNALING GROUP USAGE

Enable on the main Processor(s)? y

Enable on Survivable Processors (ESS and LSP): all

"I am learning all the time. The tombstone will be my diploma." - Eartha Kitt

 

[kyle555]

You need SA8965 - Shuffling with SDP. It makes CM send reinvites always with SDP.

You need Avaya to turn that on for you - so, good luck with that.

You're sending a reinvite without SDP because you're soliciting the media capabilities of the far end. There's nothing wrong with that. If the far end system wants to use the same SDP, then it should send the same SDP as it did the first time.

I would refer them to RFC3261 section 14.1

https://datatracker.ietf.org/doc/html/rfc3261#section-14.1

[indent][/indent]Of course, a UAC MAY
   send a re-INVITE with no session description, in which case the first
   reliable non-failure response to the re-INVITE will contain the offer
   (in this specification, that is a 2xx response).

What they're doing doesn't make sense - if I send you a reinvite, how can you reply to me with a reinvite? We need to finish the transaction of my reinvite before starting another.

Older SIP stacks are bad for that. The Avaya SBC has a feature called 'reinvite handling' to mitigate that. So, if you had a SBC facing this LinkLive thing, you could add a feature to that SIP trunk that would take the CM reinvite without SDP and the SBC would block it from getting to LinkLive and reply to CM with a 200OK that had LinkLive's original SDP. That's the "right" way of doing it. Otherwise, you'll need to kick and scream to get someone with init permissions to turn on SA8965. That will open up a new option I think on page 4 of the trunk group form to do exactly what you're asking.

Beware - it breaks transfer scenarios if the other end is Avaya CM, so if you have more than 1 system on the other end of that sig group to SM, you'd be wise to peel that out to have different sig/trunk groups to SM for different applications. To say, if you used that sig/trunk for PSTN calls and/or voicemail, you wouldn't want to mess with those call flows by enabling this particular feature on a SM trunk those applications use.

Page 71:

https://downloads.avaya.com/css/P8/documents/101063920

 

[JJacobs313]

Thank you so much! Yeah this is all internal, so we weren't using an SBC. The other end is not Avaya, so that sounds good. This sig group is only used for this.

Def going to try to get this and go from there.



"I am learning all the time. The tombstone will be my diploma." - Eartha Kitt

 

[kyle555]

you should still use a SBC if you need to reconcile otherwise incompatible SIP systems - which is what you got.

But, unless you're cozy with Avaya or plan on upgrading or whatever, asking for that on a end of life system will likely get you told to take a hike at least the first time.

Also, you can maybe try turning off direct IP shuffling options on the sig group.

If you can't shuffle, then you're technically not shuffling with SDP. That would be something that could work around the issue at the cost of burning a DSP per call

 

[JJacobs313]

We are in a slow migration to CM 8, and our SBC is quite old as well. We did turn off the direct IP shuffling, but it made no difference.

"I am learning all the time. The tombstone will be my diploma." - Eartha Kitt