Re: [Ietf-behave] Compatibility between RFC3489 anddraft-ietf-behave-rfc3489bis-04
Hi,
There are some non backwards compatible issues in rfc3489bis-04 in the
STUN service discovery.
You can see these by looking at the Behave WG mailing list archive - the
mail subject is "STUN Server Discovery".
IMHO, these compatibility issues have not yet been solved.
I hope these are taken thoroughly care of in the next draft version.
--
Tomi Kohonen
Nokia Corporation
>-----Original Message-----
>From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>ext Alfred E. Heggestad
>Sent: 03 October, 2006 17:32
>To: ietf-behave@xxxxxxxxxxxxxxxxxxx
>Subject: [Ietf-behave] Compatibility between RFC3489
>anddraft-ietf-behave-rfc3489bis-04
>
>Hi
>
>Is rfc3489bis-04 intended to be backwards compatible with
>RFC3489? i.e. should it be possible to use a RFC3489 compliant
>STUN-client with a bis-04 compliant STUN server, or vice versa?
>
>My findings so far, when implementing a STUN library as
>specified in rfc3489bis-04, is that there are some issues.
>However they might be implementation-specific.
>
>
>* rfc3489bis-04 compliant STUN client against
>RFC3489-compliant STUN server:
>
> The STUN request contains the new FINGERPRINT attribute, but this
> attribute is not supported by the STUN server (Vovida.org 0.96),
> hence the response is dropped.
>
>
>
>* RFC3489-compliant STUN client against rfc3489bit-04
>compliant STUN server:
>
> The STUN request is sent from the client (X-lite) and the
>STUN server
> returns a response with MAPPED-ADDRESS attribute. But since
>the response
> does not contain attributes SOURCE-ADDRESS and
>CHANGED-ADDRESS, the STUN
> client is not able to use the response.
>
>
>If these two specs are intended to be compliant, are there any
>special ways of getting this to work?
>
>many thanks in advance.
>
>
>/alfred
>
