[asterisk-bugs] [Asterisk 0013569]: Asterisk sending the wrong codec on re-invite.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13569 
====================================================================== 
Reported By:                bkw918
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   13569
Category:                   Channels/chan_sip/CodecHandling
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.0-rc6 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-09-26 17:48 CDT
Last Modified:              2009-02-05 11:23 CST
====================================================================== 
Summary:                    Asterisk sending the wrong codec on re-invite.
Description: 
FreeSWITCH sends invite out to tf.voipmich.com with PCMU, PCMA, GSM.  The
call is answered and setup using GSM since its listed first in the Answer
we receive from Asterisk.  A re-invite promptly follows offering
GSM,PCMU,PCMA to which we 200 OK with ONLY GSM in the SDP in our 200 OK.  

Promptly there after Asterisk starts sending PCMU packets.  The re-invite
is considered a new Session Offer Answer and Asterisk ignores the Answer
and sends a media format not in the new Answer.  

Asterisk PBX SVN-branch-1.6.0-r140976-/trunk is what I can see in the SDP
from John's equipment.  He has disabled re-invites pending a fix for this.

====================================================================== 

---------------------------------------------------------------------- 
 (0099506) mnicholson (administrator) - 2009-02-05 11:23
 http://bugs.digium.com/view.php?id=13569#c99506 
---------------------------------------------------------------------- 
bkw,

Ok, I tried to reproduce this today and I was unable to do so.  I
investigated it a little further, and your analysis of what is happening is
incorrect.  What appears to be happening from the pcap you uploaded is:

1. INVITE from your polycom to freeswitch
2. acting as a b2bua, freeswitch sends INVITE to voipmich (apparently
running asterisk)
3. presumably voipmich sends an INVITE to some where else (69.41.0.21,
which we will call host b)
4. and OK is returned from voipmich to freeswitch
5. g.722 media is flowing between polycom and freeswitch, GSM between
freeswitch and asterisk (69.41.0.51).

Now a reinvite occurs.

6. voipmich/asterisk sends an INVITE to freeswitch, attempting to bridge
media directly with 69.41.0.21 (host b), as you observed, the SDP contains
GSM, PCMU, and PCMA media offers
7. freeswitch responds with only GSM

This is where your analysis goes wrong.

At this point media is flowing from host b to freeswitch as g.711 and from
freeswitch to voipmich as GSM.  What should be happening here is freeswitch
should be sending audio (as GSM) to host b NOT voipmich.  Also note that
host b is sending the incorrect codec NOT voipmich.  What is probably
happening here is that host b also received a reinvite from
asterisk/voipmich with GSM, PCMU, and PCMA and started sending PCMU to
freeswitch.

So the actual problem is in the way reinvite operates, not in the way
asterisk handles sdp information.  The response to reinvites from asterisk
is basically ignored.  This is only a problem in cases like this where the
response to the reinvite from one host is different from what was sent to
the other host.  One way to fix this would be to rework how reinvite works
and have cases like this trigger another reinvite.  Another alternative is
to only reinvite one host at a time and wait for the response, then update
the media offers for the reinvite to the second host.

To work around this,  you could have freeswitch only send GSM from the
beginning.  I may be wrong on that. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-05 11:23 mnicholson     Note Added: 0099506                          
======================================================================