Not sure if this is going to help you. But I did find a problem in
SdpBody.cpp in SdpBody::addCodecsOffer(). Basically 'szTransportString' was
being used to fill transport in SDP but is being used unintialized. I fixed
the problem by using 'UDP' directly instead of that variable. Thats the way
it is done in SdpBody::addCodecsAnswer(). Code snippet shown -
-----------------------------------------------------------------------------------------------------
if (iNumAddresses > 1)
{
//char szTransportString[16]; // not initialized here
for (int i=0; i<iNumAddresses; i++)
{
if ((transportTypes[i] & RTP_TRANSPORT_UDP) ==
RTP_TRANSPORT_UDP)
{
szTransportType = SDP_RTP_MEDIA_TRANSPORT_TYPE;
}
else
{
szTransportType = SDP_RTP_TCP_MEDIA_TRANSPORT_TYPE;
}
double priority = (double) (iNumAddresses-i) / (double)
iNumAddresses ;
assert(mediaAddresses[i].length() > 0) ;
if (rtpAudioPorts[0] && rtpAudioPorts[i] &&
mediaAddresses[i])
{
//addCandidateAttribute(i, "t", szTransportString,
priority, mediaAddresses[i], rtpAudioPorts[i]) ; //used unintialized here
addCandidateAttribute(i, "t", "UDP", priority,
mediaAddresses[i], rtpAudioPorts[i]) ;
}
if (rtcpAudioPorts[0] && rtcpAudioPorts[i] &&
mediaAddresses[i])
{
//addCandidateAttribute(i, "t", szTransportString,
priority, mediaAddresses[i], rtcpAudioPorts[i]) ; //used unintialized here
addCandidateAttribute(i, "t", "UDP", priority,
mediaAddresses[i], rtcpAudioPorts[i]) ;
}
}
}
----------------------------------------------------------------------------------------------------------------
Regards,
Anshuman
----- Original Message -----
From: "Alexander Boreham" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, July 19, 2007 3:54 PM
Subject: [sipxtapi-dev] STUN response ignored on RTP and RTCP
ports(introduced in revisi on 9386)
Hi,
Sorry to report another problem but this is also causing issues.
The changes made in revision 9386 have caused STUN failures on the RTP and
RTCP ports. The SIP call control port still receives STUN responses
correctly. I've made many Wireshark traces and can see that the STUN
requests are correctly made to the server and that the correct STUN
responses are received back but sipXtapi doesn't use the responses on the
media ports.
Looking back through the changes and trying old builds I found the point at
which this issue started to occur. Here's a link to the change list:
http://scm.sipfoundry.org/viewsvn/sipX?view=rev&sortby=date&revision=9386
I've started to look into it but thought that maybe somebody would have an
idea of the problem already. Presumably one of the changes has caused the
STUN response messages to be dropped, maybe because we haven't yet
negotiated a codec.
Any help to track this down would be appreciated!
Thanks,
Alex
=====
Alex Boreham
Development Engineer
Redwood Technologies Limited
The Redwood Building, Broad Lane, Bracknell, Berkshire, RG12 9GU, U.K.
Registered in England No. 2817863
T +[44] (0)1344 304 344
F +[44] (0)1344 304 345
E [EMAIL PROTECTED]
W www.redwoodtech.com
=====
Email Disclaimer
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it is prohibited and may be unlawful. When addressed to our clients any
opinions or advice contained in this email are subject to the limitations of
Redwood Technologies Limited's standard terms and conditions of contract.
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
--
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.4/897 - Release Date: 7/11/2007
9:57 PM
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
