Subject: [Megaco] multiple IPs returned by DNS

From: "Raphael Tryster" <[email-masked]>
Date: Thu, 30 Nov 2006 09:34:33 +0200

MGCP is very clear about what to do if the MG knows the MGC by name,
which is resolved by DNS: If several retransmissions fail to get a
reply, it should try additional IP addresses it received from DNS for
the same name, and if all of those fail, ask DNS again to see if there
are any more IP addresses before giving up.

In Megaco, it is not specified what to do with multiple IPs returned by
DNS.  Should the MG try these additional addresses and re-query DNS
after a few retransmissions, before trying the next MGC on the secondary
list?  

Or is there a fundamental difference between the ways MGCP and Megaco
view the retransmission process?
 
Raphael Tryster
**********************************************************************************************
This e-mail contains confidential, privileged or proprietary information to VocalTec Communications.
If you received this messege by mistake, please inform us and then delete the original and all copies.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************

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

---

From: [email-masked]
Date: Thu, 30 Nov 2006 13:55:51 +0100

Raphael,

there isn't any fundamental difference concerning DNS involvement or/and
usage of domain names for H.248 entities in my opinion.

The major difference (I see) is mainly of textual nature: MGCP describes
DNS items in the core protocol itself, whereas H.248 provides a dedicate
supplement ITU-T Supplement H.Sup7  "Gateway Control Protocol:
Establishment Procedures for the H.248 MGC-MG Control Association".

   Latest draft:
   T05-SG16-061114-TD-WP2-0342!R1!MSW-E.doc
   [342-WP2]  Updated draft new ITU-T Supplement H.Sup7  "Gateway Control
   Protocol: Establishment Procedures for the H.248 MGC-MG Control
   Association" (Ed. 0.8)

H.248 is not using the core protocol spec. (= H.248.1) itself, because
H.248 is also capable for non-IP based transport, and in case of IP-based
transport, DNS operations are more othogonal to the gateway control
protocol IMHO.

H.Sup7 touches DNS at a couple of places (see below). Most important is the
structure of the MG database for MGC entries, see Table 2/H.Sup7, - which
may explicitly support domain names.

Regards,
Albrecht

H.Sup7:

5.3.1 Correlation via ServiceChange Parameter "MgcID"

There is one possibility for the MGC, but not for MGs, to correlate MID and
address by using parameter ServiceChangeMgcID in ServiceChange commands
(from MGC towards MG). Parameter ServiceChangeMgcID is of type "MID",
allowed procedure(s) are defined in clause F.5.7/H.248.1 (see also clause
5.5.5.2).

The new MIDMGC is extracted from the received parameter ServiceChangeMgcID
by the MG. The derivation of the actual IP address of the MGC ( AMGC) may
require an additional translation step (e.g., DNS query) dependent on the
chosen MIDMGC encoding scheme.

...

5.5.6.2.1   With DNS Involvement

This approach is based on the applied concept of previous clause 5.5.6.1.
The H.248 entity must provide a DNS client instance and the DNS protocol
for DNS server access. The local DNS database is coupled with databases of
H.248 entities as described in clause 5.4.1.

The idea is the following, for instance in case of an MG:

     The MG provides a database for MGC entries according Table 2. The
     FQDNMGC (see column "symbolical IP address") remains unchanged for the
     designated MGC entity, but changes of address AMGC may the MG detect
     by DNS queries.

It has to be noted that this advantage requires careful design
considerations, primarily because of following aspects:
·     Correspondent database updates on MGC and MG level are inherently not
tightly synchronized (due to the third instance of a DNS server).
·     DNS is based on caching, associated with the DNS time-to-live (TTL)
concept. The expiration of timer DNS-TTL triggers cache refreshes. It may
thus take a rather long time till the MG gets the new MGC address via DNS.

      NOTE:  Typical TTL configurations are for instance 60 seconds. H.248
             entity embedded DNS clients require definitely much smaller
             TTL values.
·     There might be interactions with other, ServiceChange based
procedures (e.g., according clause 11.6/H.248.1), due to a natural
transition period with address inconsistencies

                      "Raphael Tryster"                                                                                                  
                      <raphael.tryster@vo         To:      <[email-masked]>                                                             
                      caltec.com>                 cc:                                                                                    
                                                  Subject: [Megaco] multiple IPs returned by DNS                                         
                      30.11.2006 08:34                                                                                                   

Raphael Tryster

This e-mail contains confidential, privileged or proprietary information to
VocalTec Communications.
If you received this messege by mistake, please inform us and then delete
the original and all copies.
*** eSafe scanned this email for viruses, vandals, and malicious content.
***
**********************************************************************************************