Re: [MMUSIC] FQDN support in ice-sip-sdp

Roman Shpount <> Fri, 12 April 2019 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B31D1203DB for <>; Fri, 12 Apr 2019 11:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J69k7tL5g4zj for <>; Fri, 12 Apr 2019 11:23:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E22DD1203B6 for <>; Fri, 12 Apr 2019 11:23:16 -0700 (PDT)
Received: by with SMTP id y13so5517802pfm.11 for <>; Fri, 12 Apr 2019 11:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KxdLm7wA1Yz2C8Rtyd/3mZE1r2gVvy9PrMk1nKSf6cY=; b=CTIZRdgvHjCQjjDpwDTE2YqFtbWjlJN9jumMpt0ZtQHABOXuMGakD8ARzgEJgAiui8 Soezcuo5vwlwqI/RwguUk7MBTXfa7f5FLJ49l9x19dyyq5YepZHyJ198T5p4RmJtTB0T 7e8OqQ8bF48eQt0fPo9j9FHeG8eCs2dSQEv6PYME3onroxfAsdxuqlwnC2qFCt1BFJtb Vxsb8ZSA65UWEwq2/hrD9lwwUaAjY3f0NMMTcUWICHnLIHVg0qHuWW03Ok9vyrFg09Wz UOKwZGtdRLilqMwyoJDfY/Ds7L525/DuscWtkd6kN1ehgOF5bdQCyAVknHJCS/Up0XCi JjwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KxdLm7wA1Yz2C8Rtyd/3mZE1r2gVvy9PrMk1nKSf6cY=; b=alNMOAlohtaeRReiwCIfr57hJmHl8O/0zJNkPAKqXG9FdGfvzm1KeQqWAaVAvjfXzZ xC29by6m33J/EUTlnIzbcRZ0SoEIohfKEmP1lFDEMNghphDOkDJqz9IyXQUDC1Ekd0mv URj8FTl5tkJaRTM7vX85BMGDlrivcwnWzXob8zdQaXt5ZQPToItDRn9s3UZTKOJxjUoI yVqOmzrz45n4eroOvmb5EerWIno/GFDe/XoMnPIyUhVDIaM6vATu/dPGLiJb7FJ9h5PM 9BDkX+SlbrdfWvEbnYZMftR8FFl73JOLDCb/n4kaJ4hL9uej+fojIs1nEFjtm/RsINWF rPsA==
X-Gm-Message-State: APjAAAXGuvhCqJUE9pTw65y2F3n9wEkWapZBZ031hQJg59w8kWc2Z9rd ccluF1uym6oNJLqwt+Y/FacUSsKFHNE=
X-Google-Smtp-Source: APXvYqyFpU8DhBbzPhNutPgOGdIBdA7hv+PTc5sSiKApg/qTZ0JsbjLljx2Bo/ONPXo8LtNAeXCCCw==
X-Received: by 2002:aa7:9116:: with SMTP id 22mr58761697pfh.165.1555093396073; Fri, 12 Apr 2019 11:23:16 -0700 (PDT)
Received: from ( []) by with ESMTPSA id c81sm30482799pfb.158.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Apr 2019 11:23:14 -0700 (PDT)
Received: by with SMTP id f6so5577104pgs.8 for <>; Fri, 12 Apr 2019 11:23:14 -0700 (PDT)
X-Received: by 2002:a63:ce50:: with SMTP id r16mr52818703pgi.89.1555093394486; Fri, 12 Apr 2019 11:23:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Fri, 12 Apr 2019 14:23:00 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Christer Holmberg <>
Cc: Suhas Nandakumar <>, mmusic WG <>, Flemming Andreasen <>
Content-Type: multipart/alternative; boundary="0000000000005efcc4058659654a"
Archived-At: <>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Apr 2019 18:23:19 -0000

On Fri, Apr 12, 2019 at 5:32 AM Christer Holmberg <> wrote:

> >> I *think* I agree with Suhas that the FQDN handling should be a
> separate draft – a generic ICE draft produced by the ICE WG. ice-sip-sdp
> would then specify how it is implemented in SDP (separate a=candidiate
> lines etc).
> >>
> >> Perhaps it could be combined with the mDNS draft?
> >
> > I am not sure if this belongs to a new draft or mDNS draft. We can
> decide this later. What we need to decide now comes down to two choices:
> >
> > a. Say that FQND is allowed in candidate connection-address but these
> candidate lines are skipped. Handling of FQDN lines is defined in the
> future specification.
> >
> > b. Figure out how FQDN is handled. Options written up so far imply
> either selecting one resolution result in random or requiring the FQDN
> resolves to a single address. I think former is broken and later does not
> exist in real life.
> > I would not like this draft to be released with either option. I think
> adding address type to candidate brings candidate line connection address
> definition in line with SDP c= line specification and should work, but
> someone needs
> > to review this. I do not think this will require more then 2-3 extra
> paragraphs in the document which I am willing to write. I agree this is
> scope creep but FQDN were included in RFC 5245 so people expect them to be
> supported
> > by this draft as well.
> >
> > At the end, this is up to the group to decide. I just need something I
> can implement. If option a makes people unhappy then we will need to find
> minimal viable option b.
> As far as the technical solution is concerned (using separate a=candidiate
> lines for each IP version family etc), I think it looks good.
> As far as documenting is concerned, I think the SDP specifics (separate a=
> lines etc) could be defined in ice-sip-sdp - but I would not object to
> having a separate draft.
> My point is that I don't see FQDN support as SDP-specific, so I would like
> to have generic ICE FQDN text documented somehwhere, which the SDP-specific
> procedures then reference.

I see your point, but I would prefer to avoid creating another dependency
which will prevent ice-sip-sdp from being published.

Please note, that if we specify that candidate line using FQDN
contact-address MUST specify address type and FQDN MUST resolve to a single
address per address type, then FQDN handling is trivial: Agent should do a
DNS resolution and use the result. Figuring out how to handle multiple
results per DNS query certainly warrants a separate draft and should be out
of scope.

What makes sense for me is:

a. Define how to specify address type in candidate line. This is certainly
an SDP problem and I think is a pre-requisite to using any addresses, such
as FQDN, where address type is non-obvious

b. Specify that if agent compliant with ice-sip-sdp uses FQDN
contact-address, it MUST specify addrtype for the candidate.

c. Specify that if FQDN resolves to a single address for the specified
family then that this address is used for this candidate. Candidate lines
with FQDN returning multiple results per query MUST be ignored until their
handling is defined in a future draft

d. Specify what to do with FQDN without address type specified such as SDP
from legacy RFC 5245 implementations. We can go with try AAAA resolution
first and use if single address is returned. If nothing is returned from
AAAA query, try A query. If single address is returned, used that address,
ignore the candidate line otherwise. This matches RFC 5245 language and
should work in all the same situations where RFC 5245 implementations were

What do you think?
Roman Shpount