[Serdev] STUN support in SER
Vladimir Marek
vlada at iptel.org
Mon Dec 11 10:23:00 UTC 2006
Hi Alfred,
thanks for your mail! I will check the length calculation ASAP and will
let you know.
Actually I expect that we will upgrade STUN to newest version of draft
but there is no decision when we will do that. From my point of view the
draft 05 is still to unstable document and I would wait for more stable
version of it (I think that the discussion about draft 05 is still too big).
Yes, the SER supports STUN via TCP protocol.
Regards,
Vladimir
Alfred E. Heggestad wrote:
> hi
>
> I see that there is now support for STUN in SER (v0.10) - well done guys,
> that is a very useful feature..
>
>
> I have a couple of comments/questions:
>
>
> * I did a quick test running a STUN client against a running SER with
> STUN
> enabled, and I got back:
>
> 00000000: 0111 007c 2112 a442 bdbe 2838 6245 ed66 ...|!..B..(8bE.f
> 00000010: 89f7 90ee 0009 0076 0000 0400 5468 6520 .......v....The
> 00000020: 7265 7175 6573 7420 7761 7320 6d61 6c66 request was malf
> 00000030: 6f72 6d65 642e 2054 6865 2063 6c69 656e ormed. The clien
> 00000040: 7420 7368 6f75 6c64 206e 6f74 2072 6574 t should not ret
> 00000050: 7279 2074 6865 2072 6571 7565 7374 2077 ry the request w
> 00000060: 6974 686f 7574 206d 6f64 6966 6963 6174 ithout modificat
> 00000070: 696f 6e20 6672 6f6d 2074 6865 2070 7265 ion from the pre
> 00000080: 7669 6f75 7320 6174 7465 6d70 742e 0000 vious attempt...
> 00000090: 8022 003d 5365 7276 6572 3a20 5369 7020 .".=Server: Sip
> 000000a0: 4558 7072 6573 7320 726f 7574 6572 2028 EXpress router (
> 000000b0: 302e 3130 2e39 392d 6465 7636 332d 746c 0.10.99-dev63-tl
> 000000c0: 7320 2878 3836 5f36 342f 6c69 6e75 7829 s (x86_64/linux)
> 000000d0: 2900 0000 0023 0014 91ad 2a16 387e 3e6c )....#....*.8~>l
> 000000e0: 9e22 0c86 eed4 4f92 2ae6 0180 ."....O.*...
>
>
> according to this packet the length of the STUN message (excluding
> header) should be 124 bytes, however the length is actually 216 bytes.
> Is there perhaps a calculation error of the length field?
>
>
> * I see that SER's STUN implementation is expecting a mandatory
> FINGERPRINT
> headerfield (SHA1) as of rfc3489-bis04 - this has now changed to
> optional
> and CRC32 in rfc3489-bis05 - do you have any plans of upgrading your
> code
> to support this?
>
>
> * Do you also support STUN over TCP ?
>
>
> thanks.
>
>
> /alfred
>
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
More information about the Serdev
mailing list