[Home]

Summary:ASTERISK-03627: Codec mismatch problem
Reporter:mihai (mihai)Labels:
Date Opened:2005-03-03 17:19:32.000-0600Date Closed:2011-06-07 14:10:11
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) codec_mismatch.cap
( 1) codec_mismatch.txt
Description:I'm running 1.0.3 but this problem appears in CVS HEAD as well. I have two devices (Innomedia and Sipura IP phones) set up with ulaw preferred and g729 allowed. Asterisk is set up with g729 preferred and ulaw allowed. The first device calls, Asterisk passes the call along to the second device with g729/ulaw as allowed codecs. The second device replies 200 OK with ulaw. At this point Asterisk dumps the call due to codec mismatch (I don't have a g729 translator)



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

I'm attaching an Asterisk SIP debug trace. The caller is 66.33.140.152, the callee is 66.33.140.129 and Asterisk is 66.33.140.4.

I also have an ethereal trace, but it seems I can only attach one file...
Comments:By: mihai (mihai) 2005-03-03 17:22:59.000-0600

I figured out how to attach a second file, so here's the ethereal trace.

Mihai
By: Kevin P. Fleming (kpfleming) 2005-03-03 17:26:55.000-0600

This is tough to fix... Asterisk has told the second peer that it really wants to use G.729, because that is what the incoming call is, and the second peer allows it.

The second peer is ignoring the preference, and requesting that the call be completed using ulaw. Since you can't transcode, that won't work.
By: Kevin P. Fleming (kpfleming) 2005-03-03 17:29:18.000-0600

Also, this is not a major bug, please read the bug posting guidelines.
By: mihai (mihai) 2005-03-03 17:42:06.000-0600

According to the SDP that Asterisk sends to the second peer, g729 and ulaw are allowed codecs. Please look at frame ASTERISK-14 in the ethereal capture. The second peer just picks the second codec in the list. I believe that this problem is a violation of SIP/SDP protocol... doesn't that qualify as major?
Please correct me if I'm wrong...

Thanks
By: mihai (mihai) 2005-03-03 17:44:06.000-0600

Also, at the time Asterisk sends its INVITE to the second peer, it does not yet know what codecs the second peer supports...
By: Mark Spencer (markster) 2005-03-03 17:44:46.000-0600

But Asterisk isn't the one choosing, obviously -- the end device is.
By: Kevin P. Fleming (kpfleming) 2005-03-03 17:46:33.000-0600

No, according to the SIP RFC, when an INVITE comes in, if the first codec listed is supported by the receiver, it should accept that INVITE using that codec. Otherwise, the second takes priority, etc.

This can be affected by local preferences, but every endpoint implements it differently. In the case of a SIP phone/softphone, it's not common for the phone to select a different codec than Asterisk asked for, if it's supported.

You have told Asterisk that the second peer supports both ulaw and G.729, so that's why it offers both. It prefers G.729 though, to avoid transcoding, but the second peer ignores that.

(As far as whether this is major or not, please read the guidelines. This problem does not keep Asterisk from working, and it can be worked around with the proper configuration, even if inconvenient).

edited on: 03-03-05 17:48
By: mihai (mihai) 2005-03-03 18:23:40.000-0600

I think that was the thinking for RFC2543. In RFC3261/2327/3264 (see section 10 of 3264) the thinking is to use the offer/answer model for the codec negotiation.  It seems as if even though the first codec is considered the preferred codec, subsequent codecs are allowed in the answer.  Since Asterisk is a B2BUA in this case, it should broker the call based on the preferred codec in the 200 OK that client 2 (call leg2 - packet 18) returns to asterisk.

I just wanted to bring it to your attention.  If you'd like to downgrade it to minor, I have no issue with that - I was just looking for a quick fix (or some pointers to do it myself).  Thanks.
By: Kevin P. Fleming (kpfleming) 2005-03-03 18:32:19.000-0600

What does "broker the call" mean? Do you expect Asterisk to renegotiate the call leg from the first peer based on what the second peer accepts? That could be a never-ending negotiation, because the peers are not talking directly to each other.
By: mihai (mihai) 2005-03-04 09:22:46.000-0600

The first leg of the call has not yet finished negotiating by the time the problem occurs. Ideally, this is what should happen:
- Device 1 sends its INVITE with the list of supported codecs
- Asterisk takes a subset of the codec list, according to its own codec allow list and sends it to the second device
- Device 2 picks a codec from the list that Asterisk offers and returns the 200 OK
- Asterisk sends a 200 OK to the first device, with the codec received from the second device

There is no need to renegotiate the first leg of the call, since the initiating device receives its 200 OK after both Asterisk and the second device agree on a codec.
By: Kevin P. Fleming (kpfleming) 2005-03-04 09:45:43.000-0600

But that is not necessarily true. The first leg of the call may already have been answered, listened to some voice prompts, etc. before the second call was ever placed. Asterisk cannot tell the second call that the first one is still in process; that is an artifact of the SIP protocol, and may not (will not) be true for many other channel types.

Also, putting a different codec in the "200 OK" back to the first peer than it selected in its INVITE will not work properly in some cases... that would result in Asterisk sending audio to the first peer using a different codec than it uses to send audio to Asterisk.

The biggest problem here is that Asterisk is _not_ a SIP proxy, and it is _not_ truly a back-to-back UA. It is a PBX/switch, and its channels are independent from each other. Trying to make the channels dependent on each other will be very complicated. What you are trying to do works just fine with other brands of phones as well (I have personally used it with Cisco, Polycom and Snom phones), so I suspect that you are seeing a combination of a problem in the second peer's SIP firmware and expectation of behavior from Asterisk that it does not offer.
By: Brian West (bkw918) 2005-03-04 11:16:34.000-0600

I wonder if a reinvite is trying to take place between the devices and blowing up?

/b
By: mihai (mihai) 2005-03-04 12:39:30.000-0600

There is no reINVITE going on here, we're not at that stage yet... you can check the traces.

However, a reINVITE could be a nice way of switching the codec in the middle of the call, for example (as kpfleming mentioned) if the call goes to attendant first, then to the second device... Asterisk could keep a list of allowed codecs for the first channel and if there is a need to switch the codec, could issue a reINVITE to the first device. I guess that this would require some pretty significant changes to the code though...
By: Brian West (bkw918) 2005-03-17 20:57:32.000-0600

This really isn't a bug... I think we all agreed that this could be an implementation issue in asterisk.  But then again as Kevin pointed out asterisk is not a SIP Proxy...

/b