Re: [asterisk-users] Forcing repacketization on SIP to SIP call
JT Once again thanks for the help on this. I have found the issue, which was, as they say, "carbon based". I was getting mixed up because the default setting allow=alaw, is displayed as follows when I do "sip show user ": Codec Order : (ulaw:20,alaw:20,g729:20) which I thought was equivalent to having allow=alaw:20, but it is not. Setting the ACLs to alaw:20 explicitly as you described has fixed this issue. W.r.t. you comment: > and in the SDP Asterisk should offer a ptime and maxptime I must add that I could not get Asterisk to send a maxptime in the SDP, nor can I find any instance of "maxptime" in the Asterisk source code (version 1.4.18 so it may have since been added). Thanks again! Richard On Tue, Nov 11, 2008 at 11:29 AM, Richard Brady <[EMAIL PROTECTED]> wrote: > JT > > Thanks for this detailed response. It's clear I have some more homework to > do before going anywhere near Mantis, but I will follow up either way. > > Regards, > Richard > > > On Tue, Oct 28, 2008 at 9:02 PM, John Todd <[EMAIL PROTECTED]> wrote: > >> >> This seems like a transcoding issue, and the RTP code may not be >> clever enough to understand that a repacketization is "transcoding" >> and therefore lets the media flow directly and/or passes the RTP >> packets through without examining or modifying them. This could be an >> error in the way RTP transcoding is handled - put on your superhero >> bugtracking cape and post to Mantis! >> >> I'd suggest that you document this clearly, and put it on the >> bugs.digium.com system if you've tried all possible iterations of >> allow= and deny= for getting this media to transcode. It would seem >> that "alaw:20" is different than "alaw:40", and if you've found that >> they are treated as equal then there seems to be a problem. While not >> explicitly stated in the "doc/rtp-packetization.txt" file, it does >> seem that several things are true: >> >> - it seems that if a remote sender is sending 40ms packets, and you >> have not explicitly denied 40ms packets, that Asterisk should accept >> those packets. This seems to work. >> >> - if you explicitly have "deny=all" and then "allow=alaw:20" in a >> peer definition, it should be the case that Asterisk takes whatever >> audio stream and transcode it for the remote peer in that format (and >> in the SDP Asterisk should offer a ptime and maxptime based on the >> default and highest ptime acceptable, in this case "20" for both.) >> Is this broken? >> >> - if a remote host sends you a ptime that is not defined or >> defaulted in the list of "allow=" codec choices for that peer (or >> globally) then the call should be refused just like it would be with >> any other codec mismatch. (Of course, if you don't have a "deny=all" >> as the first statement in your peer codec list, Asterisk should let >> anything through since that's the way those ACLs work. I mention this >> only as a caution for reporting problems that might not be problems.) >> Is this broken? >> >> >> This problem is actually fairly important when we start talking about >> "scale". All RTP-based systems start to experience bottlenecks >> introduced by Packets-Per-Second limits on hardware interfaces. The >> upper limit of performance starts to be more bound to throughput on >> interfaces and kernel drivers, rather than in the higher-layer code. >> PPS, not megabits per second, becomes the number to beat. If you can >> get RTP packets to go from 20ms to 40ms, it doubles the size of the >> packet and effectively halves the number of packets you're sending on >> your interface, which _could_ lead to doubling of total numbers of >> calls as the limits of interface buffering are reached in the near >> future. Even if you're just doing this on one leg of a looped call, >> this still could reduce your overall PPS by 25%, which is nothing to >> sniff at. Of course, I'm assuming that the load introduced by re- >> packetizing different packet delays is not significant - this could be >> a false assumption. >> >> JT >> >> >> --- >> John Todd >> [EMAIL PROTECTED]+1-256-428-6083 >> Asterisk Open Source Community Director >> > > > > ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Forcing repacketization on SIP to SIP call
JT Thanks for this detailed response. It's clear I have some more homework to do before going anywhere near Mantis, but I will follow up either way. Regards, Richard On Tue, Oct 28, 2008 at 9:02 PM, John Todd <[EMAIL PROTECTED]> wrote: > > This seems like a transcoding issue, and the RTP code may not be > clever enough to understand that a repacketization is "transcoding" > and therefore lets the media flow directly and/or passes the RTP > packets through without examining or modifying them. This could be an > error in the way RTP transcoding is handled - put on your superhero > bugtracking cape and post to Mantis! > > I'd suggest that you document this clearly, and put it on the > bugs.digium.com system if you've tried all possible iterations of > allow= and deny= for getting this media to transcode. It would seem > that "alaw:20" is different than "alaw:40", and if you've found that > they are treated as equal then there seems to be a problem. While not > explicitly stated in the "doc/rtp-packetization.txt" file, it does > seem that several things are true: > > - it seems that if a remote sender is sending 40ms packets, and you > have not explicitly denied 40ms packets, that Asterisk should accept > those packets. This seems to work. > > - if you explicitly have "deny=all" and then "allow=alaw:20" in a > peer definition, it should be the case that Asterisk takes whatever > audio stream and transcode it for the remote peer in that format (and > in the SDP Asterisk should offer a ptime and maxptime based on the > default and highest ptime acceptable, in this case "20" for both.) > Is this broken? > > - if a remote host sends you a ptime that is not defined or > defaulted in the list of "allow=" codec choices for that peer (or > globally) then the call should be refused just like it would be with > any other codec mismatch. (Of course, if you don't have a "deny=all" > as the first statement in your peer codec list, Asterisk should let > anything through since that's the way those ACLs work. I mention this > only as a caution for reporting problems that might not be problems.) > Is this broken? > > > This problem is actually fairly important when we start talking about > "scale". All RTP-based systems start to experience bottlenecks > introduced by Packets-Per-Second limits on hardware interfaces. The > upper limit of performance starts to be more bound to throughput on > interfaces and kernel drivers, rather than in the higher-layer code. > PPS, not megabits per second, becomes the number to beat. If you can > get RTP packets to go from 20ms to 40ms, it doubles the size of the > packet and effectively halves the number of packets you're sending on > your interface, which _could_ lead to doubling of total numbers of > calls as the limits of interface buffering are reached in the near > future. Even if you're just doing this on one leg of a looped call, > this still could reduce your overall PPS by 25%, which is nothing to > sniff at. Of course, I'm assuming that the load introduced by re- > packetizing different packet delays is not significant - this could be > a false assumption. > > JT > > > --- > John Todd > [EMAIL PROTECTED]+1-256-428-6083 > Asterisk Open Source Community Director > ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Forcing repacketization on SIP to SIP call
On Oct 27, 2008, at 10:34 AM, Richard Brady wrote: > Hi folks > > I have a handset talking to Asterisk, which in turn puts the call > through to an ITSP. > > The handsets likes to send audio in 40ms frames (even though > Asterisk requests 20ms frames with a ptime header in the SDP). > > The ITSP doesn't request any particular frame length (with ptime) or > state a maximum length (with maxptime), so when Asterisk receives > the 40ms media frames from the handset, it simply relays it on to > the ITSP. Unfortunately the ITSP doesn't support this, and the > result is one-way audio. > > I would like to know whether there is a way to force Asterisk to > repacketize the media stream, converting from 40ms frames to 20ms > frames. I am aware of the allow=alaw:20 syntax but this doesn't seem > to work. It is not clear from the docs whether that setting is for > the SDP offer (in which case it would only affect incoming media) or > whether it's used to to actually force what is sent to a peer/user > as well (in which case it is not behaving as expected). > > I would also be interested to know what the correct action is for > the ITSP to take. How do they complain (using SIP and/or SDP) that > the media received is not what they were expecting? > > Any help would be greatly appreciated. > > Regards, > Richard > > -- > Richard Brady > T: +44 (0)7771 623 348 > E: [EMAIL PROTECTED] This seems like a transcoding issue, and the RTP code may not be clever enough to understand that a repacketization is "transcoding" and therefore lets the media flow directly and/or passes the RTP packets through without examining or modifying them. This could be an error in the way RTP transcoding is handled - put on your superhero bugtracking cape and post to Mantis! I'd suggest that you document this clearly, and put it on the bugs.digium.com system if you've tried all possible iterations of allow= and deny= for getting this media to transcode. It would seem that "alaw:20" is different than "alaw:40", and if you've found that they are treated as equal then there seems to be a problem. While not explicitly stated in the "doc/rtp-packetization.txt" file, it does seem that several things are true: - it seems that if a remote sender is sending 40ms packets, and you have not explicitly denied 40ms packets, that Asterisk should accept those packets. This seems to work. - if you explicitly have "deny=all" and then "allow=alaw:20" in a peer definition, it should be the case that Asterisk takes whatever audio stream and transcode it for the remote peer in that format (and in the SDP Asterisk should offer a ptime and maxptime based on the default and highest ptime acceptable, in this case "20" for both.) Is this broken? - if a remote host sends you a ptime that is not defined or defaulted in the list of "allow=" codec choices for that peer (or globally) then the call should be refused just like it would be with any other codec mismatch. (Of course, if you don't have a "deny=all" as the first statement in your peer codec list, Asterisk should let anything through since that's the way those ACLs work. I mention this only as a caution for reporting problems that might not be problems.) Is this broken? This problem is actually fairly important when we start talking about "scale". All RTP-based systems start to experience bottlenecks introduced by Packets-Per-Second limits on hardware interfaces. The upper limit of performance starts to be more bound to throughput on interfaces and kernel drivers, rather than in the higher-layer code. PPS, not megabits per second, becomes the number to beat. If you can get RTP packets to go from 20ms to 40ms, it doubles the size of the packet and effectively halves the number of packets you're sending on your interface, which _could_ lead to doubling of total numbers of calls as the limits of interface buffering are reached in the near future. Even if you're just doing this on one leg of a looped call, this still could reduce your overall PPS by 25%, which is nothing to sniff at. Of course, I'm assuming that the load introduced by re- packetizing different packet delays is not significant - this could be a false assumption. JT --- John Todd [EMAIL PROTECTED]+1-256-428-6083 Asterisk Open Source Community Director ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Forcing repacketization on SIP to SIP call
Hi folks I have a handset talking to Asterisk, which in turn puts the call through to an ITSP. The handsets likes to send audio in 40ms frames (even though Asterisk requests 20ms frames with a ptime header in the SDP). The ITSP doesn't request any particular frame length (with ptime) or state a maximum length (with maxptime), so when Asterisk receives the 40ms media frames from the handset, it simply relays it on to the ITSP. Unfortunately the ITSP doesn't support this, and the result is one-way audio. I would like to know whether there is a way to force Asterisk to repacketize the media stream, converting from 40ms frames to 20ms frames. I am aware of the allow=alaw:20 syntax but this doesn't seem to work. It is not clear from the docs whether that setting is for the SDP offer (in which case it would only affect incoming media) or whether it's used to to actually force what is sent to a peer/user as well (in which case it is not behaving as expected). I would also be interested to know what the correct action is for the ITSP to take. How do they complain (using SIP and/or SDP) that the media received is not what they were expecting? Any help would be greatly appreciated. Regards, Richard -- Richard Brady T: +44 (0)7771 623 348 E: [EMAIL PROTECTED] ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
