Re: [asterisk-dev] Potential change to outgoing codec offers (new topic)
On Tue, Oct 24, 2006 at 07:28:57AM -0500, Kevin P. Fleming wrote: > Whatever we do, we will not offer formats to the second endpoint that > were not chosen during negotiation with the first endpoint. We don't > want the call to be setup using direct media and a format which we > cannot support should we need to pull the media back to Asterisk. Absolutely agree. But that's not the problem in bug #8152 - Asterisk supported both codecs, but it forget to stitch itself back into the media path. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Potential change to outgoing codec offers (new topic)
On Mon, Oct 23, 2006 at 05:47:56PM -0500, Kevin P. Fleming wrote: > > (However, I have no idea what these devices would do if you completed the > > call, and then they had to use the 'WIBBLE' codec to send audio...) > > I don't think that my proposal is practical; instead, what I am going to > do is to modify the channel drivers to not offer formats (audio or video > codecs) which either don't match the incoming channel's format, or are > not transcodable to that format. The translation core already has all > the information needed to do this. > > While this won't have the complete effect you wanted (forcing the 'B' > endpoint to only select the no-transcode-needed format), it will be > close, given that we put the no-transcode-needed format at the top of > that list in the SDP. OK, that's good (it looks like our mails crossed) > If the 'B' endpoint chooses another format which > requires transcoding in spite of our stated preference, there's no > simple way for us to deal with it. Yep. So if you've already offered all those codecs to the second phone, and with a direct RTP path back to the first phone, you'd better reinvite quickly to make the RTP path go via Asterisk. Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Potential change to outgoing codec offers (new topic)
On Mon, Oct 23, 2006 at 02:37:39PM +0100, Brian Candler wrote:
> Here's one I knocked together in Perl:
> http://pobox.com/~b.candler/software/testsiperror
>
> The fake codec it offers is "WIBBLE/8000".
>
> And the results I get when pointing it at various SIP UAs:
>
> Audiocodes Tulip ATA (2.2.0_build_6) 403 Forbidden
> Ekiga 2.0.1 180 Ringing (!!)
> Asterisk trunk r45305 with Zaptel FXS 100 Trying, then rings (!!)
And a couple more data points; this time not using the Perl script, but
configuring the Tulip ATA to use only G726-16, and then pointing at an
upstream provider.
Quintum/1.0.0 (via Cicero softswitch I think) 415 Unsupported Media Type
sipgate.co.uk (derived from Asterisk?)100 Trying, followed by
488 Not acceptable here
I'm surprised how inconsistent and even broken this behaviour is.
So I've been trying to think of some other approaches. Here's what I've
considered:
1. Drive the media exchange from the other end. That is, send an empty
INVITE for the second call leg; the initial SDP offer comes from the far end
in the 200 OK, and the media setup is completed in the ACK.
However this doesn't help us in the case where the *incoming* leg already
has an empty INVITE; we learn nothing about the capabilities of that side
until we complete the call, so we're back to square one.
[In any case, this method of working may not be implemented properly by UAs,
even though it's allowed by the RFCs. You can also get audio clipping at the
start of the call, as described in RFC 3960]
2. For calls placed to dynamic terminals which have registered, you could
probe their capabilities with OPTIONS at registration time. This might be
more efficient than sending an OPTIONS request at call setup time.
This is caching of information, so the cache can become stale (i.e. the UA
may have changed what codecs it permits between registration and the call
coming in). I don't think that will be a problem in practice.
For calls going out to upstream providers, in principle you could probe them
in the same way. However if they run a VoIP switch like Asterisk, I expect
they will give a very general response (i.e. "I have all these codecs")
which doesn't help you much.
3. Revert to 1.2 behaviour (i.e. offer all codecs with media proxying, and
re-INVITE to set up native bridging afterwards). However, re-order the codec
list so that the codecs included in the incoming SIP INVITE appear before
the others. This might make it a bit more likely that the far end will
choose a codec which doesn't need transcoding.
This will work of course. However the codec decision is made by the far end
based on its own preferences, so you may still end up with unnecessary
transcoding; and even if you don't, there may still be an audio glitch while
the re-invite takes place.
4. Like (3) but turn it on its head: that is, set up the call with direct
media first, offering all codecs; and quickly re-INVITE to fix up the media
stream where transcoding turns out to be necessary.
An example in more detail:
- first phone sends offer: codecs A,C,E from IP address X
- Asterisk sends offer to second phone: codecs A,C,E,B,D,F from IP addr X
- second phone sends response to Asterisk
- if it picked codec A,C or E then Asterisk completes the direct
media path by sending an OK to the first phone
- if it picked codec B,D or F, then Asterisk immediately re-INVITEs
to the second phone, redirecting the media stream to Asterisk,
then sends OK to the first phone also directing media at Asterisk.(*)
In the second case, there will be a brief period of time when the first
phone receives media packets for a codec it doesn't grok. Hopefully this
won't crash it; if it does, then you set canreinvite=no on that phone, and
so Asterisk falls back to the behaviour of unconditionally proxying media.
I'd say this is a reasonable solution, if you assume that *not* transcoding
is going to be the most common scenario. It gives a clean glitch-free direct
audio setup in that case. It's also pretty close to the current (but broken)
1.4 behaviour.
(*) Asterisk could choose whichever of A,C or E is cheapest to transcode;
or it could honour the preference of the originator by picking the
first one that it supports (i.e. A, unless Asterisk doesn't have
an SLIN translator for A)
This is all starting to feel like a circle-squaring exercise though...
people want immediate end-to-end media setup, but people want RTP proxying
and transcoding to work immediately too :-{
Regards,
Brian.
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] SIP Address port remove suggestion
On Tue, Oct 17, 2006 at 11:13:48AM +0100, Alexandre Almeida wrote: > [xxyy] > username=123456 > type=peer > secret=1423241 > port=5070 > outboundproxy=my.proxy.com > host=gateway.server.com > > > when dialing a number like this 00123456789: > > asterisk make this, > > SIP:[EMAIL PROTECTED]:5070 > > but what i need is, > > SIP:[EMAIL PROTECTED] > > asterisk put the port on the SIP address, any idea on how to remove the > port from the sip address.. Hmm, depends what do you mean when you write "port=5070". You might want: (1) The INVITE to be sent to my.proxy.com port 5070, and the INVITE to be for sip:[EMAIL PROTECTED] (implied: the proxy should use DNS to resolve the domain to IP and port, and default to UDP port 5060) (2) The INVITE to be sent to my.proxy.com port 5060, and the INVITE to be for [EMAIL PROTECTED]:5070 I'm not sure what Asterisk actually does in this case. But it would seem reasonable to want to be able to set outboundproxy host address and port independently of the target SIP URI domain and port. Perhaps if ast_get_ip_or_srv() were able to parse x.x.x.x:p (i.e. IP and port), then you could write outboundproxy=my.proxy.com:5070 - but I don't think you can do that today. Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Regarding SIP direct media (new topic)
On Tue, Oct 17, 2006 at 08:54:50AM +0100, Brian Candler wrote: > Sorry, I missed the notes, as I wasn't emailed when they were added. (Mantis > did this when notes were added to 8072 Mistype, I meant 8078. Anyway, that's a report I opened in the same way AFAIK, and whenever someone added a note I got an E-mail. Both 8078 and 8152 have 10-16-06 05:47 candlerbIssue Monitored: candlerb in their history. Strange. Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Regarding SIP performance
On Mon, Oct 16, 2006 at 03:34:10PM +0200, Johansson Olle E wrote: > Or, set up the call as normal - one call leg to Asterisk, transcode > and another > call leg and media stream to the other device. > > That should be the case here. But the point is - how do you know when you need to do that? At the moment (SVN), Asterisk is passing on an INVITE with SDP pointing to the first endpoint. That works sometimes, but not other times, depending on which codecs the second endpoint supports. But you have to know whether to try this before you send on the INVITE. Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Regarding SIP performance
On Mon, Oct 16, 2006 at 03:11:15PM +0100, Brian Candler wrote: > - if you get a 606 then INVITE again, this time listing all the codecs you > are prepared to transcode for, ... and in particular, at this point don't offer G729 if you don't have a G729 licence available ... > with SDP pointing at Asterisk. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Regarding SIP performance
On Mon, Oct 16, 2006 at 02:11:09PM +0100, Brian Candler wrote: > * Make the INVITE to the second phone only offer codecs which the first > phone offered. Then if the call is rejected due to no compatible codec > (606?), try again using the normal two-leg setup, with SDP pointing at the > Asterisk server. This to me seems the cleanest way. Aside: I think this would also give a very clean solution to the codec-selection problem discussed previously. As I understand it, you can get situations where phone1 and phone2 share a common codec, but transcoding still ends up taking place because phone1's preferred codec was chosen first, and phone2 doesn't support it. So the suggested algorithm is: - pass on an INVITE with the same codecs as the incoming INVITE (filtered against those codecs which you wish to disallow, of course), with SDP pointing to incoming peer if canreinvite=yes, or SDP pointing to Asterisk if canreinvite=no. - if you get a 606 then INVITE again, this time listing all the codecs you are prepared to transcode for, with SDP pointing at Asterisk. Given a chain of SIP calls, e.g. phone1 -> astx1 -> astx2 -> phone2, this will push the transcoding down the chain as far as possible, and if there is any common end-to-end codec it will be used (as long as it's not disallowed by any intervening device) Or have I overlooked a problem? Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Regarding SIP performance
On Mon, Oct 16, 2006 at 01:28:13PM +0200, Johansson Olle E wrote: > >I've tested it now, and in my SVN build, which is about 10 days out > >of date, > >it appears to be broken. > > > >Full description posted at http://bugs.digium.com/view.php?id=8152 > > > >In summary: the two endpoints think they can both use different > >codecs at > >the same time, with the RTP stream running directly between them :-( > > If they're not compatible, we should not re-invite or set up the RTP > directly. > I'll check the bug report. OK. I don't know the best way to solve this though, because the second leg INVITE has already offered a bunch of codecs to the second phone, some of which the first phone doesn't support, but with SDP pointing at the first phone. We don't learn which one the second phone chooses until it's too late. Some possible ideas: * Probe the second phone with OPTIONS first, to discover what codecs it supports. Adds latency to every call. or * Make the INVITE to the second phone only offer codecs which the first phone offered. Then if the call is rejected due to no compatible codec (606?), try again using the normal two-leg setup, with SDP pointing at the Asterisk server. This to me seems the cleanest way. or * Allow the wrongly-setup call to proceed anyway, and then when you realise there's an incompatibility immediately fix it with some re-INVITEs (yuk) Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Re: SIP to IAX (Jeremy McNamara)
On Thu, Oct 05, 2006 at 03:47:22AM -0400, Jeremy McNamara wrote: > I suggest you purchase the Asterisk book. You seem to be missing quite a > few major core concepts of how Asterisk functions. > > > http://www.oreilly.com/catalog/asterisk/ Or just download the whole book for free: http://www.asteriskdocs.org/modules/tinycontent/index.php?id=11 ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Rate limiting traffic to address potential DoS issues?
On Tue, Sep 26, 2006 at 05:02:56PM -0500, Jason Parker wrote: > Let's look at other apps (say, apache) for an example of something > similar. What happens if you throw thousands of requests at apache per > second? It's going to die. And why shouldn't it? Stuff like this, in my > opinion, is best handled at the firewall level, or perhaps with a load > balancer of sorts. I think you may be comparing apples and oranges there. HTTP runs over TCP. There are well-known denial of service attacks against TCP (e.g. half-open connections from spoofed source IP addresses) and well-known defences which can be implemented in the kernel or in firewalls (e.g. syn cookies). Therefore by the time Apache sees an incoming TCP request, these have been filtered out. SIP generally runs over UDP, and so you don't get this protection. In fact there's very little generic protection that the kernel could offer. In both Apache and Asterisk, as you say, if you overload the system with a large number of *valid* requests then they may fall over. I suspect that's not actually the problem under discussion; rather, that there are specific denial-of-service attacks of the spoofed IP variety against SIP. However, without disclosure of what the actual attacks under consideration are, then it's very difficult to be specific about how they could be handled. Equally, it's clear that any sort of attack can be managed by a firewall if it is sophisticated enough. But how many firewalls have full application-layer stateful support for SIP? And if there are any, which ones have been tested with Asterisk and certified by Digium? Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Data Modem calls passthrough
On Mon, Sep 04, 2006 at 07:18:33PM +0500, Anton wrote: > Does anyone know is possible to pass DIALUP modem calls > over, through asterisk? Nothing extra needed I think, say > asterisk is in-between of 2 telcos, connected over E1 from > both sides. Modem calls is already DATA, so will it work, > or asterisk will make some sort of codec resampling, so > original E1 data will be lost? There's some useful background here: http://www.soft-switch.org/foip.html (it talks about fax rather than data modem, but the same things apply) Basically: if you want data modem calls to work, you have to either: (1) use a G711 codec, have *very* low latency and jitter in your network, turn off all echo cancellation, silence suppression, dynamic jitter buffering etc, and cross your fingers; or (2) use V.150 "modem over IP", which is the data modem equivalent of T.38 "fax over IP". Here, the modulated audio is demodulated at the first endpoint, passed as data over the network, and remodulated at the far end gateway. However there are very few implementations of this that I'm aware of, and Asterisk doesn't have it. Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Note about mpg123
Looking at SVN trunk source for asterisk, a couple of minor points: (1) doc/mp3.txt says: Please use mpg123 0.59r. Using mpg123 pre0.59s can/may/will result in crashes and/or unreliable playback. Running "make mpg123" in the Asterisk source directory will download and make the working version. However, the "make mpg123" target no longer exists. Maybe just the second para there needs to be deleted. (2) agi/jukebox.agi has a comment pointing to URL http://www.mpg123.de/cgi-bin/sitexplorer.cgi?/mpg123/ This gives a 404. The new link is http://www.mpg123.de/download.shtml, but perhaps a link to just http://www.mpg123.de/ would be more robust. Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Make for res_jabber broken in svn trunk - needs new library
On Tue, Aug 22, 2006 at 04:53:44PM +0100, Julian Lyndon-Smith wrote: > libtasn1 is a library for Abstract Syntax Notation One (ASN.1) and > Distinguish Encoding Rules (DER) manipulation. > > Whatever that means :) http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf http://www.itu.int/ITU-T/studygroups/com10/languages/X.690_1297.pdf respectively. Warning: not light reading :-) (ASN.1 and DER provide a packed structured data format, used by LDAP and DNS protocols amongst other things) ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Routing data modem calls
On Fri, Jul 28, 2006 at 12:49:14PM +0200, Olivier Krief wrote: > In many cases, I noticed (though I didn't experienced) data modems could > simply be replaced by serial-to-ethernet converters plus dialup routers. > What do you think of that ? That won't work for me: (1) EPOS terminals may have modems built-in. It would require modifications to the terminals to get at the RS232 signals. (2) The other end (i.e. the bank or whatever) would also need to install serial-to-ethernet convertors, in addition to their existing modem bank. Then I would need to install a secure IP link into the bank or whatever, whereas at the moment all these calls just come in over the PSTN. Regards, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Routing data modem calls
On Fri, Jul 28, 2006 at 10:27:58AM +0100, Brian Candler wrote: > Does anyone know if there's a standard mechanism for carrying data modem > calls over a VoIP-type network? I know there's T.38 for fax, but I have not > been able to find something equivalent for generic data modem calls. To answer my own question, at least in part - there *is* a standard for this, called V.150 (= V.150.0 + V.150.1), and Googling for that turns up the sort of thing I was looking for. (Sometimes, a bookshop is better than the Internet. I found a reference to this standard in an O'Reilly book called "Switching to VoIP". However, even this book says that if you need legacy modem services, you should just keep some POTS lines around to support them :-) I notice that the source for Asterisk 1.2.10 doesn't refer to V.150, but Asterisk SVN at least decodes the frame type in frame.h / frame.c. Does this mean there is some plan for this in the pipeline? Thanks, Brian. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
