Subject: FW: Application for port-number

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 12 Jan 2000 13:35:19 -0600

I've requested a single port number pair (TCP/UDP) for Megaco/H.248.  See
below.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Wednesday, January 12, 2000 2:29 PM
> To:   [email-masked]; Taylor, Tom-PT [CAR:B904:EXCH]
> Subject:      Application for port-number
>
> Name :
> Tom Taylor
>
> E-mail :
> [email-masked]
>
> Protocol Number :
> TCP & UDP
>
> Message Formats :
> For full documentation see ITU-T Recommendation H.248 (RFC number
> forthcoming).
> Message overhead consists of ptional authentication header, protocol name
> (MEGACO) and version, and an originator identifier. The body of the
> message
> consists of one or more independent transaction requests or responses, or
> an
> error response to an indecipherable message.  The protocol comes in
> text-encoded
> and ASN.1 BER binary-encoded versions.
>
> Message Types :
> A message is just a transport container for transactions and their
> responses.
> Except for the authentication header, the message overhead should be the
> same
> for every message from the same originator.
>
> Message opcodes :
> Not applicable at the message level.  Transactions contain actions
> which contain commands.  The possible commands are Add, Modify, Move,
> Subtract,
> AuditCapability, AuditValue, and ServiceChange.
>
> Message Sequences :
> Not applicable at the message level.  TransactionRequests within messages
> will be followed by TransactionReply or TransactionPending responses.  The
> same message may contain multiple transactions (requests and/or
> responses), which are independent of each other.
>
> Protocol functions :
> The protocol operates between a Media Gateway Controller and a Media
> Gateway
> to control the connection and manipulation of media streams through the
> latter,
> typically in the provision of IP telephony or multimedia conferencing
> service.
>
> Broadcast or Multicast used ?
> no
>
> How and what for Broadcast or Multicast is used (if used):
>
>
> Range for port number :
> user port
>
> Description :
> This will be a rendezvous port through which the Media Gateway registers
> its
> presence with a Media Gateway Controller.  Assignment of a well-known port
>
> simplifies administration of the Media Gateway and Controller.
>
> The Media Gateway has the option to use either UDP or TCP.  The Media
> Gateway
> Controller has the option to assign an alternative address and/or port for
>
> establishment of the association, but must respect the initial choice of
> protocol.
>
> Name of the port :
> Megaco/H.248
>
>
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 14 Jan 2000 10:21:47 -0500

>I've requested a single port number pair (TCP/UDP) for Megaco/H.248.  See

In fact, it would make sense to require separate port numbers for the MG
and for the MGC, to facilitate the writing of ACL in firewalls or similar
devices. Also, it might make sense to use separate port numbers for the
text and ASN.1 encodings -- that would limit confusion.
-- Christian Huitema

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 14 Jan 2000 12:15:03 -0500

The key differentiator is the presence or absence of the word MEGACO in text
encoding.  ASN.1 has its own well-defined structure, of course, so an
ASN.1-savvy implementation will be able to pick that out quickly enough.

> From: Rayhan, Abdallah [CAR:5N00:EXCH] [SMTP:[email-masked]]
> Sent: Friday, January 14, 2000 11:51 AM
> To:   Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]
> Cc:   [email-masked]
> Subject:      Re: FW: Application for port-number
>
> Either a different port or a BinaryToken in the ASN.1 to differentiate
> binary and text. Or the other way around in the ABNF, e.g., you look
> for a particular token  at the beginning the message. If present then
> binary encoding is assumed, otherwise text encoding.
>
> Abdallah Rayhan
>
>
> "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:
>
>
>
>       On your first point, the only purpose of these ports is to give the
> MG somewhere to go to initiate the association.  If it's TCP, the MG port
> is fixed at that point.  If it's UDP, the MG can signal which port it
> wants to receive at.
>
>       I thought about your second point, but figured the outcome would be
> the same, regardless: if the MGC doesn't understand a particular encoding,
> it will have no choice but to ignore the association attempt, since it
> won't even be able to recognize the protocol.  Perhaps that's a hole we
> should fix so the MG can at least be told that the MGC doesn't understand
> it.
>
>       From:   Christian Huitema [SMTP:[email-masked]]
>       Sent:   Friday, January 14, 2000 10:22 AM
>       To:     Taylor, Tom-PT [CAR:B904:EXCH];
> [email-masked]
>       Subject:        Re: FW: Application for port-number
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 14 Jan 2000 20:45:38 -0600

Good point.  And I'm thinking that the ServiceChange command itself is
buried rather deeply in the message, so if we do stay with one port, the
requirement should be softened to recognition of a Meggaco/H.248 message.

So, is convenience worth the consumption of another port?

> From: Michael Thomas [SMTP:[email-masked]]
> Sent: Friday, January 14, 2000 6:26 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]
> Tom-PT Taylor writes:
>  > Further to this point, I would propose the following modification to
> section
>  > 7.2.9.  Following the sentence "MGCs should support both  encoding
>  > formats.": add the sentence: "If an MGC does not support a given
> encoding
>  > method, it MUST at least be able to recognize a ServiceChange command
> within
>  > that encoding and be able to return an error reply indicating error 501
> -
>  > Not implemented."
>
>    If you have different ports for text and binary
>    (which I think is by far the most sensible), an
>    MGC would just not listen on that port which
>    would generate a host unreachable ICMP when the
>    MG tried to send a message. If an MG sees that
>    and has the capability to switch over, it would
>    just look at the ECONNREFUSED and use that as
>    the cue to try the other port/encoding.
>
>    Seems a whole lot easier to me.
>
>        Mike