Bug 1124510 - upgrade to 1.18.2 breaks voice calls
Summary: upgrade to 1.18.2 breaks voice calls
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pidgin-sipe
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stefan Becker
QA Contact: Fedora Extras Quality Assurance
URL: http://sourceforge.net/p/sipe/bugs/258/
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-29 16:28 UTC by David Woodhouse
Modified: 2014-08-28 15:35 UTC (History)
2 users (show)

Fixed In Version: pidgin-sipe-1.18.3-1.fc20
Clone Of:
Environment:
Last Closed: 2014-07-29 19:19:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description David Woodhouse 2014-07-29 16:28:44 UTC
Since upgrading to 1.18.2, I can no longer make voice calls. I get

SIP/2.0 488 Not Acceptable Here
ms-diagnostics-public: 10006;reason="Proxy side Media negotiation failed";component="MediationServer"

This only appears to happen when I have an IPv6 address assigned; if I put my self through a time warp back into the 20th century and run with only Legacy IP, it starts working again.

Further investigation shows a difference in my INVITE when attempting to make the call. With 1.17.0 it sends this (using my public IP address instead of the VPN address, but it seems to work anyway):

Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-Disposition: session; handling=optional; ms-proxy-2007fallback

o=- 0 0 IN IP4 90.155.92.213
s=session
c=IN IP4 90.155.92.213
m=audio 0 RTP/AVP


With 1.18.2 in the 20th century, it sends this (with a better IP address, not that it seemed to matter):

o=- 0 0 IN IP4 10.252.13.192
s=session
c=IN IP4 10.252.13.192
m=audio 0 RTP/AVP

With 1.18.2 in the 21st century, it sends this:

o=- 0 0 IN IP4 2001:8b0:10b:1:225:64ff:fee8:e9df
s=session
c=IN IP4 2001:8b0:10b:1:225:64ff:fee8:e9df
m=audio 0 RTP/AVP

Comment 1 David Woodhouse 2014-07-29 16:49:35 UTC
I tried the following hack, which didn't work:

--- a/src/core/sdpmsg.c
+++ b/src/core/sdpmsg.c
@@ -709,7 +709,7 @@ sdpmsg_to_string(const struct sdpmsg *msg)
 		"c=IN IP4 %s\r\n"
 		"b=CT:99980\r\n"
 		"t=0 0\r\n",
-		msg->ip, msg->ip);
+		"10.252.13.192", "10.252.13.192");
 
 
 	for (i = msg->media; i; i = i->next) {
diff --git a/src/core/sipe-media.c b/src/core/sipe-media.c
index c4dcffb..43ce198 100644
--- a/src/core/sipe-media.c
+++ b/src/core/sipe-media.c
@@ -429,7 +429,8 @@ sipe_invite_call(struct sipe_core_private *sipe_private, TransCallback tc)
 			"%s"
 			"\r\n"
 			"------=_NextPart_000_001E_01CB4397.0B5EB570--\r\n",
-			msg->ip, msg->ip, body);
+			"10.252.13.192", "10.252.13.192",
+		        body);
 		g_free(body);
 		body = tmp;
 	}
I now send this:

Via: SIP/2.0/tls 10.252.1.172:39350
From: <sip:david.woodhouse>;tag=2289020549;epid=8c60d96cd971
To: <sip:+447976658355;user=phone>
Max-Forwards: 70
CSeq: 1 INVITE
User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2) 
Call-ID: 79AEg4FD9aB526i3D15mEF58tF7EFb9A91xEDC4x
ms-keep-alive: UAC;hop-hop=yes
Contact: <sip:david.woodhouse;opaque=user:epid:RTTbfUxsnFasNhQY104Z9wAA;gruu>
P-Preferred-Identity: <sip:david.woodhouse>, <TEL:+441793404858;ext=2814858>
Content-Type: multipart/alternative;boundary="----=_NextPart_000_001E_01CB4397.0B5EB570"
Content-Length: 2758
Authorization: NTLM qop="auth", opaque="A1BF668D", realm="SIP Communications Service", targetname="fmscsfe111.amr.corp.intel.com", crand="8781e51d", cnum="10", response="0100000036B31911DBE1FE0464000000"

------=_NextPart_000_001E_01CB4397.0B5EB570
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-Disposition: session; handling=optional; ms-proxy-2007fallback

o=- 0 0 IN IP4 10.252.13.192
s=session
c=IN IP4 10.252.13.192
m=audio 0 RTP/AVP

------=_NextPart_000_001E_01CB4397.0B5EB570
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-Disposition: session; handling=optional

v=0
o=- 0 0 IN IP4 10.252.13.192
s=session
c=IN IP4 10.252.13.192
b=CT:99980
t=0 0
m=audio 55290 RTP/AVP 0 3 8 9 96 97 98 99 100 101 102 103 104
a=candidate:1 1 UDP 2013266431 2001:8b0:10b:1:225:64ff:fee8:e9df 55290 typ host 
a=candidate:1 2 UDP 2013266430 2001:8b0:10b:1:225:64ff:fee8:e9df 49172 typ host 
a=candidate:10 1 UDP 1006633215 192.198.165.17 50043 typ relay raddr 192.168.122.1 rport 33466 
a=candidate:10 2 UDP 1006633214 192.198.165.17 51161 typ relay raddr 192.168.122.1 rport 33421 
a=candidate:2 1 UDP 2013266431 10.252.13.192 33496 typ host 
a=candidate:2 2 UDP 2013266430 10.252.13.192 33769 typ host 
a=candidate:3 1 UDP 2013266431 192.168.100.1 47655 typ host 
a=candidate:3 2 UDP 2013266430 192.168.100.1 40632 typ host 
a=candidate:4 1 UDP 2013266431 172.31.0.1 51951 typ host 
a=candidate:4 2 UDP 2013266430 172.31.0.1 50686 typ host 
a=candidate:5 1 UDP 2013266431 192.168.122.1 33466 typ host 
a=candidate:5 2 UDP 2013266430 192.168.122.1 33421 typ host 
a=candidate:6 1 UDP 2013266431 90.155.92.213 49966 typ host 
a=candidate:6 2 UDP 2013266430 90.155.92.213 36270 typ host 
a=candidate:7 1 UDP 1006633215 192.198.165.17 51593 typ relay raddr 10.252.13.192 rport 33496 
a=candidate:7 2 UDP 1006633214 192.198.165.17 52985 typ relay raddr 10.252.13.192 rport 33769 
a=candidate:8 1 UDP 1006633215 192.198.165.17 51790 typ relay raddr 192.168.100.1 rport 47655 
a=candidate:8 2 UDP 1006633214 192.198.165.17 53947 typ relay raddr 192.168.100.1 rport 40632 
a=candidate:9 1 UDP 1006633215 192.198.165.17 57460 typ relay raddr 172.31.0.1 rport 51951 
a=candidate:9 2 UDP 1006633214 192.198.165.17 52239 typ relay raddr 172.31.0.1 rport 50686 
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:96 SIREN/16000
a=fmtp:96 bitrate=16000
a=rtpmap:97 MPA/90000
a=rtpmap:98 DV/90000
a=rtpmap:99 AMR/8000
a=fmtp:99 octet-align=1 crc=0 robust-sorting=0 interleaving=0
a=rtpmap:100 telephone-event/16000
a=fmtp:100 events=0-15
a=rtpmap:101 telephone-event/8000
a=fmtp:101 events=0-15
a=rtpmap:102 telephone-event/90000
a=fmtp:102 events=0-15
a=rtpmap:103 SPEEX/16000
a=rtpmap:104 SPEEX/8000
a=rtcp:49172
a=encryption:rejected
a=ice-ufrag:MoES
a=ice-pwd:FsioW5MA4z7r1MgbZFyKyP

... and get this:

SIP/2.0 503 Service Unavailable
ms-diagnostics-public: 10014;reason="An internal exception received while processing the incoming request";component="MediationServer";Exception="An internal media error occurred"

Comment 2 Stefan Becker 2014-07-29 19:19:01 UTC
CLOSED UPSTREAM, because the same issue has already been reported there.

As SF bug tracker is not in th elist, I've added the upstream bug in the URL field.

Comment 3 David Woodhouse 2014-07-29 20:22:35 UTC
As noted in the upstream bug, this regression was introduced in 1.18.1 by commit 
1556f377ecc7c3d4887f8e9f2805a4e7f7e60660.

Reverting that commit on top of the current 1.18.2 release makes it work again.

I still can't see a material difference between the invite before the offending the commit, and the invite with my hack from comment 1 though.

Comment 4 Fedora Update System 2014-08-16 14:29:36 UTC
pidgin-sipe-1.18.3-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/pidgin-sipe-1.18.3-1.fc20

Comment 5 Fedora Update System 2014-08-16 14:30:47 UTC
pidgin-sipe-1.18.3-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/pidgin-sipe-1.18.3-1.fc19

Comment 6 Fedora Update System 2014-08-28 15:32:34 UTC
pidgin-sipe-1.18.3-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Fedora Update System 2014-08-28 15:35:45 UTC
pidgin-sipe-1.18.3-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.