Skip to content

VXML

Advertisements

Cisco H.264 Video Endpoint Calls Firefox Browser via WebRTC

Cisco and Mozilla want to make sure everyone knows H.264 is on the WebRTC support list. The two companies jointly demonstrated a straight-line video call between a WebRTC application and Cisco H.264 video hardware endpoint at the Cisco Collaboration Summit this week.   While purists might not like it, the collaboration opens up a wider world of business video interoperability.

H.264 for video is like G.722 for audio within the enterprise – an old standard built into just about every piece of hardware.  You can find H.264 in numerous desktop phones  with video camera to high-end telepresence systems.

The Cisco-Mozilla demonstration used a SIP URI and a Cisco video endpoint to call a Cisco Project Squared client running in Mozilla Firefox.  The Firefox browser has Cisco’s OpenH264 binary model integrated into it, enabling the desktop browser to communicate with the (arguably legacy) Cisco hardware using WebRTC without having to use additional browser plug-ins, additional downloads, or transcoding gear for different video formats.

Efforts to get H.264 compatibility into WebRTC started a year ago, with Cisco open sourcing its H.264 implementation and offering a binary model that companies and developers could integrate into their products. Last month, Cisco worked with Mozilla to get the H.264 binary model into Firefox.

WebRTC purists have tried to stick with VP8 as the mandatory video codec, but enterprise-focused vendors such as Cisco and Microsoft saw the need to support H.264 for the business world.   Companies can now use their existing base of H.264 hardware to seamlessly communicate and collaborate with any WebRTC client or service.

Cisco has already built a service, Project Squared, around WebRTC , to provide a fully featured communications experience.   Teams can post messages, share content and conduct video calling from any Android, Apple iOS, Macintosh or PC .  Mozilla is adding the Hello service to Firefox, enabling people to put up contact lists and make WebRTC voice and video calls directly, with TokBox providing the back-end server support.

The Cisco-Mozilla announcement comes on the heels of Microsoft’s rush to embrace WebRTC and rename everything communication-enabled as Skype.  At the end of October, Microsoft announced it was rolling WebRTC into Internet Explorer (IE).  Earlier this week, the beta of Skype for Web was released, enabling Skype voice and video calls directly from a web page.  Everything will be linked together using WebRTC, including the newly re-branded Microsoft Lync, now known as Skype for Business.

Two companies are losing ground with the latest WebRTC announcements.  Apple is on its usual slow-boat to support WebRTC some day, but by the time it gets around to it, Microsoft will once again have locked up the enterprise space.    Polycom may have more significant concerns.  Cisco has played a leadership role in supporting H.264 for WebRTC and likely has more extensive products and services in the works.  Polycom doesn’t have a compelling story to tell around WebRTC at this point in time, other than “let’s wait until the hype dies down” and “We’re working on WebRTC bits and piece within the enterprise.”

The next twelve months are going to be critical for  the WebRTC community.  New powers will rise, and old empires will fall.  Acquisition-hungry Mitel is probably shopping for a WebRTC company and who knows what deals are being discussed in smoke-filled rooms.  It’s going to be fun to watch.

SIP Normalization for ITSP Internetworking Using Cisco Unified Border Element (CUBE)

At its base, CUBE consists of allowing both inbound and outbound call legs to be of the type VoIP. Here we first explore a very basic configuration where we have 2 Inbound/Outbound Dial-Peers (depending on which direction the call originates from) To/From the CUCMs in the cluster, and 2 Inbound/Outbound Dial-Peers To/From a fictional AT&T SIP ITSP trunk. We are allowing a codec negotiation and also possibly a DTMF relay internetworking between CUBE  and the CUCMs on Dial-Peer’s 101 & 102 (we needed both of these for another utility on this router using the SIP stack), while allowing for the codec of G.729 Annex B on the AT&T carrier side in Dial-Peers 1001 & 1002. We are also load balancing calls between both of the CUCM Subscriber servers and also between both of the SBCs on AT&T’s side that they have given us to peer with. We see this here:

!
ip domain retry 0
ip domain timeout 2
ip domain name ine.com
ip name-server 177.1.100.110
!
voice service voip
 address-hiding
 allow-connections sip to sip
 redirect ip2ip
 sip
  bind control source-interface Loopback0
  bind media source-interface Loopback0
  header-passing error-passthru
  midcall-signaling passthru
  g729 annexb-all
!
voice class codec 1
 codec preference 1 g711ulaw
 codec preference 2 g729r8
!
!
dial-peer voice 101 voip
 description ** TO/FROM CUCM SUBSCRIBER 1 **
 destination-pattern 2065011...$
 voice-class codec 1
 session protocol sipv2
 session target ipv4:177.1.10.20
 incoming called-number .
 dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 102 voip
 description ** TO/FROM CUCM SUBSCRIBER 2 **
 destination-pattern 2065011...$
 voice-class codec 1
 session protocol sipv2
 session target ipv4:177.1.10.25
 dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 1001 voip
 description ** TO/FROM SIP ITSP - AT&T SBC 1 **
 destination-pattern +T
 voice-class sip localhost dns:corphqr1.ine.com
 session protocol sipv2
 session target dns:sip1.att.com
 incoming called-number 2065011...$
 dtmf-relay rtp-nte
 codec g729br8
!
dial-peer voice 1002 voip
 description ** TO/FROM SIP ITSP - AT&T SBC 2 **
 destination-pattern +T
 voice-class sip localhost dns:corphqr1.ine.com
 session protocol sipv2
 session target dns:sip2.att.com
 incoming called-number 2065011...$
 dtmf-relay rtp-nte
 codec g729br8
!
dial-peer hunt 1
!
!
voice service voip
allow-connections sip to sip
sip
bind control source-interface Loopback0
bind media source-interface Loopback0
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
!
dial-peer voice 101 voip
description ** TO/FROM CUCM SUBSCRIBER **
destination-pattern 2065011…$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.20
incoming called-number .
dtmf-relay frtp-nte
!
dial-peer voice 102 voip
description ** TO/FROM CUCM PUBLISHER **
preference 1
destination-pattern 2065011…$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.10
dtmf-relay rtp-nte
!
dial-peer voice 1001 voip
description ** TO/FROM SIP ITSP – AT&T SBC 1 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip1.att.com
incoming called-number 2065011…$
dtmf-relay rtp-nte
!
dial-peer voice 1002 voip
description ** TO/FROM SIP ITSP – AT&T SBC 1 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip2.att.com
incoming called-number 2065011…$
dtmf-relay rtp-nte
!
dial-peer hunt 1

Now what if we have a carrier who wants to see our specific domain name (ine.com) after the @ in the Contact header of a SIP INVITE request message (so 2065011001@ine.com   vs.   2065011001@177.1.254.1), possibly for something like compliance with SIP Asserted-Identity? Let’s look at what the SIP INVITE might look like prior to any modification to the above configuration:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@177.1.254.1:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20
So what can CUBE do about this? CUBE can alter the contents of any header in any SIP or SDL header of any request or response (SDL or “Session Description Language” is where things like media, DTMF relay, etc are negotiated – you see a SDL sub-component of the above SIP INVITE  message – which is known as a “SIP Early Offer”). So let’s tell CUBE to alter that Contact header of that particular INVITE message, but only out to AT&T. As a preface to our configuration example, it is worth noting that SIP Profiles allow for pattern matching and replacement in a similar (but not exact) method to that of Voice Translation Rules, and like them, are based (loosely) on the GNU SED stream editor. We will use this to match and replace a few possible dynamic values of the string. Like Voice Translation Rules, reference “sets” of matched information in the replacement string with \1 which calls Set 1 from the matched pattern to the replacement pattern. Also like Voice Translation Rules, any part of the string (beginning or end) that we don’t match, passes through to the replacement pattern, unaltered.
!
voice class sip-profiles 1
 request INVITE sip-header Contact modify "<sip:(.*)@(.*):5060>" "<sip:\1@ine.com:5060>"
!
dial-peer voice 1001 voip
 voice-class sip profiles 1
!
dial-peer voice 1002 voip
 voice-class sip profiles 1
!

Now let’s take a look at what that did to the contents of our Contact header in a new call, and thus a new SIP INVITE message that we send out to AT&T:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@ine.com:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20

Excellent! It did exactly what we asked it to!

%d bloggers like this: