[reSIProcate] webrtc/websocket branch test results
I've now had a chance to run some tests using sipml5, a webrtc
Javascript client running in a Chrome browser, against the b-webrtc
branch (r9980)
a) repro appears to struggle with the unusual domain in the Via header.
The sipml5 client inserts the hostname df7jal23ls0d.invalid in the Via
header. Hacking Tuple.cxx a little bit (see patch at bottom) got me
past this
INVITE sip:1004@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx SIP/2.0
Via: SIP/2.0/WS
df7jal23ls0d.invalid;branch=z9hG4bKHX0A65ARCtLsQ1XQKAzAU7IvRuydwnTV;rport=51523;received=192.168.1.114
Max-Forwards: 70
Route:
<sip:srv1.office.readytechnology.co.uk:5060;lr;sipml5-outbound;transport=tcp>
Contact:
<sip:1005@df7jal23ls0d.invalid;rtcweb-breaker=no;transport=ws>;+g.oma.sip-im;+sip.ice;language="en,fr"
b) sipml5 can register successfully using WS (WSS is not fully
implemented yet) and I see the user in the web UI
c) calling from a regular client (e.g. on TCP) back to the sipml5
client: repro tries to do DNS lookups on df7jal23ls0d.invalid, this
fails, it rejects the call. It needs to behave as if using Outbound,
and send the INVITE to the client using the existing WS connection.
d) calling from the sipml5 client to 4 other SIP clients was
unsuccessful, but repro was not at fault. repro correctly passes the
INVITE to the destination. However, I observed the following:
- the Polycom IP321 reboots itself when it sees the INVITE from sipml5
(a useful party trick for SIPit next week?)
- Jitsi rings, but when I answer, it complains politely about no valid media
- Lumicall has an exception in Codecs.java
- Empathy rejects the INVITE
To summarise, I think there is more work to be done in reSIProcate to
integrate this feature, but there is also work to be done to find a
suitable peer that can accept calls from the WebRTC user.
Here is a sample INVITE from sipml5 proxied by repro:
INVITE sip:1004@192.168.1.124:50417;transport=tls SIP/2.0
Via: SIP/2.0/TLS
192.168.1.2:5061;branch=z9hG4bK-524287-1---98996e3a6022990d;rport
Via: SIP/2.0/TCP
192.168.1.114:51523;branch=z9hG4bKHX0A65ARCtLsQ1XQKAzAU7IvRuydwnTV;rport=51523;received=192.168.1.114
Max-Forwards: 69
Record-Route:
<sip:KQAAAAIAAAAQAeWcwKgBfDE1YTZmZTY1NThkMGRjYzkwYjllMTlkMTkyMDM5ZTMx@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;transport=tls;lr;drr>
Record-Route: <sip:192.168.1.2:5062;transport=ws;lr;drr>
Contact:
<sip:1005@192.168.1.2:5061;transport=tls;ws-src-ip=192.168.1.114;ws-src-port=51523;rtcweb-breaker=no>;language="en,fr";+g.oma.sip-im;+sip.ice
To: <sip:1004@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
From: <sip:1005@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>;tag=7ON5gByNVoJWrFD94GZw
Call-ID: 104a99ed-fd36-4f22-0f3c-5552d419dbde
CSeq: 61935 INVITE
Content-Type: application/sdp
Organization: Doubango Telecom
User-Agent: IM-client/OMA1.0 sipML5-v1.2013.02.13
Content-Length: 1617
v=0
o=- 3002941421 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS qh0sXeOMFjIIP2EkLfueSjXSjSqza4HCFJFR
m=audio 58216 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126
c=IN IP4 213.x.y.z
a=rtcp:58216 IN IP4 213.144.156.34
a=candidate:27784895 1 udp 2113937151 192.168.1.114 58216 typ host
generation 0
a=candidate:27784895 2 udp 2113937151 192.168.1.114 58216 typ host
generation 0
a=candidate:2163208203 1 udp 1845501695 213..x.y.z 58216 typ srflx raddr
192.168.1.114 rport 58216 generation 0
a=candidate:2163208203 2 udp 1845501695 213.x.y.z 58216 typ srflx raddr
192.168.1.114 rport 58216 generation 0
a=candidate:1327761999 1 tcp 1509957375 192.168.1.114 52655 typ host
generation 0
a=candidate:1327761999 2 tcp 1509957375 192.168.1.114 52655 typ host
generation 0
a=ice-ufrag:8Rnzc0WYnIaNWBJg
a=ice-pwd:W3AJ4kJXEaWuuTLC/EC4pqe8
a=ice-options:google-ice
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32
inline:5dI4ZdZIAGBBkwILexFm2VfcyfIwvyiOMh5Tlr7+
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:L78xfrqO3Uq1UlRNtiv4BNHpCjNWlhBT/J1gOjss
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:111 opus/48000/2
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=ssrc:1179996796 cname:XsAYZ4+TD6OfBvLh
a=ssrc:1179996796 msid:qh0sXeOMFjIIP2EkLfueSjXSjSqza4HCFJFR a0
a=ssrc:1179996796 mslabel:qh0sXeOMFjIIP2EkLfueSjXSjSqza4HCFJFR
a=ssrc:1179996796 label:qh0sXeOMFjIIP2EkLfueSjXSjSqza4HCFJFRa0
and here is the hacked Tuple.cxx:
Index: resip/stack/Tuple.cxx
===================================================================
--- resip/stack/Tuple.cxx (revision 9980)
+++ resip/stack/Tuple.cxx (working copy)
@@ -114,6 +114,8 @@
mTransportType(ptype),
mTargetDomain(targetDomain)
{
+ if(mTransportType == UNKNOWN_TRANSPORT)
+ return;
if (DnsUtil::isIpV4Address(printableAddr))
{
memset(&m_anonv4, 0, sizeof(m_anonv4));
@@ -487,7 +489,9 @@
bool
Tuple::isPrivateAddress() const
{
- if(ipVersion()==V4)
+ if(mTransportType == UNKNOWN_TRANSPORT)
+ return true;
+ else if(ipVersion()==V4)
{
// RFC 1918
return isEqualWithMask(v4privateaddrbase1,8,true,true) || //
10.0.0.0 - 10.255.255.255 (10/8 prefix)