SIP / Gamma odd issues

[BristolD]

Having to re post as my traces where too long, try again

I have a customer with some odd issues that started around Christmas, Was working fine before and no changes where made to the IPO or SBCE around this time.

Some issues are
when our customer call another company, the call is answered ok but if the other company then transfers the call internally the call cuts off with a message on our customer phone "Incompatible"

If they call a company with an AA and choose an option the call cuts off with the message "Incompatible on the display

If they call a company and are put on hold they hear their own MOH not the far ends.

This is a IPO 9.0.5 SBCE using Gamma

On the attached trace the two test calls where to 01458831742 and 01925286520

Any help would be appreciated

Thanks

 

[rabb2004]

Did you ever resolve this problem, I’ve got an IP Office with Gamma lines having a similar problem?

If they call a company and are put on hold they hear their own MOH not the far ends.

 

[BristolD]

Hi rabb2004

This is currently with Avaya tier 2, I will post any resolutions I get.

 

[IPGuru]

If they call a company and are put on hold they hear their own MOH not the far ends.

Know issue (I am surprised Ava didn't pot it & even more surprised that Avaya have not already recommended upgrade to latest maint. release as that i ALWAYS their 1st response)
documented in the V9.0.12 release notes.

if you are going to maintain these systems professionally it is important check for updates & FULLY READ the release notes



Do things on the cheap & it will cost you dear

 

[BristolD]

Hi IPGuru

An upgrade was done on Wednesday to V 10.1 and this has not resolved the issues.

 

[IPGuru]

OK
now is the time for Tier 2 (& probably Teir 3) to get involved again

this could easily be yet another example of Avaya's Bug recycling process (they seem to develop release x from the code base of release x-2 & often forget to test for issues found in release x-1)


Do things on the cheap & it will cost you dear

 

[BristolD]

Thank you IPGuru

 

[VoIP Numpty]

I heard about an MoH 'issue' on a SIP trunk from a colleague, don't know whose they were. Apparently the far end PBX is sending a reINVITE with "inactive" in the SDP to indicate that they are not sending any RTP (and obviously no MoH), so I guess the developers made the IP Office provide local MoH instead of giving just silence, sounds like a good thing to me.

Have you looked at the SIP tracing to see what's happening when the caller is put on hold? (yes there's a trace but there's too much in there for me to want to go wading through it)
Not heard of the Incompatible issue though

 

[BristolD]

Hi Voip Numpty

The more pressing issue is the calls dropping, here is what Avaya have come back with so far. (sorry it wont allow me to put the screenshots of the wireshark)



We have looked at the traces and have made some initial observations which may be key.


sip.Call-ID == "c67154e56ffed995ac4a667f07a9e43b"
sip.Call-ID == "bf17b66d1cab907aa5d9663cf0f50233"




If we look at SIP Call ID c67154e56ffed995ac4a667f07a9e43b in the sysmon trace we can see that:-

15:03:09 338912995mS Sip: c0a80a01000051ef 20.20975.0 5129 SIPTrunk Endpoint(f16bc130) ProcessSDPAck, ACK doesn't have SDP
15:03:12 338915416mS Sip: sip_indicateTimeOut Timer 9
15:03:12 338915995mS Sip: c0a80a01000051ef 20.20975.0 5129 SIPTrunk Endpoint(f16bc130) SDP Failed Timeout ....

Then the call is cleared down

15:03:12 338915995mS CMLineRx: v=0
CMReleaseComp
Line: type=SIPLine 20 Call: lid=20 id=20975 in=0
Called[] Type=Default (100) Reason=CMDRdirect Calling[01225775666] Type=Default Plan=Unknown
IE CMIERespondingPartyName (228)(Type=CMNameDefault) name=WITHHELD
IE CMIERespondingPartyNumber (230)(P:100 S:100 T:0 N:100 R:4) number=01458831742
IE CMIEDeviceDetail (231) c0a80a01000051ef LOCALE=eng HW=15 VER=10 class=CMDeviceSIPTrunk type=0 number=20 channel=1 features=0x0 rx_gain=32 tx_gain=32
ep_callid=20975 ipaddr=192.168.10.1 apps=0 loc=999 em_a_loc=999 em_d_loc=0 features2=0x0 is_spcall=1 ignores_dtmf=0 avgsid=
Cause=88, Incompatible destination


Analysis of the wireshark trace shows that the SBCE is not transmitting the SDP in the flow of messages after the AA Invite.

Take a look at this portion of the trace, just prior to the BYE.




Notice the 200 OK with SDP from IPO to SBCE at timestamp 14.54.12.955779

The 200 from the SBC to the AA only transmits the 200 and not the SDP.

Further, the 3rd party AA sends ACK with SDP ro SBCE but the ACK from SBC to IPO only contains the ACK and there is no SDP, hence the SDP timeout and hence the call clearing down.


this would seem to be the root cause of the issue but I would suggest to take this up with SBC team as to why the SDP is not transmitted in the 200 OK and in the ACK.

 

[BristolD]

Just an update

The incompatible issue was resolved with an upgrade to 10.1.0.1 with a hotfix patch supplied by Avaya.

I am still working on the MOH issue.