> > > This was only true with Asterisk up to and including 1.2; 1.4 and
> > beyond
> > > send proper RFC2833 (now RFC4833) DTMF telephone-events and
> > > interoperability has been dramatically improved.
> >
> > my patch was for 1.4 so that is not true.
>
> What specifically does the 1.4 DTMF implementation break in terms of the
> RFC? RFC-2833 is pretty vague about a lot of things, and most vendors
> implementations (Cisco, Avaya, Sonus etc..) can be deemed to be "in
> violation" of the RFC. For example Cisco doesn't respect DTMF duration
> events, and clips DTMF upon receipt of a DTMF "end of event" marker.
> Technically this violates the RFC.
>
duration per the rfc is optional, recommended for pstn gateways, but
optional.
But aside from that there are issues, some of them such as the one I
will say here (only becuase its been a couple months and I dont recall
everything that I did, although it was all very obvious stuff if you
look at it with a packet sniffer such as wireshark). RTP timestamps
dont match, they are just plain wrong infact (1.4.15 was what I did this
in, yes rtp is rfc1889 but this is in the 2833 generation code and only
happens when it generates a 2833 packet, so its clumped together with
the other things I fixed).
At the time I gave oej a full list via irc, he made some comment on the
bug issue and I kinda left it alone. I think there were 3-4 things
fixed, this is either 25% or 33% of it, I just dont recall right now.
> In a lot of ways, the Asterisk RFC-2833 implementation is more compatible
> (in 1.4) than most other stacks out there.
That may be, however it doesnt mean that its compliant :)
--
Trixter http://www.0xdecafbad.com
Bret McDanel
Belfast +44 28 9099 6461 US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
Posts
No comments:
Post a Comment