Subject: [MMUSIC] How to Differentiate Application Data, and STUN Packets after ICE Connectivity Checkup

From: <[email-masked]>
Date: Fri, 30 Nov 2007 17:37:05 +0800

Hi:

           I have a question about the packet classification in ICE-19 as:

           Assuming terminal-A is using RTP port 8000 for a SIP call, and it has provided host-candidate, server-reflexive-candidate, and TURN-relayed-candidate for ICE connectivity checkup.

           Just upon finishing ICE connectivity checkup, there might have several kinds of packets destined to RTP-port 8000 at A 

1.       ICE connectivity check up packets in transit after ICE concluding.

                                                             i.                TURN packets  with channel and length framing and without FINGERPRINT (TURN-draft-5)

                                                            ii.                STUN binding requests with FINGERPRINT (ICE-19)

2.       RTP packets, which may be

                                                             i.                from TURN server in a different channel or as Data indication without FINGERPRINT

                                                            ii.                from the peer directly as RTP raw data if TURN-relayed-candidate is not in use.

My question is how we differentiate from 1.i and 2.ii under such circumstances? FINGERPRINT helps in packet differentiation, but TURN-draft-5 explicit forbids the use of FINGERPRINT. Besides, TURN-draft-5 also introduced a 2-byte channel field at the beginning of a UDP packet and its value is randomly selected by the peer, which in turn stands a possibility to match the RTP-version field in RTP-header.

Albert

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 Nov 2007 10:47:15 -0500

The client needs to first separate data from the TURN server, from other
data. Data from the TURN server is separable because the source IP/port
is that of the TURN server.

So the algorithm would be:

if(source IP == TURN server) {
  /* from TURN server */

  if(channel == 0) {
    /* control traffic */

    processTURNControl();
  } else {
    /* data traffic */

    ExtractDataFromChannel();

    if(isSTUNMessage(Data)) {
      /* connectivity check */
      processConnectivityCheck();
    } else {
      /* RTP */
      processRTP();
    }
  }

} else {

    if(isSTUNMessage(Data)) {
      /* connectivity check */
      processConnectivityCheck();
    } else {
      /* RTP */
      processRTP();
    }
}

-Jonathan R.
[email-masked] wrote:
>            Assuming terminal-A is using RTP port 8000 for a SIP call, 
> and it has provided host-candidate, server-reflexive-candidate, and 
> TURN-relayed-candidate for ICE connectivity checkup.
> 
>            Just upon finishing ICE connectivity checkup, there might 
> have several kinds of packets destined to RTP-port 8000 at A
> 
> My question is how we differentiate from 1.i and 2.ii under such 
> circumstances? FINGERPRINT helps in packet differentiation, but 
> TURN-draft-5 explicit forbids the use of FINGERPRINT. Besides, 
> TURN-draft-5 also introduced a 2-byte channel field at the beginning of 
> a UDP packet and its value is randomly selected by the peer, which in 
> turn stands a possibility to match the RTP-version field in RTP-header.
> 
>  
> 
> Albert
> 
> 
> ------------------------------------------------------------------------
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com