My company is trying to interoperate with the asterisk. We have a back-to-back SIP user agent (B2BUA) that communicates with the asterisk (*):
gateway <–> Our B2BUA <–> * <–> phone
During a call the initial negotiated codec is G.729 with RTP directly between the gateway and the phone (i.e. * is not in the media path, nor is our B2BUA). Our B2BUA sends a (re)INVITE to renegotiate the codec to G.711. The * responds with 200 OK, with an SDP allowing G.711 and the RTP target still pointed to the phone, then sends a (re)INVITE to the phone with an SDP indicating G.729 and RTP target of the gateway. Obviously, this results in the two enpoints talking a different language, thus no intelligible audio is transferred.
We have tried several versions: 1.2.0, 1.2.24, 1.4.0, 1.4.13. Each had a different behavior, but the result was the same: no audio after the (re)INVITEs. The above scenario occurred with version 1.4.13.
Yes, but that is because there is nothing to renegotiate in the middle of the call. If we start out G.711 and stay on G.711, then everything seems to work fine.
I can see from packet traces that * is not doing the correct thing in the case of switching codecs.
As an aside, our B2BUA is sending a reINVITE with a NULL SDP (c=0.0.0.0) with G.711 codec (m=0) prior to sending the reINVITE with a non-null SDP (valid RTP target and G.711 codec).
That’s a fair call. Reason I asked the one-codec-throughout-call was because a prominent voip provider in australia mysteriously started trying to negotiate codecs that were not listed in the SDP on a re-invite.
I’d go down the road of submitting a bug seeing as asterisk isn’t doing what it’s supposed to.
It’s a bit of a pain-in-the-axx, but you seem to have everything needed to give them a good look at fixing it. (debug info etc.)
The RTP traffic starts out with
gateway(g729) <----> phone (g729)
and, after reINVITES, ends up with
gateway(g711/ulaw) <----> phone (g729)
What we want after the reINVITEs is
gateway(g711/ulaw) <----> phone (g711/ulaw)
Signalling is always
gateway <–> B2BUA <–> * <–> phone
Version 1.4.13 has an issue where it does not offer all codecs to the phone. In my sip.conf, I have
disallow=all
allow=g729
allow=ulaw
but the * only offers g729 to the phone during the INVITE. This results in a “488 Not acceptable here” when our B2BUA attempts to reINVITE to g711 (ulaw). When I force the phone to return both g729 and g711 on the 200 OK message, I get around the 488 error, but the * still does not renegotiate the codec properly.
Tests with version 1.2.24 show the * staying in the media path (not desirable or necessary) even with nat=no and canreinvite=yes.
