[RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?

[Bernard Aboba]

Alternatives can be explored for how to represent the information provided by SDP, but the enumeration and testing of potential endpoints within an offer-answer exchange is at the core of ICE (RFC 5245), and is also a potential means for demonstrating media authorization.  If the Javascript limitations on enumeration of physical or logical addresses can't be overcome, we might have to live with server reflexive and relayed endpoint identifiers (assuming that server reflexive and relayed endpoint identifiers don't trigger similar concerns).  Replacing addresses with names could be done prior to the offer/answer exchange but this might introduce vulnerabilities (e.g. voice hammer attacks based on DNS cache poisoning).  
Date: Wed, 2 Feb 2011 16:09:48 -0800
From: harald at alvestrand.no
To: rtc-web at alvestrand.no
Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?



  


    
  
  
    On 02/02/11 11:19, Henry Sinnreich wrote:
    
      Message body
      Is there some understanding on the
          list on how the IP addresses in SDP can be reconciled with the
          USAF RFC 3424?

        
    Nit: UNSAF, not USAF.

    
          http://www.rfc-editor.org/rfc/rfc3424.txt
          

          

          “...a process whereby some

               originating process attempts to determine or fix the
            address (and

               port) by which it is known - e.g. to be able to use
            address data in

               the protocol exchange, or to advertise a public address
            from which it

               will receive connections.

            There are only heuristics and workarounds to attempt to
            achieve this

               effect; there is no 100% solution.  Since NATs may also
            dynamically

               reclaim or readjust translations, "keep-alive" and
            periodic re-

               polling may be required.  Use of these workarounds MUST
            be considered

               transitional in IETF protocols, and a better
            architectural solution

               is being sought.  The explicit intention is to deprecate
            any such

               workarounds when sound technical approaches are
            available.”

          
    In our case, the answer that has proved workable is called STUN.

    
          

          Obviously there is much more dead stuff in SDP besides using
          the misleading IP addresses, but this seems to be a deep
          architectural flaw.

          There were some early attempts to do SDPng and we know today
          much more:

          http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07

          

          Why not replace SDP, since it deals only with a/v codec
          negotiation with a more general, standards based metadata
          approach?

          For example including Web conferencing displays and UI control
          capabilities.

          Of course such a new approach must be easily mapped to the
          existing global SIP VoIP infrastructure. 

          

          Or are the no  “sound
            technical approaches” available at all?

    
    I'm all in favour of replacing SDP, but would not like to require
    that before we can produce any output from this group.

    

    Justin's idea of sorting out what information we need and specifying
    how that maps into SDP (just like is currently done by Jingle) might
    be a reasonable approach that can allow us to not fossilize SDP's
    misfeatures forever.

    

                           Harald

    

  


_______________________________________________
RTC-Web mailing list
RTC-Web at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/rtc-web 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtc-web/attachments/20110202/0e1739bb/attachment.html>