[Home]

Summary:ASTERISK-01211: Codec negotiation with re-invites
Reporter:connor (connor)Labels:
Date Opened:2004-03-14 00:25:04.000-0600Date Closed:2004-09-25 02:52:20
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When using a Cisco ATA setup for g729 calling to a cisco gateway, The call leg from The ATA to asterisk will be g729, the leg from asterisk will be ULAW.  Even with re-invites. Asterisk should use the same codec for the second part of the call leg when it's a allowable codec instead of the "best codec"

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

[general]
port = 5060
bindaddr = 0.0.0.0
context = inbound
tos=lowdelay
tos=184
disallow=all
allow=ulaw
allow=g729

[gateway]
type=friend
host=1.1.1.29
canreinvite=yes
qualify=yes
dtmfmode=rfc2833
context=default
disallow=all
allow=ulaw
allow=g729

[siphone]
type=friend
secret=12345
nat=yes
host=dynamic
canreinvite=yes
qualify=200
context=outbound
dtmfmode=rfc2833
mailbox=1234
disallow=all
allow=ulaw
allow=g729

Codec's on ata are all set as 3's which is g729


Comments:By: Olle Johansson (oej) 2004-03-14 04:12:20.000-0600

Please upload a "sip debug" trace of the packets for the first invite/ok and the reinvite, so we can see what happens.
By: connor (connor) 2004-03-14 20:27:38.000-0600

Additional Note:
This is what sip show channels looks like when calling from my ATA to my gateway

Peer             User/ANR    Call ID      Seq (Tx/Rx)  Lag      Jitter  Format
198.144.169.29   9865539193  426aae9837e  00103/00000  00000ms  0000ms  ULAW
198.144.165.65   8659342199  398029354@1  00102/00003  00000ms  0000ms  G729A


and this is waht sip show channels looks like when caling from POTS (from the gateway to my ATA) using a voice-class codec

voice class codec 97
codec preference 1 g729r8
codec preference 3 g711ulaw

Peer             User/ANR    Call ID      Seq (Tx/Rx)  Lag      Jitter  Format
198.144.165.65   8659342199  6f2e827a4e5  00103/00000  00000ms  0000ms  G729A
198.144.169.29   8655391933  A0B1D35-18F  00102/00102  00000ms  0000ms  ULAW

This is what it looks like if I FORCE the gateway to ONLY use g729 when calling the ATA

198.144.165.65   8659342199  40bd03eb650  00103/00000  00000ms  0000ms  G729A
198.144.169.29   8655391933  660AE778-18  00102/00102  00000ms  0000ms  G729A
By: Brian West (bkw918) 2004-03-16 12:04:38.000-0600

Asterisk can't see the other channel's codec so it has no way to do what you want.  The only way is to force it like you did.
By: connor (connor) 2004-03-16 12:17:23.000-0600

Why not? It knows about the other channel, it has to, because it's gotta bridge it..  It knows enough about the channel to know weather it can "native" bridge it too..  Simply forcing it isn't going to work for ATA's, because they can only have 1 g729 channel in use at any given time, the other channel will be ulaw if it's the second one in use.  Not only that, but why else put more than 1 allow= statement in a SIP entry...
By: connor (connor) 2004-03-18 14:14:32.000-0600

OKay, some more info..
In 0.7.2 in rtp.c around line 1203, we have

if (codec0 != codec1)

okay.. in a later cvs (CVS-02/25/04-14:35:41) we have

if (!(codec0 & codec1))

This is allowing asterisk to bridge the 2 channels together, even though they may be speaking DIFFERENT codecs, BUT support a COMMON codec.  There is a flaw in the logic here..  We should first, find the common codecs, then pick the "best" codec from that, and set BOTH channels to that codec, in correctly ordered "best" prefrence, example being I might want g729 vs ulaw to be best codec.
By: Olle Johansson (oej) 2004-03-18 14:52:08.000-0600

Let's see if I understand you.
1) A SIP ua calls asterisk and negiotiates codec #1
2) Asterisk places a SIP call forward to a Cisco gw
3) In this call, Asterisk should offer the codec from call #1 as a preferred codec in the codec negotiation
4) With good luck and some karma, the second call uses the same codec as call #1 and then Asterisk only acts as a passthrough without any codec conversion

One has to remember that the SIP channel receives call 1, connects it to the PBX core and let the PBX core place the second call. The second call may be SIP, but could be anything else as well. IF it's SIP, the core needs to tell the SIP channel to use codec hints from call #1.

The SIP channel doesn't handle the two calls as one, the PBX core is in the middle of all calls through Asterisk. I'm guessing that fixing this is a huge task (or a quick Mark fix :-). You need to know how the PBX core works. I'm not fully aware of that myself, so I can't help you there.

So I'm guessing the logic that you needs to add is
* When you receive a call from the PBX core
* Check if the owner is another SIP call
* if (somevariablefromsip.conf) is set, get the codec used and add it to the top of the list for *this* call

How do we configure this - as a global setting for all calls?
By: connor (connor) 2004-03-18 15:46:22.000-0600

Correct, Bear in mind, that I'm using re-invites, so asterisk simply needs to setup the RTP stream using the correct codecs, which means the SAME codecs on both ends..  Someone changed that line in rtp.c for SOME reason I kinda thought it was to fix this problem, but guess not....  I really don't know where the changes should be made, but, I think it's something that's needed..  Not everyone is using asterisk to transcode the codecs or using it inbtween the media stream..

Since this is mainly involving re-invites, maybe just have this "feature" turned on when re-invites are active...   This problem doesn't exist if it's not a re-invited call because asterisk will do the transcodeing.

Mark, Can you comment on this bugnote?
By: Mark Spencer (markster) 2004-03-19 03:42:55.000-0600

I've made some changes to chan_sip which *should* cause it to properly order the codecs with the requested codec being the highest priority one.  Please note this is *untested* as i don't have an environment for it, but if this doesn't work, find me on IRC and give me login information and i'll work on it in your box.
By: connor (connor) 2004-03-19 13:41:23.000-0600

Mark, I'm heading out of town for this weekend, I'll have to look at it Monday night when I get back into town..  I'll pull the latest CSV and put it on my development machine and check to see if it works.   Thanks!
By: Mark Spencer (markster) 2004-03-22 14:58:36.000-0600

What's the story?
By: Mark Spencer (markster) 2004-03-23 19:08:51.000-0600

Please let me know if this made a difference or I'm going to hvae to close out this bug and assume that it did (which is not likely a good assumption).
By: Mark Spencer (markster) 2004-03-31 11:22:17.000-0600

As far as I know, this is fixed in CVS *head*.  If this is still a problem you can reopen the order.