[Home]

Summary:ASTERISK-07933: P2P connection is established when endpoints are using incompatible codecs
Reporter:Brian Candler (candlerb)Labels:
Date Opened:2006-10-16 05:47:54Date Closed:2007-06-18 13:51:13
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) earlyrtp1.txt
( 1) earlyrtp2.txt
( 2) sip.conf
( 3) sip-codec-mismatch.txt
( 4) sip-debug2.txt
( 5) sip-debug3.txt
( 6) sip-debug4.txt
Description:Asterisk now has a neat feature where a call between two SIP legs is set up with the media stream running end-to-end from the start of the call - just like a SIP proxy.

However, this breaks when transcoding is needed, as the two sides end up using different codecs but are squirting RTP directly at each other.


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

Test rig:

* 10.69.255.246: Tulip ATA, only G711u enabled
* 10.69.255.251: Asterisk
* 10.69.255.242: Tulip ATA, only G726-32 enabled

Place a call from first ATA to second. It rings and connects, but no audio
passes.

tcpdump clearly shows G711 being sent in one direction and G726-32 in the
other:

11:35:24.252880 IP 10.69.255.246.5004 > 10.69.255.242.5004: UDP, length 172
11:35:24.263266 IP 10.69.255.242.5004 > 10.69.255.246.5004: UDP, length 92
11:35:24.272892 IP 10.69.255.246.5004 > 10.69.255.242.5004: UDP, length 172
11:35:24.283263 IP 10.69.255.242.5004 > 10.69.255.246.5004: UDP, length 92
11:35:24.292912 IP 10.69.255.246.5004 > 10.69.255.242.5004: UDP, length 172
11:35:24.303285 IP 10.69.255.242.5004 > 10.69.255.246.5004: UDP, length 92

(172 = 12 bytes RTP + 160 payload, 92 = 12 bytes RTP + 80 payload)

A tcpdump of the SIP exchange is attached. You can see:
- first phone offers only PCMU to Asterisk
- Asterisk offers a bunch of codecs to second phone
- second phone chooses g726-32
- Asterisk tells first phone that it can use PCMU - even though the SDP has set the media stream to run directly between the two endpoints :-(
Comments:By: Olle Johansson (oej) 2006-10-16 08:35:39

The bug here is that media should stay through asterisk.
By: Olle Johansson (oej) 2006-10-16 08:37:41

I need a full SIP debug from *ASTERISK* to see what is happening in asterisk (according to the bug guidelines - please read and upload a new file)
By: Olle Johansson (oej) 2006-10-16 08:38:58

I would also like to see sip.conf settings. Thank you.
By: Brian Candler (candlerb) 2006-10-17 02:47:31

OK I have run the test again, and uploaded asterisk's debug output as sip-debug2.txt.gz, and the entire sip.conf.
By: Olle Johansson (oej) 2006-10-17 06:58:43

There is definitely a bug here in Asterisk. We should not offer all those codecs for a call with the direct RTP stream.
By: Olle Johansson (oej) 2006-11-13 13:34:36.000-0600

There's been a few changes lately. Can you please retest? Thank you for your help and patience.
By: Brian Candler (candlerb) 2006-11-13 13:59:12.000-0600

I'm afraid I may not have time to retest for a couple of weeks, due to more pressing work.

However if you were able to replicate the problem with the old code, and if the new code behaves properly, then I don't mind if you want to close the ticket.
By: Ronald Chan (loloski) 2006-11-14 07:38:25.000-0600

candlerb: since this bug has been file for SVN trunk is this applicable for both 1.2 and 1.4? i maybe able to test this but i need to know where to begin with.



Best regards,

Ronald
By: Brian Candler (candlerb) 2006-11-14 08:38:45.000-0600

I was testing trunk. I'm not sure, but I believe this behaviour is in 1.4 but not 1.2. That is, 1.2 still sets up the call as two separate legs with RTP via Asterisk initially, and then reinvites to stitch the two together if appropriate.
By: Brian Candler (candlerb) 2006-11-16 06:21:23.000-0600

OK I have now rebuilt Asterisk using SVN trunk r47654 and repeated the test. Due to DHCP, the first ATA is now on 10.69.255.248 and second is 10.69.255.247. Asterisk is still on 10.69.255.251 and the config is the same.

The result is exactly the same:
- call is setup but no audio is heard
- tcpdump clearly shows different codecs being used in both directions

12:02:27.392188 IP 10.69.255.248.5004 > 10.69.255.247.5004: UDP, length 172
12:02:27.410003 IP 10.69.255.247.5004 > 10.69.255.248.5004: UDP, length 92
12:02:27.412197 IP 10.69.255.248.5004 > 10.69.255.247.5004: UDP, length 172
12:02:27.430009 IP 10.69.255.247.5004 > 10.69.255.248.5004: UDP, length 92
12:02:27.432205 IP 10.69.255.248.5004 > 10.69.255.247.5004: UDP, length 172
12:02:27.450014 IP 10.69.255.247.5004 > 10.69.255.248.5004: UDP, length 92

I will upload sip-debug3.txt containing the debug output.

Now, please don't take this the wrong way, but as this is pretty core functionality, perhaps Digium could consider setting up a rig to test this themselves? They just need two phones or ATAs with selectable codecs, preferably connected to a hub so they can tcpdump the traffic between them.

It doesn't seem very efficient for Digium to make some assorted changes, wait two weeks for me to retest, just to determine that the changes didn't work, and continue round this loop.

Aside: I reported and demonstrated this bug primarily as a favour to the community. Asterisk is a useful test and development tool for me, but just a means to an end. Tinkering with Asterisk itself is a low priority. In particular, this means that if the rig on my desk has been repatched for some other purpose, reconfiguring it just to test some Asterisk change is always going to wait.

Regards, Brian.
By: Brian Candler (candlerb) 2006-11-16 06:37:16.000-0600

Hmm, looking at that sip-debug3.txt in detail, not all the debugging which I'd want is there.

I believe this is due to the CLI change of the week:

  sip set debug ip x.x.x.x

Now, I had set

  sip set debug ip 10.69.255.248
  sip set debug ip 10.69.255.247

but it would seem that the second takes precendence over the first. I don't know if there's a way to turn on SIP debugging globally.

Anyway, sip-debug4.txt is the same test repeated again, but this time just with "sip set debug ip 10.69.255.248", so you see the packets from the perspective of the first ATA.

This shows Asterisk sending back an OK for PCMU to the first ATA, even though the second ATA chose g726-32 from those offered by Asterisk.
By: Olle Johansson (oej) 2006-11-16 08:15:24.000-0600

I am not Digium. I am a community developer that shares my time, just like you. If you need Digium support, call them.
By: Brian Candler (candlerb) 2006-11-16 09:35:16.000-0600

OK, and thanks for engaging with me.

No, I don't need Digium support. If they're going to sell this code then they might want to fix it first; but if not then I won't lose any sleep over it.

Regards, Brian.
By: Serge Vecher (serge-v) 2006-11-20 12:20:24.000-0600

ok, getting back the issue at hand here -- the problem still exists in trunk r47654, correct? Thank you everyone who is involved for your time and hard work.
By: Brian Candler (candlerb) 2006-11-20 13:44:23.000-0600

> the problem still exists in trunk r47654, correct?

Correct.
By: Olle Johansson (oej) 2007-02-01 15:46:25.000-0600

Please test the same scenario with the "earlyrtpfix" branch. Thanks.
By: Brian Candler (candlerb) 2007-02-08 09:02:19.000-0600

Executive summary: this looks good.

I have rebuilt the test rig. The two ATAs are now on 10.69.255.229 and 10.69.255.230, due to DHCP changes.

At first I couldn't find the 'earlyrtpfix' branch you mention, so I retested with SVN-trunk-r53498. Then I found team/oej/earlyrtpfix in SVN so I built and retested that too.

(1) SVN-trunk-r53498

This appears to work acceptably:

* With one ATA set to uLaw and the other to g726-32: media is proxied via Asterisk

* With both ATAs set to uLaw: the initial offer from Asterisk to the second endpoint offers all codecs, and for a short period both phones send RTP to Asterisk, but then Asterisk re-invites to connect the endpoints together. Asterisk then only sees occasional RTCP packets on odd port numbers.

I guess this is back to the 'old' re-invite behaviour.

However, I did notice that before re-invite kicked in, the ATAs sent 10 or 20 packets of RTP before Asterisk proxied them, which it did in a big burst.

(2) SVN-oej-earlyrtpfix-r53553

This appears to work well:

* With one ATA set to uLaw and the other to g726-32: media is proxied via Asterisk [UDP packet lengths in tcpdump show that transcoding is definitely taking place]

* With both ATAs set to uLaw: RTP is proxied for a short amount of time and then the call is connected directly with re-invite.

The total time before the media streams were reconnected appears to have been less in this branch than trunk, and the handful of packets which did need proxying were proxied immediately.
By: Brian Candler (candlerb) 2007-02-08 09:27:21.000-0600

However, these results were without setting directrtpsetup=yes (which I only just discovered is now available)

With the earlyrtpfix branch, and setting directrtpsetup=yes in sip.conf:

* Both phones on uLaw: call connects directly, no RTP via Asterisk at all. The first ATA offers only PCMU to Asterisk; Asterisk offers all its codecs to the second ATA.

* One phone on uLaw and the second on g726-32: rings but no audio.

In this latter case, the behaviour is the same as the original bug report:
* ATA1 offers call with PCMU
* Asterisk offers call with all codecs to ATA2, with ATA1 as RTP source
* ATA2 accepts g726-32
* Asterisk passes response to ATA1, giving ATA2 as endpoint and PCMU as the codec

I'd say this is a bug. If the second phone has decided to squirt g726-32 packets, then Asterisk should not complete the call by (wrongly) telling the first phone that the stream is PCMU. It would be better to hangup, I think.

Anyway, I have captured SIP debug logs for this case. It is attached in two files: "earlyrtp1.txt" has SIP debugging enabled for the first ATA, and "earlyrtp2.txt" has SIP debugging enabled for the second ATA, since I can't see how to enable it globally.


By: Serge Vecher (serge-v) 2007-02-08 10:12:49.000-0600

thanks for testing, candlerb!
By: Serge Vecher (serge-v) 2007-03-08 14:07:11.000-0600

please test with with 1.4 revision > 58436
By: Serge Vecher (serge-v) 2007-03-26 12:54:34

brian, what's the status here?
By: Brian Candler (candlerb) 2007-03-26 13:43:12

Status is that my Asterisk test rig is currently not in service and I'm working on different projects now.

I believe there's sufficient information above to allow someone else to replicate the problems, but I'm afraid I don't have bandwidth at the moment to do so here.

Regards, Brian.
By: Joshua C. Colp (jcolp) 2007-06-18 13:51:11

This issue should already be fixed per 9221.