Thursday, July 25, 2013

WebRTC: sipML5, Asterisk and Chrome

I got a quick WebRTC setup working. I used the sipML5 demo setup, so I was not required to do any Javascript coding. Mostly it was simple config of Asterisk, Apache, and a soft phone.

I followed these two guides:

https://wiki.asterisk.org/wiki/display/AST/Asterisk+WebRTC+Support
http://highsecurity.blogspot.com/2012/12/webrtc-and-asterisk-11-using-sipml5.html

I got audio calls working between Chrome (using a webpage with sipML5) and a soft-phone, and between two Chromes (Windows and Mac).
But there were some problems: one way audio, or no audio after been put on hold, etc.

There are some limitations to this setup:
  • Chrome only supports G711
  • sipML5 does seem to do some transcoding, but I am not sure in which scenarios
  • Asterisk does not support the VP8 video codec
  • I think some of the no-audio calls was caused by some SRTP issues (errors thrown on Asterisk CLI)
I think this is how it works:
  • The browser talks to the sipML5 media stack
  • simML5 talks SIP over Websocket to the built-in Asterisk HTTP server
  • Asterisk then talks normal SIP to any soft-phones


This is how an INVITE looks from simML5 towards Asterisk:

INVITE sip:8000@10.1.43.131 SIP/2.0

Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKp6HJtQdMMTDMPbySBk9LTU3eskrWXPu4;rport
From: "Yusuf"<sip:8001@10.1.43.131>;tag=0hwykfSs3NexZBU8tdJW
To: <sip:8000@10.1.43.131>
Contact: "Yusuf"<sip:8001@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"
Call-ID: 1fd37734-e224-993d-0e39-4a9d0a29249d
CSeq: 64283 INVITE
Content-Type: application/sdp
Content-Length: 2055
Max-Forwards: 70
User-Agent: IM-client/OMA1.0 sipML5-v1.2013.07.17
Organization: Doubango Telecom

v=0
o=- 5377262258022282000 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUK
m=audio 35291 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 196.14.169.11
a=rtcp:35291 IN IP4 196.14.169.11
a=candidate:221728540 1 udp 2113937151 10.1.43.131 55639 typ host generation 0
a=candidate:221728540 2 udp 2113937151 10.1.43.131 55639 typ host generation 0
a=candidate:2999745851 1 udp 2113937151 192.168.56.1 55640 typ host generation 0
a=candidate:2999745851 2 udp 2113937151 192.168.56.1 55640 typ host generation 0
a=candidate:2758328521 1 udp 1845501695 196.14.169.11 35291 typ srflx raddr 10.1.43.131 rport 55639 generation 0
a=candidate:2758328521 2 udp 1845501695 196.14.169.11 35291 typ srflx raddr 10.1.43.131 rport 55639 generation 0
a=candidate:1135916012 1 tcp 1509957375 10.1.43.131 0 typ host generation 0
a=candidate:1135916012 2 tcp 1509957375 10.1.43.131 0 typ host generation 0
a=candidate:4233069003 1 tcp 1509957375 192.168.56.1 0 typ host generation 0
a=candidate:4233069003 2 tcp 1509957375 192.168.56.1 0 typ host generation 0
a=ice-ufrag:ENpcn07bboX2FSNu
a=ice-pwd:R+IH3MlQbkh8eW5RO2Mux7GM
a=ice-options:google-ice
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:KAECDDgcHP+us1cLDMQnMU7r7tPUGp20csN2YXpx
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ZcVN+IBStqIqojpkJ9yHcw7lsz/w0zniMfyqg8LH
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:2411427001 cname:0uphoIzFFc4tBBDf
a=ssrc:2411427001 msid:akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUK akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUKa0
a=ssrc:2411427001 mslabel:akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUK
a=ssrc:2411427001 label:akLep2Ro5PJZMHZbFqARiPlU485AHVNwnnUKa0

Whats interesting is that you wont see this on the wire. Because websockets serves as a transport for SIP, you only seen an initial HTTP Upgrade request.

GET /ws HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 10.1.43.133:8088
Origin: http://10.1.43.133
Sec-WebSocket-Protocol: sip
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: JMjC0QBuN4z9XHAR4JWfHA==
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: x-webkit-deflate-frame
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36
Cookie: __utma=96741151.1671289293.1374742717.1374742717.1374745812.2; __utmc=96741151; __utmz=96741151.1374742717.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)


No comments: