Summary: | ASTERISK-01211: Codec negotiation with re-invites | ||
Reporter: | connor (connor) | Labels: | |
Date Opened: | 2004-03-14 00:25:04.000-0600 | Date Closed: | 2004-09-25 02:52:20 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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. |