[Home]

Summary:ASTERISK-12785: Asterisk sending the wrong codec on re-invite.
Reporter:Brian West (bkw918)Labels:
Date Opened:2008-09-26 17:48:11Date Closed:2009-05-18 09:00:31
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) file.pcap
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.


****** ADDITIONAL INFORMATION ******

In RFC3264 - Section 8.3.2:

The corresponding media stream in the answer is formulated as
described in Section 6, and may result in a change in media formats
as well.  Similarly, as described in Section 6, as soon as it sends
its answer, the answerer MUST begin sending media using any formats
in the offer that were also present in the answer, and SHOULD use the
most preferred format in the offer that was also listed in the answer
(assuming the stream allows for sending), and MUST NOT send using any
formats that are not in the offer, even if they were present in a
previous SDP from the peer.  Similarly, when the offerer receives the
answer, it MUST begin sending media using any formats in the answer,
and SHOULD use the most preferred one (assuming the stream allows for
sending), and MUST NOT send using any formats that are not in the
answer, even if they were present in a previous SDP from the peer.

Comments:By: Brian West (bkw918) 2008-09-26 17:55:45

Attached is a call from a Polycom 650 to tf.voipmich.com via FreeSWITCH that exhibits this problem.  Its repeatable every single time when John has re-invites enabled.

/b


By: Olle Johansson (oej) 2008-09-27 12:52:57

Brian, as an old bug marshal you know that I want to see what's going on in the asterisk server- full debug output and the configuration for the peer and the channel codecs. Specifically, I want to see the evaulation of the incoming SDP - the stuff with joint capabilities and such. Thanks.

Propably should take karma off for an incomplete bug report, but I'll let it slip this time, young man :-)
By: Brian West (bkw918) 2008-09-27 20:06:38

I don't have access to the server in question.  From the pcap file its rather clear what is going on and where the problem is.  John Lodden would have to collect the output.  I don't run Asterisk so I can't collect the output.  ;)

/b
By: Matthew Nicholson (mnicholson) 2008-12-16 18:53:55.000-0600

I examined your trace and can confirm that the trace displays the behavior you describe.  I will take a look at this issue.
By: Matthew Nicholson (mnicholson) 2008-12-17 17:49:15.000-0600

I reviewed the code that is supposed to handle this and I didn't see any obvious problems.  Would it be possible to get sip debug and asterisk debug output of this issue so I can see some more of what asterisk is doing?  I will also try to reproduce this here using asterisk and openser.
By: Brian West (bkw918) 2009-01-14 16:43:38.000-0600

You would have to contact tf.voipmich.com for that info.  I don't use asterisk in our setup so I can't reproduce this.

/b
By: Leif Madsen (lmadsen) 2009-01-14 17:11:42.000-0600

Uhhhh... that should actually be the other way around should it not? Shouldn't they be the one providing the information?
By: Brian West (bkw918) 2009-01-15 17:57:40.000-0600

This is a legit bug.  I would be more than happy to work with John and anyone at Digium to collect any info because this is clearly a place where Asterisk is in the wrong.  You can't take my 200 OK with GSM in it ONLY and start sending me ulaw... it doesn't work like that.

/b
By: Leif Madsen (lmadsen) 2009-01-16 14:36:13.000-0600

I think that's all we're looking for. Matt requested some information in order to diagnose the problem, but I'm not going to send him off chasing after the debugging information.

Yes, there does appear to be an issue here, which is why we have not closed it, but I'm not going to try and wrangle debugging information out of someone.
By: Matthew Nicholson (mnicholson) 2009-02-05 11:23:53.000-0600

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.  I wonder how other B2BUAs handle cases like this.

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


By: Brian West (bkw918) 2009-03-06 23:12:35.000-0600

You're clearly misreading the SDP Offer Answer RFC... please reread the attached text.

/b
By: Matthew Nicholson (mnicholson) 2009-03-09 09:54:24

I understand what the RFC says.  I don't think you understand what is happening here.  This problem occurs because Asterisk assumes that during a re-invite, the media formats will not change from the original sdp offer.  In this case, this assumption is wrong, thus you receive the wrong codec.  I am not saying this is not a bug in Asterisk, I am saying your understanding of what you have observed is wrong.
By: Brian West (bkw918) 2009-03-20 16:52:50

NO you have said exactly what I said in a different way.  I fully understand what is going on...

"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. "

Is that not the same thing?
By: Matthew Nicholson (mnicholson) 2009-03-20 17:09:03

Well the audio is no longer coming from Asterisk.  The answer is basically ignored by asterisk, but asterisk is not sending the audio anymore.  Other than that, we are saying the same thing.

To fix this, the logic asterisk uses to perform re-invites needs to be changed.  My first thought was to only reinvite one leg at a time, but that still would not fix the problem.  Right now, I am thinking that asterisk should reinvite one leg of the call at a time, and then send additional reinvites if the media formats or other items in the answer differ from the last reinvite we sent to the other leg of the call.  This is somewhat complex, so I need to spend some time thinking about it some more to make sure all edge cases are covered before I move forward with an implementation.
By: Brian West (bkw918) 2009-04-01 18:57:59

Audio is coming from Asterisk.. This was a different box that the call was reinvited to ... so Asterisk A reinvites to Asterisk B... Asterisk B starts sending Ulaw but our 200 OK only has GSM in it...

/b
By: Matthew Nicholson (mnicholson) 2009-04-02 09:09:41

Yes, there are two asterisk boxes, so technically audio is still coming from asterisk.  But it is not the same asterisk box that generated the reinvite.  The problem is with the box that is doing the reinvite, not the one actually sending the audio.  That is an important detail.  The box sending the audio, is doing everything correctly, it is only sending the wrong codec because "Asterisk A" told it to.

There could be an audio codes gateway in place of "Asterisk B" and it would still be sending the wrong codec.  The problem is with the way the reinvite is done.
By: Matthew Nicholson (mnicholson) 2009-04-03 16:20:07

lmadsen,

I have confirmed that this is a bug in asterisk, but I am not going to pursue a fix in the immediate future as I have other things to work on.  Please assign this to someone else.
By: David Vossel (dvossel) 2009-04-14 15:34:45

Hey bkw918, I'm trying to bring this issue to completion.  I've taken a good look at it and agree that its a problem, but I'm really blind to exactly what is causing it.  So far we are guessing about what happens behind Asterisk before the native bridge takes place, so we really don't know why that end point is sending ULAW rather than GSM.  At this point I really need access to a packet capture of the Asterisk box as well as the sip.conf information for the peers involved.  You mentioned that you would be willing to to work with John Lodden to try and retrieve some of that information.  Is this still possible?
By: David Vossel (dvossel) 2009-05-11 09:49:26

If we are unable to receive feedback soon, this issue will be closed due to inactivity.
By: David Vossel (dvossel) 2009-05-14 10:44:58

I'm closing this issue due to inactivity.  In order to move forward on this more information must be provided.  If this information becomes available, please reopen.
By: Brian West (bkw918) 2009-05-14 10:48:50

Plenty of information has been provided and I have offered my time to place test calls but nobody has setup a box to reproduce the issue and I'm not going to do that but this is still a bug none the less.

All you need are two asterisk boxes with can reinvite turned on.

FS -> AST1 -> AST2, When the reinvite takes place FS will 200 OK that GSM ONLY.  To which Asterisk will promptly start sending ulaw even thou our answer didn't contain anything to do with ulaw.  

/b

By: David Vossel (dvossel) 2009-05-14 12:49:25

bkw918: "I would be more than happy to work with John and anyone at Digium to collect any info because this is clearly a place where Asterisk is in the wrong."

dvossel: "You mentioned that you would be willing to to work with John Lodden to try and retrieve some of that information. Is this still possible?"

Okay, I'm just trying to get this straight, you won't make an effort to retrieve any of the information I asked for a month ago?  I asked for it for a reason, without it I'm just guessing as to why this occurs.  I have a pretty good idea though.


By: Brian West (bkw918) 2009-05-14 23:09:01

The information is already in the pcap file attached to this bug its the exact info I could collect if I worked with John.  All you have to do is get two Asterisk boxes ready for me to send a call to from FreeSWITCH to reproduce the problem.  The issue has been described more than once in this bug report.

The issue is clear that asterisk doesn't consider the reinvite a new SOA and uses the codecs from the original invite on the re-invite when our answer to the reinvite only contains GSM then asterisk promptly starts sending ulaw when we said in our answer we only want GSM.  It should be listening to the answer we give them and not taking the codecs from the original invite into account.

RFC3264 - Section 8.3.2

/b
By: Brian West (bkw918) 2009-05-14 23:10:11

Just close the issue out its clear from the notes that nobody cares!

/b
By: Joshua C. Colp (jcolp) 2009-05-15 07:18:35

bkw918: I disagree on that last note. We *do* care and this issue has been kept open for awhile to try to bring it to a resolution. The entire problem though was that we did not know how the Asterisk machines were actually configured, so in order to reproduce this I guess we'll just have to guess on everything and hope for the best.

After re-reading the notes I agree with Matt's analysis and will work with dvossel on this. I also think we will be able to recreate this using a sipp scenario file.
By: Digium Subversion (svnbot) 2009-05-18 08:53:40

Repository: asterisk
Revision: 195095

U   branches/1.4/channels/chan_sip.c
U   branches/1.4/main/rtp.c

------------------------------------------------------------------------
r195095 | file | 2009-05-18 08:53:39 -0500 (Mon, 18 May 2009) | 5 lines

Fix a bug where the codecs of the called party leg were not properly sent back to the caller call leg when reinvited.

(closes issue ASTERISK-12785)
Reported by: bkw918

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195095
By: Digium Subversion (svnbot) 2009-05-18 08:56:16

Repository: asterisk
Revision: 195096

_U  trunk/
U   trunk/main/rtp_engine.c

------------------------------------------------------------------------
r195096 | file | 2009-05-18 08:56:16 -0500 (Mon, 18 May 2009) | 12 lines

Merged revisions 195095 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r195095 | file | 2009-05-18 10:53:39 -0300 (Mon, 18 May 2009) | 5 lines
 
 Fix a bug where the codecs of the called party leg were not properly sent back to the caller call leg when reinvited.
 
 (closes issue ASTERISK-12785)
 Reported by: bkw918
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195096
By: Digium Subversion (svnbot) 2009-05-18 08:57:33

Repository: asterisk
Revision: 195097

_U  branches/1.6.0/
U   branches/1.6.0/main/rtp.c

------------------------------------------------------------------------
r195097 | file | 2009-05-18 08:57:33 -0500 (Mon, 18 May 2009) | 19 lines

Merged revisions 195096 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r195096 | file | 2009-05-18 10:56:16 -0300 (Mon, 18 May 2009) | 12 lines
 
 Merged revisions 195095 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r195095 | file | 2009-05-18 10:53:39 -0300 (Mon, 18 May 2009) | 5 lines
   
   Fix a bug where the codecs of the called party leg were not properly sent back to the caller call leg when reinvited.
   
   (closes issue ASTERISK-12785)
   Reported by: bkw918
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195097
By: Digium Subversion (svnbot) 2009-05-18 08:58:31

Repository: asterisk
Revision: 195098

_U  branches/1.6.1/
U   branches/1.6.1/main/rtp.c

------------------------------------------------------------------------
r195098 | file | 2009-05-18 08:58:31 -0500 (Mon, 18 May 2009) | 19 lines

Merged revisions 195096 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r195096 | file | 2009-05-18 10:56:16 -0300 (Mon, 18 May 2009) | 12 lines
 
 Merged revisions 195095 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r195095 | file | 2009-05-18 10:53:39 -0300 (Mon, 18 May 2009) | 5 lines
   
   Fix a bug where the codecs of the called party leg were not properly sent back to the caller call leg when reinvited.
   
   (closes issue ASTERISK-12785)
   Reported by: bkw918
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195098
By: Digium Subversion (svnbot) 2009-05-18 09:00:30

Repository: asterisk
Revision: 195099

_U  branches/1.6.2/
U   branches/1.6.2/main/rtp.c

------------------------------------------------------------------------
r195099 | file | 2009-05-18 09:00:30 -0500 (Mon, 18 May 2009) | 19 lines

Merged revisions 195096 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
 r195096 | file | 2009-05-18 10:56:16 -0300 (Mon, 18 May 2009) | 12 lines
 
 Merged revisions 195095 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r195095 | file | 2009-05-18 10:53:39 -0300 (Mon, 18 May 2009) | 5 lines
   
   Fix a bug where the codecs of the called party leg were not properly sent back to the caller call leg when reinvited.
   
   (closes issue ASTERISK-12785)
   Reported by: bkw918
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195099