Bug 591261 – SIP negociation to echo test timeout after resending INVITE with authentication

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 591261 - SIP negociation to echo test timeout after resending INVITE with authentication


Summary:	SIP negociation to echo test timeout after resending INVITE with authentication


Status:	RESOLVED OBSOLETE

Product:	ekiga
Classification:	Applications
Component:	general
Version:	3.2.x
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	---
Assigned To:	Ekiga maintainers
QA Contact:	Ekiga maintainers

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2009-08-09 20:53 UTC by Yannick
Modified:	2013-05-07 11:46 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Yannick 2009-08-09 20:53:38 UTC

Hi,

Downstream bug:
https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/411102

The issue is with the negotiation when calling the echo test: the INVITE timeout after resending with authentication information.
2009/08/09 21:45:09.165 0:25.714 Housekeeper:0xcf05f950 SIP Transaction 2 INVITE timeout, making retry 1

-d 4:
http://launchpadlibrarian.net/30087660/output.txt


I do not find the reason of this failure. I see 2 weird things here:
* Ekiga use a private IP:
SIP/2.0 200 OK
CSeq: 2 REGISTER
Via: SIP/2.0/UDP 172.19.3.200:5060
Still registration works. I though Ekiga.net do not accept private IP.

* The PDU might be the reason for the timeout (as INVITE with authentification is the larger PDU of this output), but:
2009/08/09 21:45:08.664	  0:25.212	  Aggregator:0xc76d8950	SIP	Sending PDU (1381 bytes) to: rem=udp$86.64.162.35:5060,local=udp$172.19.3.200:5060,if=172.19.3.200%eth0

The PDU is 1381. I'm aware of some network having smaller PDU than 1500, and the standard ask to not use UDP if PDU is above 1300.

I'm waiting Damien's expertise. ;)

Best regards,
Yannick

Comment 1 tom schorpp 2010-05-20 01:20:42 UTC

hi yannick, CONFIRM, ekiga 3.2.6 is unusable to me with this bug,
tried 2 stun servers, timeout happens with every SIP-provider/proxy:


02:50:25.532796 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 30)
    tom1.sip > ekiga.net.sip: SIP, length: 2
	
	
02:50:25.533185 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 30)
    tom1.sip > ekiga.net.sip: SIP, length: 2
	
	
02:50:30.072097 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 1361)
    tom1.sip > ekiga.net.sip: SIP, length: 1333
	INVITE sip:500@ekiga.net SIP/2.0
	Date: Thu, 20 May 2010 00:50:29 GMT
	CSeq: 1 INVITE
	Via: SIP/2.0/UDP 77.3.126.167:16074;branch=z9hG4bK9ab34c5b-1762-df11-8ffa-001109d76d6b;rport
	User-Agent: Ekiga/3.2.6
	From: "Tom1 Schorpp" <sip:schorpp@ekiga.net>;tag=50f0405b-1762-df11-8ffa-001109d76d6b
	Call-ID: f8f2405b-1762-df11-8ffa-001109d76d6b@tom1
	To: <sip:500@ekiga.net>
	Contact: <sip:schorpp@77.3.126.167:16074>
	Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
	Content-Type: application/sdp
	Content-Length: 769
	Max-Forwards: 70
	
	v=0
	o=- 1274316629 1 IN IP4 77.3.126.167
	s=Opal SIP Session
	c=IN IP4 77.3.126.167
	t=0 0
	m=audio 5094 RTP/AVP 8 116 115 0 105 104 103 102 3 9 101 120
	a=sendrecv
	a=rtpmap:8 PCMA/8000/1
	a=rtpmap:116 Speex/16000/1
	a=fmtp:116 sr=16000,mode=any
	a=rtpmap:115 Speex/8000/1
	a=fmtp:115 sr=8000,mode=any
	a=rtpmap:0 PCMU/8000/1
	a=rtpmap:105 G726-16/8000/1
	a=rtpmap:104 G726-24/8000/1
	a=rtpmap:103 G726-32/8000/1
	a=rtpmap:102 G726-40/8000/1
	a=rtpmap:3 gsm/8000/1
	a=rtpmap:9 G722/8000/1
	a=rtpmap:101 telephone-event/8000
	a=fmtp:101 0-16,32,36
	a=rtpmap:120 NSE/8000
	a=fmtp:120 192-193
	m=video 5096 RTP/AVP 119 31
	b=AS:4096
	b=TIAS:4096000
	a=sendrecv
	a=rtpmap:119 theora/90000
	a=fmtp:119 height=576;width=704
	a=rtpmap:31 h261/90000
	a=fmtp:31 CIF=1;QCIF=1
	
02:50:30.144232 IP (tos 0x0, ttl 51, id 0, offset 0, flags [DF], proto UDP (17), length 563)
    ekiga.net.sip > tom1.sip: SIP, length: 535
	SIP/2.0 407 Proxy Authentication Required
	CSeq: 1 INVITE
	Via: SIP/2.0/UDP 77.3.126.167:16074;branch=z9hG4bK9ab34c5b-1762-df11-8ffa-001109d76d6b;rport=16056
	From: "Tom1 Schorpp" <sip:schorpp@ekiga.net>;tag=50f0405b-1762-df11-8ffa-001109d76d6b
	Call-ID: f8f2405b-1762-df11-8ffa-001109d76d6b@tom1
	To: <sip:500@ekiga.net>;tag=c64e1f832a41ec1c1f4e5673ac5b80f6.a515
	Proxy-Authenticate: Digest realm="ekiga.net", nonce="4bf48774000184d785571b5f1a1692d77377d70b496f69d5"
	Server: Kamailio (1.5.3-notls (i386/linux))
	Content-Length: 0
	
	
02:50:30.147130 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 411)
    tom1.sip > ekiga.net.sip: SIP, length: 383
	ACK sip:500@ekiga.net SIP/2.0
	CSeq: 1 ACK
	Via: SIP/2.0/UDP 77.3.126.167:16074;branch=z9hG4bK9ab34c5b-1762-df11-8ffa-001109d76d6b;rport
	From: "Tom1 Schorpp" <sip:schorpp@ekiga.net>;tag=50f0405b-1762-df11-8ffa-001109d76d6b
	Call-ID: f8f2405b-1762-df11-8ffa-001109d76d6b@tom1
	To: <sip:500@ekiga.net>;tag=c64e1f832a41ec1c1f4e5673ac5b80f6.a515
	Content-Length: 0
	Max-Forwards: 70
	
	
02:50:30.230081 IP (tos 0x0, ttl 64, id 37058, offset 0, flags [+], proto UDP (17), length 1500)
    tom1.sip > ekiga.net.sip: SIP, length: 1472
	INVITE sip:500@ekiga.net SIP/2.0
	Date: Thu, 20 May 2010 00:50:30 GMT
	CSeq: 2 INVITE
	v: SIP/2.0/UDP 77.3.126.167:16074;branch=z9hG4bK60ee645b-1762-df11-8ffa-001109d76d6b;rport
	User-Agent: Ekiga/3.2.6
	f: "Tom1 Schorpp" <sip:schorpp@ekiga.net>;tag=50f0405b-1762-df11-8ffa-001109d76d6b
	i: f8f2405b-1762-df11-8ffa-001109d76d6b@tom1
	t: <sip:500@ekiga.net>
	m: <sip:schorpp@77.3.126.167:16074>
	Proxy-Authorization: Digest username="schorpp", realm="ekiga.net", nonce="4bf48774000184d785571b5f1a1692d77377d70b496f69d5", uri="sip:500@ekiga.net", algorithm=MD5, response="ce73f65915959f3aeeddaa1669858a18"
	Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
	c: application/sdp
	l: 769
	Max-Forwards: 70
	
	v=0
	o=- 1274316629 1 IN IP4 77.3.126.167
	s=Opal SIP Session
	c=IN IP4 77.3.126.167
	t=0 0
	m=audio 5094 RTP/AVP 8 116 115 0 105 104 103 102 3 9 101 120
	a=sendrecv
	a=rtpmap:8 PCMA/8000/1
	a=rtpmap:116 Speex/16000/1
	a=fmtp:116 sr=16000,mode=any
	a=rtpmap:115 Speex/8000/1
	a=fmtp:115 sr=8000,mode=any
	a=rtpmap:0 PCMU/8000/1
	a=rtpmap:105 G726-16/8000/1
	a=rtpmap:104 G726-24/8000/1
	a=rtpmap:103 G726-32/8000/1
	a=rtpmap:102 G726-40/8000/1
	a=rtpmap:3 gsm/8000/1
	a=rtpmap:9 G722/8000/1
	a=rtpmap:101 telephone-event/8000
	a=fmtp:101 0-16,32,36
	a=rtpmap:120 NSE/8000
	a=fmtp:120 192-193
	m=video 5096 RTP/AVP 119 31
	b=AS:4096
	b=TIAS:4096000
	a=sendrecv
	a=rtpmap:119 theora/90000
	a=fmtp:119 height=576;width=704
	a=rtpmap:31 h261/9[|sip]
02:50:30.737448 IP (tos 0x0, ttl 64, id 37059, offset 0, flags [+], proto UDP (17), length 1500)
    tom1.sip > ekiga.net.sip: SIP, length: 1472
	INVITE sip:500@ekiga.net SIP/2.0
	Date: Thu, 20 May 2010 00:50:30 GMT
	CSeq: 2 INVITE
	v: SIP/2.0/UDP 77.3.126.167:16074;branch=z9hG4bK60ee645b-1762-df11-8ffa-001109d76d6b;rport
	User-Agent: Ekiga/3.2.6
	f: "Tom1 Schorpp" <sip:schorpp@ekiga.net>;tag=50f0405b-1762-df11-8ffa-001109d76d6b
	i: f8f2405b-1762-df11-8ffa-001109d76d6b@tom1
	t: <sip:500@ekiga.net>
	m: <sip:schorpp@77.3.126.167:16074>
	Proxy-Authorization: Digest username="schorpp", realm="ekiga.net", nonce="4bf48774000184d785571b5f1a1692d77377d70b496f69d5", uri="sip:500@ekiga.net", algorithm=MD5, response="ce73f65915959f3aeeddaa1669858a18"
	Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
	c: application/sdp
	l: 769
	Max-Forwards: 70
	
	v=0
	o=- 1274316629 1 IN IP4 77.3.126.167
	s=Opal SIP Session
	c=IN IP4 77.3.126.167
	t=0 0
	m=audio 5094 RTP/AVP 8 116 115 0 105 104 103 102 3 9 101 120
	a=sendrecv
	a=rtpmap:8 PCMA/8000/1
	a=rtpmap:116 Speex/16000/1
	a=fmtp:116 sr=16000,mode=any
	a=rtpmap:115 Speex/8000/1
	a=fmtp:115 sr=8000,mode=any
	a=rtpmap:0 PCMU/8000/1
	a=rtpmap:105 G726-16/8000/1
	a=rtpmap:104 G726-24/8000/1
	a=rtpmap:103 G726-32/8000/1
	a=rtpmap:102 G726-40/8000/1
	a=rtpmap:3 gsm/8000/1
	a=rtpmap:9 G722/8000/1
	a=rtpmap:101 telephone-event/8000
	a=fmtp:101 0-16,32,36
	a=rtpmap:120 NSE/8000
	a=fmtp:120 192-193
	m=video 5096 RTP/AVP 119 31
	b=AS:4096
	b=TIAS:4096000
	a=sendrecv
	a=rtpmap:119 theora/90000
	a=fmtp:119 height=576;width=704
	a=rtpmap:31 h261/9[|sip]
02:50:31.739617 IP (tos 0x0, ttl 64, id 37060, offset 0, flags [+], proto UDP (17), length 1500)
    tom1.sip > ekiga.net.sip: SIP, length: 1472
	INVITE sip:500@ekiga.net SIP/2.0
	Date: Thu, 20 May 2010 00:50:30 GMT
	CSeq: 2 INVITE
	v: SIP/2.0/UDP 77.3.126.167:16074;branch=z9hG4bK60ee645b-1762-df11-8ffa-001109d76d6b;rport
	User-Agent: Ekiga/3.2.6
	f: "Tom1 Schorpp" <sip:schorpp@ekiga.net>;tag=50f0405b-1762-df11-8ffa-001109d76d6b
	i: f8f2405b-1762-df11-8ffa-001109d76d6b@tom1
	t: <sip:500@ekiga.net>
	m: <sip:schorpp@77.3.126.167:16074>
	Proxy-Authorization: Digest username="schorpp", realm="ekiga.net", nonce="4bf48774000184d785571b5f1a1692d77377d70b496f69d5", uri="sip:500@ekiga.net", algorithm=MD5, response="ce73f65915959f3aeeddaa1669858a18"
	Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
	c: application/sdp
	l: 769
	Max-Forwards: 70
	
	v=0
	o=- 1274316629 1 IN IP4 77.3.126.167
	s=Opal SIP Session
	c=IN IP4 77.3.126.167
	t=0 0
	m=audio 5094 RTP/AVP 8 116 115 0 105 104 103 102 3 9 101 120
	a=sendrecv
	a=rtpmap:8 PCMA/8000/1
	a=rtpmap:116 Speex/16000/1
	a=fmtp:116 sr=16000,mode=any
	a=rtpmap:115 Speex/8000/1
	a=fmtp:115 sr=8000,mode=any
	a=rtpmap:0 PCMU/8000/1
	a=rtpmap:105 G726-16/8000/1
	a=rtpmap:104 G726-24/8000/1
	a=rtpmap:103 G726-32/8000/1
	a=rtpmap:102 G726-40/8000/1
	a=rtpmap:3 gsm/8000/1
	a=rtpmap:9 G722/8000/1
	a=rtpmap:101 telephone-event/8000
	a=fmtp:101 0-16,32,36
	a=rtpmap:120 NSE/8000
	a=fmtp:120 192-193
	m=video 5096 RTP/AVP 119 31
	b=AS:4096
	b=TIAS:4096000
	a=sendrecv
	a=rtpmap:119 theora/90000
	a=fmtp:119 height=576;width=704
	a=rtpmap:31 h261/9[|sip]
02:50:33.749305 IP (tos 0x0, ttl 64, id 37061, offset 0, flags [+], proto UDP (17), length 1500)
    tom1.sip > ekiga.net.sip: SIP, length: 1472
	INVITE sip:500@ekiga.net SIP/2.0
	Date: Thu, 20 May 2010 00:50:30 GMT
	CSeq: 2 INVITE
	v: SIP/2.0/UDP 77.3.126.167:16074;branch=z9hG4bK60ee645b-1762-df11-8ffa-001109d76d6b;rport
	User-Agent: Ekiga/3.2.6
	f: "Tom1 Schorpp" <sip:schorpp@ekiga.net>;tag=50f0405b-1762-df11-8ffa-001109d76d6b
	i: f8f2405b-1762-df11-8ffa-001109d76d6b@tom1
	t: <sip:500@ekiga.net>
	m: <sip:schorpp@77.3.126.167:16074>
	Proxy-Authorization: Digest username="schorpp", realm="ekiga.net", nonce="4bf48774000184d785571b5f1a1692d77377d70b496f69d5", uri="sip:500@ekiga.net", algorithm=MD5, response="ce73f65915959f3aeeddaa1669858a18"
	Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
	c: application/sdp
	l: 769
	Max-Forwards: 70
	
	v=0
	o=- 1274316629 1 IN IP4 77.3.126.167
	s=Opal SIP Session
	c=IN IP4 77.3.126.167
	t=0 0
	m=audio 5094 RTP/AVP 8 116 115 0 105 104 103 102 3 9 101 120
	a=sendrecv
	a=rtpmap:8 PCMA/8000/1
	a=rtpmap:116 Speex/16000/1
	a=fmtp:116 sr=16000,mode=any
	a=rtpmap:115 Speex/8000/1
	a=fmtp:115 sr=8000,mode=any
	a=rtpmap:0 PCMU/8000/1
	a=rtpmap:105 G726-16/8000/1
	a=rtpmap:104 G726-24/8000/1
	a=rtpmap:103 G726-32/8000/1
	a=rtpmap:102 G726-40/8000/1
	a=rtpmap:3 gsm/8000/1
	a=rtpmap:9 G722/8000/1
	a=rtpmap:101 telephone-event/8000
	a=fmtp:101 0-16,32,36
	a=rtpmap:120 NSE/8000
	a=fmtp:120 192-193
	m=video 5096 RTP/AVP 119 31
	b=AS:4096
	b=TIAS:4096000
	a=sendrecv
	a=rtpmap:119 theora/90000
	a=fmtp:119 height=576;width=704
	a=rtpmap:31 h261/9[|sip]
02:50:35.537024 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 30)
    tom1.sip > ekiga.net.sip: SIP, length: 2
	
	
02:50:35.537486 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 30)
    tom1.sip > ekiga.net.sip: SIP, length: 2

Comment 2 tom schorpp 2010-05-20 01:23:23 UTC

But REGISTER works here.

Comment 3 Yannick 2010-05-20 04:27:38 UTC

Tom,

What happen if you discard unseless audio codecs and just keep 1 or 2 codecs that works (like PCMA, PCMU) ?

The idea is to keep all PDU under 1300.

Best regards,
Yannick

Comment 4 tom schorpp 2010-05-20 13:46:26 UTC

hi yannick, set STATUS to NEW, pls. Bug no more unconfirmed.

Yes, therere several warnings in -d 3 log for oversized PDU:

2010/05/20 15:15:46.736	  4:04.584	        Pool:0xe1ed7910	SIP	Adding authentication information
2010/05/20 15:15:46.780	  4:04.628	        Pool:0xe1ed7910	SIP	Transaction remote address is udp$ekiga.net:5060
2010/05/20 15:15:46.784	  4:04.632	        Pool:0xe1ed7910	SIP	PDU is likely too large (1501 bytes) for UDP datagram.

Ok, it works with ekiga.net and sipgate.de if I disable ms-gsm and G.726-40 with missing unfree video codecs setup.

Pls notify the user about this in the status line and not with the default error message.

Comment 5 Yannick 2010-05-20 16:44:45 UTC

Hi Tom,

Unfortunately I do not have such power... IMHO it is dupe of #341518

Please take the time to read the above bug, it sum up all knowledge I do have about this issue.

Best regards,
Yannick

*** This bug has been marked as a duplicate of bug 341518 ***

Comment 6 tom schorpp 2010-05-22 00:49:56 UTC

#341518 (Feature request for TCP support) is not a duplicate of this bug,
comments starting with 
https://bugzilla.gnome.org/show_bug.cgi?id=341518#c6
are wrongplaced there, they belong here.

Comment 7 Yannick 2010-05-22 04:49:15 UTC

Ok, reverted the mark as a duplicate.

Comment 8 Eugen Dedu 2012-12-14 08:33:06 UTC

I think this is a duplicate of bug #341518 indeed.  When the PDU is too large, we have to switch to TCP.

Comment 9 Tobias Mueller 2013-05-07 11:13:26 UTC

Reopen as I can't see any open non developer question.

Comment 10 Eugen Dedu 2013-05-07 11:46:43 UTC

Well, this issue is very likely solved with the release of 4.0.  If not, please reopen...