Bug 29785

Summary:	Video calls fail using SIP protocol with telepathy-sofiasip
Product:	Telepathy	Reporter:	Chris Vine <vine35792468>
Component:	rakia	Assignee:	Mikhail Zabaluev <mikhail.zabaluev>
Status:	RESOLVED MOVED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium
Version:	0.6
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Debug output from the caller Debug output from the recipient Sofiasip debug output from caller Sofiasip debug output from recipient

Description Chris Vine 2010-08-24 11:52:13 UTC

Video chat works fine for me using telepathy with the the XMPP protocol (say, via the google servers) using the empathy client with telepathy-gabble, both with empathy to empathy, and empathy to google talk browser plugin.

However, although audio chat works between SIP accounts using empathy with telepathy-sofiasip, if video chat is chosen, the calling client appears to close the connection as soon as the connection is made.  I have tested on two different sip accounts using empathy to empathy, and empathy to linphone.  Video on these sip accounts is supported and works fine if the connection is made with linphone as the client at both ends.

If an audio connection is first made (successfully) between SIP accounts using empathy, and then video chat is chosen subsequently on the open connection, the same thing happens: the calling client appears to close the connection as soon as a video connection is made.

Both machines have the following installed:

empathy 2.30.2 with gnome-2.30.2
farsight2-0.0.21
libnice-0.0.13
sofia-sip-1.12.10
telepathy-python-0.15.18
pycrypto-2.1.0
pyOpenSSL-0.10
telepathy-glib-0.10.7
telepathy-farsight-0.0.14
telepathy-mission-control-5.4.3
telepathy-gabble-0.8.14
telepathy-sofiasip-0.6.3

I attach separately the empathy debug logs of a video chat attempt both from the caller and recipient, both using telepathy-sofiasip.

Comment 1 Chris Vine 2010-08-24 11:53:35 UTC

Created attachment 38128 [details]
Debug output from the caller

Comment 2 Chris Vine 2010-08-24 11:54:31 UTC

Created attachment 38129 [details]
Debug output from the recipient

Comment 3 Mikhail Zabaluev 2010-08-27 03:32:19 UTC

Can you paste the contents of 'sofiasip' debug output?

What are the SIP account parameters? Try to set transport to TCP or UDP, if it's set to Auto.

Comment 4 Chris Vine 2010-08-28 02:23:53 UTC

The transport protocol was set as 'Auto'.

I won't be able to test again by setting it explicitly to UDP for about a week, nor obtain additional debugging output until then.  But how do you capture sofiasip debug output that wasn't in the output that I have already attached?

Comment 5 Mikhail Zabaluev 2010-08-30 05:59:11 UTC

(In reply to comment #4)
> The transport protocol was set as 'Auto'.
> 
> I won't be able to test again by setting it explicitly to UDP for about a week,
> nor obtain additional debugging output until then.  But how do you capture
> sofiasip debug output that wasn't in the output that I have already attached?

There is a selection box on top of the debug window. "sofiasip" logs are available as another choice in that selection.

Comment 6 Chris Vine 2010-09-10 02:32:55 UTC

If I set UDP as the transport medium, the problem remains.

I will attach the sofiasip debug output.

Comment 7 Chris Vine 2010-09-10 02:35:35 UTC

Created attachment 38597 [details]
Sofiasip debug output from caller

Comment 8 Chris Vine 2010-09-10 02:36:22 UTC

Created attachment 38598 [details]
Sofiasip debug output from recipient

Comment 9 Mikhail Zabaluev 2010-09-10 03:33:03 UTC

(In reply to comment #7)
> Created an attachment (id=38597) [details]
> Sofiasip debug output from caller

Thanks. The fatal event for the caller is:

tpsip/events-DEBUG: 10/09/10 10:19:22.966525: tpsip_connection_sofia_callback: event nua_r_invite: 513 Message too big

Now I'm interested to look at the SIP traffic. It might be that the SDP description of available codecs together with SIP headers exceeds the packet size limit at some point.
It may be related to bug #20135. Another thing to improve in the code is to avoid sending the whole set of supported codecs in the session answer, sending rather the intersected codecs (this also helps interoperability). But this doesn't help in outbound call case.

Does it work with TCP or TLS, however?

Comment 10 Chris Vine 2010-09-14 03:12:04 UTC

TCP doesn't work.  It fails in the same way as with UDP, and the sender log contains the following:

tpsip/events-DEBUG: 14/09/10 11:05:25.759294: tpsip_connection_sofia_callback: event nua_r_invite: 513 Message too big
tpsip/events-DEBUG: 14/09/10 11:05:25.762049: tpsip_connection_sofia_callback: event nua_i_state: 513 Message too big

I can attach the full sofiasip debug log if that helps, although my guess is that it doesn't.

I cannot test TLS as the sip server does not support it.

Comment 11 GitLab Migration User 2019-12-03 19:36:52 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-rakia/issues/10.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.