I would like to analyze the capture file and comment the most important steps. Lets go.
I see two sessions:
| A: 10.200.0.17->10.128.3.1 | B: 10.128.3.1->10.200.0.253 |
|---|
-> INVITE (with SDP, aLaw, media 10.200.0.17, sendrecv) <-180 RINGING (with SDP, aLaw, media 10.128.3.1, sendrecv) | -> INVITE (with SDP, aLaw, media 10.200.0.17, sendrecv) <- RINGING (no SDP) |
The session A is now in phase "call setup" with preliminary audio carrying call setup tones, media 10.200.0.17,10.128.3.1 aLaw, bidirectional (sendrecv).
The session B is now in phase "call setup", no preliminary audio, call progress announced by SIP message itself
| A: 10.200.0.17->10.128.3.1 | B: 10.128.3.1->10.200.0.253 |
|---|
<- OK (with SDP, aLaw,media 10.128.3.4, sendrecv) <-ACK | <- OK (with SDP, aLaw,media 10.200.0.253, sendrecv) -> ACK |
The session A is now in phase "call connected" with audio media 10.200.0.17,10.128.3.4 aLaw, bidirectional (sendrecv).
The session B is now in phase "call connected" with audio media 10.200.0.17,10.200.0.253 aLaw, bidirectional (sendrecv).
Two RTP streams can be seen within capture file
1: starting on packet 125&126 (Seq 4911) 10.200.0.17->10.128.3.4->10.200.0.253
2: starting on packet 129&130 (Seq 210) 10.200.0.253->10.128.3.4->10.200.0.17
CNG is passed trough them and has been detected by terminating device. So ReINVITE:
| A: 10.200.0.17->10.128.3.1 | B: 10.128.3.1->10.200.0.253 |
|---|
<- INVITE (with SDP, T.38,media 10.128.3.4) -> 488 Not acceptable here | <- INVITE (with SDP, T.38, media 10.200.0.253) -> OK (with SDP, T.38. media 10.128.3.4) |
So T.38 has been successfully (re-)negotiated on session B as sip proxy has approved the T.38. Session A remain in former state (e.g. aLaw audio) as originating device rejected transition to T.38.
Note that media proxy receive T.38 packets from 10.200.0.253 a resends them as-is to 10.200.0.17 despite there is no T.38 negotiated here. Also, aLaw packets received from 10.200.0.17 are resend as-is to 10.200.0.253 (they are interpreted as T.38 packets).
It is somewhat unfortunate behavior. Media proxy should recode media of the protocol on left side is not the same as the protocol on right side. SIP proxy should not approve protocol change unless it know the media proxy can handle them. On the ideal world, the SIP proxy should not OK T.38/reINVITE to 10.20.0.253 unless it received OK from 10.200.0.17. As originator is not willing to speak T.38 and media proxy can't translate aLaw<->T.38 the terminating reINVITE has to be rejected.
Well, we are not living in ideal word and reINVITE request has been approved. Now the SIP proxy know the media proxy can't handle the current configuration, so it start attempt to revert both session back to aLaw (despite the A session is aLaw already):
| A: 10.200.0.17->10.128.3.1 | B: 10.128.3.1->10.200.0.253 |
|---|
<- INVITE (with SDP, aLaw, media 10.128.3.4) -> OK (with SDP, aLaw. media 10.200.0.17) | -> INVITE (with SDP, aLaw, media 10.128.3.4) <- OK (with SDP, aLaw. media 10.200.0.253) |
Both sessions should be in aLaw mode now. Unfortunately, despite 10.200.0.253 ACKed the transition to aLaw it continue to speak T.38.
Conclusion:
It seems you hit firmware bug. SPA112 should either:
A: reject reINVITE from T.38 to aLaw if it is unable to do it correctly
or
B: do it correctly
By the way, in the "A" case, the SIP proxy can do nothing but terminate the both legs of call. Premature OK to aLaw->T.38 transition (as I described above) make it incompatible with devices that are unable to revert from T.38 back to raw audio.
Whats now ? You can turn in level 3 syslog and debug (Voice->System tab) and catch them. It may reveal more about the issue. But I'm not so sure it can reveal something that allow us to solve the issue. But you need the log if you decide to report the bug to Cisco SMB TAC.
You can report firmware bug to SMB TAC even in the case you have no support agreement.
Despite you have support contract or not, don't put so much hope the Cisco will help you. And zero chance it will solve the problem in reasonable time frame.
