Category: Standards
-
/
I’ll be out in Vancouver Dec 2-7 for the 70th meeting of the IETF.
Continue Reading: I’ll be out in Vancouver Dec 2-7 for the 70th meeting of the IETF.Just confirmed travel plans today – I will be heading out to the 70th meeting of the Internet Engineering Task Force (IETF) in Vancouver, British Columbia, Canada, from December 2-7. If any readers will be out there (either for the IETF or in Vancouver in general), please do drop a note and let me know. This will be my first meeting in my new role with Voxeo and I’m very much looking forward to renewing old acquaintances and also getting more directly involved with the work of the IETF.
-
/
Did you know RFC 4733 had replaced/obsoleted RFC 2833 for DTMF signaling in SIP?
Continue Reading: Did you know RFC 4733 had replaced/obsoleted RFC 2833 for DTMF signaling in SIP?Did you know that RFC 4733 replaced/obsoleted RFC 2833? I just learned this myself through a SIP Forum mailing list exchange the other day. For those not aware, RFC 2833 and now 4733 define methods of carrying DTMF signals (and other similar signaling) in RTP streams separate from the main audio component of the RTP stream. A typical example of use might be where you were using a highly-compressed audio codec for audio between two SIP endpoints where the high degree of compression might make it challenging for the DTMF tones to be correctly interpreted on the receiving end. Using “RFC 2833 compliant” signaling, the sending SIP endpoint would send those DTMF tones as separate packets within the RTP stream.
My key takeaway from learning about RFC 4733 is that we should really be talking about “RFC 4733 compliant” signaling… but given that the industry is really only now starting to really talk about “RFC 2822 compliant” signaling, I’m not sure I expect to see that happening anytime soon.
Anyway, here’s the abstract from RFC 4733 – you can naturally read the rest of the document to understand more:
This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other…
-
/
IETF approves RFC standard for adding dialstrings to SIP
Continue Reading: IETF approves RFC standard for adding dialstrings to SIPIn the usual (and ongoing) flurry of IETF announcements, there was one notice that caught my attention. It announces that an Internet Draft document about “dialstrings” has been approved to become a standards-track RFC. So what, you say? Well here’s a bit more info:
This document provides a way of incorporating a dial string into the SIP or SIPS URI scheme. A dial string is a cousin of a telephone number, but rather than taking the form of a fully-qualified E.164 or national-specific telephone number, it is a description of a literal set of dialed digits that would be delivered over a POTS line. As such, it may include pauses, omit prefixes like area codes, and its applicability is necessarily restricted to a particular context (an enterprise, a LATA, etc). Support for dialstrings was formerly a feature of the tel: URI scheme specification (back in RFC2806); since that functionality did not make it into the revision (RFC3966), it is provided here specifically for the SIP and SIPS case.
Think of it as extra digits you have to type when making a call… or extra keys you have to press to start a service. The challenge is that SIP proxies and…
-
/
Attaining BLISS… (at least in the world of SIP)… a.k.a. why can’t we all just get along?
Continue Reading: Attaining BLISS… (at least in the world of SIP)… a.k.a. why can’t we all just get along?So you’d like your SIP phones to all work together, eh? And you’d like your SIP phone from Vendor A to work with the SIP phone of Vendor B and yet give you the business functionality that you used to have in the PBX from Vendor C?
Good luck.
Yes, they will (or should!) all work together for basic call functions, but if you want to do more than just the very basics, you rapidly wind up in the realm of incompatible SIP implementations. Different vendors support different RFCs… or interpret RFCs differently. It’s a challenge to go beyond basic functionality.
Enter “BLISS“, one of the latest working groups coming out of the IETF. It stands for “Basic Level of Interoperability for SIP Services” and, as noted in its charter, the intent is to define a basic set of functionality (“minimum interoperability requirements”) to allow SIP endpoints to interoperate on 4 specific telephony services:
- Bridged/Shared Line Appearance (BLA/SLA)
- Call Park/Pickup
- Do Not Disturb (DND)
- Call Completion to Busy Signal/Call Completion on No Reply
More details are on the charter page. These are just the initial four issues chosen to be addressed and Internet-Draft documents are already circulating on…
-
/
So who will be first vendor to implement VoIP over RFC4824?
Continue Reading: So who will be first vendor to implement VoIP over RFC4824?So with the release yesterday of RFC4824, The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS), one has to wonder… which of the vendors will be the first to attempt to implement VoIP transmission in this medium? I think it would make for a rather slower conversation, but it would certainly be intriguing. Hmmm… I wonder which would be faster – this method? Or the avian method defined in RFC2549. Probably this one, methinks.
Oh, you have to love a standards body with a sense of humor…
Technorati tags: ietf, rfc4824, semaphore, voip
