search

sipsorcery-org / sipsorcery

A WebRTC, SIP and VoIP library for C# and .NET. Designed for real-time communications apps.
https://sipsorcery-org.github.io/sipsorcery
Other
1.45k stars 440 forks source link

Potential incompatibility with the way Cisco Webex expects SIP Invites #60

Closed KallDrexx closed 6 years ago

KallDrexx commented 6 years ago

I'm trying to use SipSorcery to connect (as a guest) to a Cisco Webex video conference (I'm intending to capture video/audio with ffmpeg or gstreamer so the lack of codec support in SipSorcery is not a concern). In webex I got my SIp address of xxxx@meet.ciscospark.com. So I wrote the following code:

        public static void Main(string[] args)
        {
            var address = STUNClient.GetPublicIPAddress("stun.ideasip.com");
            var sipUri = new SIPURI("xxxx", "meet.ciscospark.com", "", SIPSchemesEnum.sips, SIPProtocolsEnum.tls);

            var sipTransport = new SIPTransport(SIPDNSManager.ResolveSIPService, new SIPTransactionEngine());
            sipTransport.SIPTransportRequestReceived += SIPRequestReceived;
            sipTransport.SIPTransportResponseReceived += SIPResponseReceived;
            sipTransport.SIPRequestOutTraceEvent += SipTransportOnSipRequestOutTraceEvent;
            sipTransport.SIPResponseInTraceEvent += SipTransportOnSipResponseInTraceEvent;

            var cert = GenerateCertificate("test");
            SIPTLSChannel tlsChannel = new SIPTLSChannel(cert, new IPEndPoint(IPAddress.Any, 5061));
            sipTransport.AddSIPChannel(tlsChannel);

            var fromHeader = new SIPFromHeader("test", SIPURI.ParseSIPURI(SIPFromHeader.DEFAULT_FROM_URI), null).ToString();
            var userAgent = new SIPClientUserAgent(sipTransport, null, null, null, null);
            var sdp = GenerateSDP();
            var callDescriptor = new SIPCallDescriptor("test",
                null,
                sipUri.ToString(),
                fromHeader,
                null,
                null,
                null,
                null,
                SIPCallDirection.Out,
                "application/sdp",
                sdp,
                null);

            userAgent.Call(callDescriptor);
        }

With this I get the following output:

2018-06-07 12:11:22,225 [1] DEBUG sipsorcery [(null)] - Logging initialised.
2018-06-07 12:11:22,400 [1] DEBUG sipsorcery [(null)] - STUNClient attempting to determine public IP from stun.ideasip.com.
2018-06-07 12:11:22,607 [3] DEBUG sipsorcery [(null)] - STUNClient Response to initial STUN message received from 217.10.68.152:3478.
2018-06-07 12:11:22,614 [3] DEBUG sipsorcery [(null)] - STUNClient Public IP=199.26.74.234.
2018-06-07 12:11:23,242 [1] DEBUG siptls-channel [(null)] - SIP TLS Channel listener created 0.0.0.0:5061.
2018-06-07 12:11:23,258 [siptls-5061] DEBUG siptls-channel [(null)] - SIPTLSChannel socket on tls:0.0.0.0:5061 accept connections thread started.
2018-06-07 12:11:23,584 [1] DEBUG dnslookup [(null)] - Initialising DNS resolver with operating system DNS server entries.
2018-06-07 12:11:23,615 [1] DEBUG dnslookup [(null)] - DNSManager lookup queued for SRV _sips._tcp.meet.ciscospark.com, queue size=1, in progress=1.
2018-06-07 12:11:23,616 [dnslookup-2] DEBUG dnslookup [(null)] - DNSManager thread dnslookup-2 looking up SRV _sips._tcp.meet.ciscospark.com.
2018-06-07 12:11:23,620 [dnslookup-2] DEBUG sipsorcery [(null)] - Resolver sending UDP DNS request to 8.8.8.8:53 for SRV _sips._tcp.meet.ciscospark.com..
2018-06-07 12:11:23,691 [dnslookup-2] DEBUG sipsorcery [(null)] - Caching DNS lookup success for IN-SRV-_sips._tcp.meet.ciscospark.com..
2018-06-07 12:11:23,692 [dnslookup-2] DEBUG dnslookup [(null)] - DNSManager resolve time for _sips._tcp.meet.ciscospark.com SRV 75.9838ms.
2018-06-07 12:11:23,694 [dnslookup-2] DEBUG dnslookup [(null)] -  result: priority=5, weight=10, port=5061, target=l2sip-cfa-01.wbx2.com..
2018-06-07 12:11:23,695 [dnslookup-2] DEBUG dnslookup [(null)] -  result: priority=5, weight=10, port=5061, target=l2sip-cfa-02.wbx2.com..
2018-06-07 12:11:23,709 [1] DEBUG dnslookup [(null)] - DNSManager lookup queued for A l2sip-cfa-01.wbx2.com., queue size=1, in progress=1.
2018-06-07 12:11:23,710 [dnslookup-1] DEBUG dnslookup [(null)] - DNSManager thread dnslookup-1 looking up A l2sip-cfa-01.wbx2.com..
2018-06-07 12:11:23,712 [dnslookup-1] DEBUG sipsorcery [(null)] - Resolver sending UDP DNS request to 8.8.8.8:53 for A l2sip-cfa-01.wbx2.com..
2018-06-07 12:11:23,754 [dnslookup-1] DEBUG sipsorcery [(null)] - Caching DNS lookup success for IN-A-l2sip-cfa-01.wbx2.com..
2018-06-07 12:11:23,756 [dnslookup-1] DEBUG dnslookup [(null)] - DNSManager resolved A record for l2sip-cfa-01.wbx2.com. to 13.59.223.3 in 45.997ms.
2018-06-07 12:11:23,818 [1] DEBUG siptls-channel [(null)] - Attempting to establish TLS connection to 13.59.223.3:5061.
Sending sip message:
INVITE sips:xxxx@meet.ciscospark.com;transport=tls SIP/2.0
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport
To: <sips:xxxx@meet.ciscospark.com>;transport=tls
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 INVITE
Contact: <sips:test@0.0.0.0:5061;transport=tls>
Max-Forwards: 70
User-Agent: www.sipsorcery.com
Content-Length: 157
Content-Type: application/sdp

v=0
o=-
s=-
t=0 0
c=IN IP4 199.26.74.234
m=audio 12688 RTP/AVP 97
a=rtpmap:97 MPEG4-GENERIC/44100/2
m=video 12666 RTP/AVP 96
a=rtpmap:96 H264/90000

2018-06-07 12:11:24,079 [4] WARN  siptls-channel [(null)] - Certificate error: RemoteCertificateNameMismatch
2018-06-07 12:11:24,092 [4] DEBUG siptls-channel [(null)] - Established TLS connection to 13.59.223.3:5061.
Sending sip message:
INVITE sips:xxxx@meet.ciscospark.com;transport=tls SIP/2.0
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport
To: <sips:xxxx@meet.ciscospark.com>;transport=tls
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 INVITE
Contact: <sips:test@0.0.0.0:5061;transport=tls>
Max-Forwards: 70
User-Agent: www.sipsorcery.com
Content-Length: 157
Content-Type: application/sdp

v=0
o=-
s=-
t=0 0
c=IN IP4 199.26.74.234
m=audio 12688 RTP/AVP 97
a=rtpmap:97 MPEG4-GENERIC/44100/2
m=video 12666 RTP/AVP 96
a=rtpmap:96 H264/90000

Received sip response:
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport=60434;received=172.18.218.134
To: <sips:xxxx@meet.ciscospark.com>;transport=tls
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 INVITE
Content-Length: 0

Received sip response:
SIP/2.0 503 Service unavailable
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport=60434;received=172.18.218.134
To: <sips:xxxx@meet.ciscospark.com>;transport=tls;tag=521921318
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 INVITE
Retry-After: 2
Content-Length: 0
Reason: http;cause=0;text="Request timed-out accessing Locus service: Read timed out"

Sending sip message:
ACK sips:xxxx@meet.ciscospark.com;transport=tls SIP/2.0
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport
To: <sips:xxxx@meet.ciscospark.com>;transport=tls;tag=521921318
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0

Received sip response:
SIP/2.0 503 Service unavailable
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport=60434;received=172.18.218.134
To: <sips:xxxx@meet.ciscospark.com>;transport=tls;tag=521921318
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 INVITE
Retry-After: 2
Content-Length: 0
Reason: http;cause=0;text="Request timed-out accessing Locus service: Read timed out"

Sending sip message:
ACK sips:xxxx@meet.ciscospark.com;transport=tls SIP/2.0
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport
To: <sips:xxxx@meet.ciscospark.com>;transport=tls;tag=521921318
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0

Received sip response:
SIP/2.0 481 call or transaction does not exist
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport=60434;received=172.18.218.134
To: <sips:xxxx@meet.ciscospark.com>;transport=tls;tag=521921318
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 ACK
Content-Length: 0

SIP response received from tcp:13.59.223.3:5061.
SIP/2.0 481 call or transaction does not exist
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport=60434;received=172.18.218.134
To: <sips:xxxx@meet.ciscospark.com>;transport=tls;tag=521921318
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 ACK
Content-Length: 0

Received sip response:
SIP/2.0 481 call or transaction does not exist
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport=60434;received=172.18.218.134
To: <sips:xxxx@meet.ciscospark.com>;transport=tls;tag=521921318
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 ACK
Content-Length: 0

SIP response received from tcp:13.59.223.3:5061.
SIP/2.0 481 call or transaction does not exist
Via: SIP/2.0/TLS 0.0.0.0:5061;branch=z9hG4bKbe4d35839576456d9af0df1ef19cfe7a;rport=60434;received=172.18.218.134
To: <sips:xxxx@meet.ciscospark.com>;transport=tls;tag=521921318
From: "test" <sip:thisis@anonymous.invalid>;tag=CNPYRUXCTX
Call-ID: e7e3611aff604397a66e03d6b1e4f61c
CSeq: 1 ACK
Content-Length: 0

Normally I'd say it's a bug on Webex side because of the 503 (I'm assuming the Locus service it is referencing is an internal service of theirs). However, I am able to connect with 3rd party sip clients as well as the Python Simple Sip SDK (I haven't been able to get a python environment set up enough to fully understand what it's doing differently).

It seems like there is something off in the way that SipSorcery is performing SIP invites compared to others, but I can't for the life of me figure out what (custom SIP messages I've written are giving the same, and since Webex only uses TLS I can't just do a wireshark capture to figure it out).

Just wanted to bring it to your attention as you are much more knowledgeable in SIP than I.

(I assume the ACK response errors are just because it's not expecting an ACK when a 5xx is returned).

KallDrexx commented 6 years ago

Nevermind, the issue ended up being the SDP being used for whatever reason, nothing to do with SipSorcery.