I have observed what I think is a subtle bug in 10.9.0, 11.8.1 and 12.1.1 for medialess INVITE(s) and am interested to hear whether anyone else agrees.
By medialess, I mean empty INVITE, destination offer sdp in 200OK and origin answer sdp in ACK. RFC3261 section 13.2.1 covers this offer/answer variation.
My scenario is that the ACK contains an a=inactive sdp that is mirror of the sdp in the 200OK offer from Asterisk. This is immediately followed by a re-INVITE to Asterisk with a useful a=sendrecv sdp. However, asterisk responds with valid, but a=inactive sdp in the consequential 200OK.
My SIP topology is an MSML server <–> NodeJSAppSvr <–> Asterisk <–> Bria. The ultimate destination being the Bria, which on answer hears a mix of Asterisk MOH and MSML server audio, mixed by Asterisk.
A wireshark of this is here: http://netconfigs.com/misc/files/5344441d-110d-12b6-9881-20cf30f2fed7.pcapng
The sip-dialog is question is ‘Call-ID: 5344441d-110d-12b6-9881-20cf30f2fed7’
The bria-leg is ‘Call-ID: 782b0e4025879cd67de26bde39c2d1b5@192.168.11.251:5060’
The msml-leg is ‘Call-ID: 5344441e-89d7-1c1e-9881-20cf30f2fed7’
This was encountered because the MSML server does not currently handle medialess INVITE(s) which would have provided sdp for the INVITE to asterisk.
These are called “late offer”.
There is a bug in 1.6.1.0, which may not have been fixed in later versions, whereby Asterisk offers its current negotiated state in a late offer, when it should offer its desired state.
See the big patch in issues.asterisk.org/jira/i#brow … RISK-16583 for details. Note, because we did significant other forking, I failed to track this one through, so I’m not sure what happened in the end. Please note I can’t provide you with detailed support.
I’ve had a cursory look at the big patch pt1, and the around chan_sip.c:25503 of 11.8.1 the fix looks absent to the untrained eye.
Pt2 is somewhat bigger and more difficult for me to assess.
Is this a dead duck, or will someone pick it up in due course ?
pjsip is likely to have started over from first principles.
This is NOT an Asterisk bug, it is mine. 
The re-INVITE carried the same o.version as sent in the 1st ACK
Sorry for any wasted time.
[code]INVITE sip:hMartin@asterisk SIP/2.0
User-Agent: Node x64 v0.10.26
Content-Length: 0
SIP/2.0 200 OK
Server: Asterisk PBX 11.8.1
o=root 234523880 234523880 IN IP4 192.168.11.251
ACK sip:hMartin@192.168.11.251:5060 SIP/2.0
User-Agent: Node x64 v0.10.26
o=node 1396982814 1396982814 IN IP4 192.168.11.252
INVITE sip:hMartin@192.168.11.251:5060 SIP/2.0
User-Agent: Node x64 v0.10.26
o=node 1396982814 1396982814 IN IP4 192.168.11.252
SIP/2.0 200 OK
Server: Asterisk PBX 11.8.1
o=root 234523880 234523880 IN IP4 192.168.11.251
ACK sip:hMartin@192.168.11.251:5060 SIP/2.0
User-Agent: Node x64 v0.10.26
Content-Length: 0[/code]