Subject: [BEHAVE] STUN/TURN message type bits

From: Benny Prijono <[email-masked]>
Date: Mon, 05 Feb 2007 13:45:15 -0800

All,

I think I need a way to distinguish STUN message classes (i.e. 
request, response, or indication), and reading section 6 of the 
rfc3489bis I think this is what I conclude for the formula, in 
traditional C:

#define IS_REQUEST(msg_type)      (((msg_type) & 0x0FF0) == 0x0000)
#define IS_RESPONSE(msg_type)     (((msg_type) & 0x0FF0) == 0x0100)
#define IS_ERR_RESPONSE(msg_type) (((msg_type) & 0x0FF0) == 0x0110)
#define IS_INDICATION(msg_type)   (((msg_type) & 0x0FF0) == 0x0010)

Is that right (or wrong)?

If that is right, then I have a question regarding the values for 
TURN indications, which currently (as turn-02) are:

    0x0004  :  Send Indication
    0x0115  :  Data Indication
    0x0118  :  Connect Status Indication

Somehow I feel that there is no consistency in the value assignment 
(Send Indication looks like a request, while the others look like 
error responses). So what's the rule here?

Any help on this will be great.

thanks,
  -benny

-- 
Benny Prijono
http://www.pjsip.org

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Feb 2007 11:38:52 -0500

Benny Prijono wrote:

> All,
> 
> I think I need a way to distinguish STUN message classes (i.e. request, 
> response, or indication), and reading section 6 of the rfc3489bis I 
> think this is what I conclude for the formula, in traditional C:
> 

I think its wrong. The reason is that the class is only two of the 12 
bits. So I think its:

#define IS_REQUEST(msg_type)       (((msg_type) & 0x0110) == 0x0000)
#define IS_INDICATION(msg_type)    (((msg_type) & 0x0110) == 0x0010)
#define IS_SUCCESS_RESP(msg_type)  (((msg_type) & 0x0110) == 0x0100)
#define IS_ERR_RESP(msg_type)      (((msg_type) & 0x0110) == 0x0110)

> 
> If that is right, then I have a question regarding the values for TURN 
> indications, which currently (as turn-02) are:
> 
>    0x0004  :  Send Indication
>    0x0115  :  Data Indication
> (Send Indication looks like a request, while the others look like error 
> responses). So what's the rule here?

Yes, the TURN values are wrong. I discussed this at the IETF meeting, 
that the proposed bitfield approach worked well for existing STUN 
attributes but would be wrong for the new indications that were recently 
added to TURN. Those need to be changed in the revision of TURN.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Benny Prijono <[email-masked]>
Date: Wed, 14 Feb 2007 23:05:58 +0000

> #define IS_ERR_RESP(msg_type)      (((msg_type) & 0x0110) == 0x0110)

thanks for answering my questions, Jonathan, and you're right with 
the bit-fields. Using 0x0110 mask rather than 0x0FF0 gives us 
possibility to have more than 16 STUN methods.

> added to TURN. Those need to be changed in the revision of TURN.

So until the new revision is released, I think we can assume that 
these are the values (?):

     0x0014  :  Send Indication
     0x0015  :  Data Indication
     0x0018  :  Connect Status Indication

thanks
  -benny

-- 
Benny Prijono
http://www.pjsip.org