Subject: [Megaco] Remote descriptor question

From: Christer Holmberg <[email-masked]>
Date: Wed, 05 Jun 2002 13:07:36 +0300

Hi,

Assume my MGC wants to initiate a session. It sends down the following
Local descriptor in the ADD request:

Local {
    v=0
    c=IN IP4 $
    m=audio $ 0
}

In the reply the MG sends the following Local Descriptor, indicating its
media receiving capabilities:

Local {
    v=0
    c=IN IP4 123.45.67.89
    m=audio 20000 0
}

Now, according to chapter 7.1.8 the MG shall also return a remote
descriptor, indicating the SENDING capabilities:

Remote {
    v=0
    c=IN IP4 XXXX
    m=audio YYYY 0
}

My question is: HOW does the MG know the values of the remote IP address
(XXXX) and the remote IP port (YYYY)? It will not get them until it has
contacted the remote party, when it will send a MODIFY request to the
MG, including the remote capabilities in a remote descriptor.

Shall the MG use "$" for the address and port?

Regards,

Christer Holmberg
Ericsson Finland

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

---

From: Shambhu Dayal Rai <[email-masked]>
Date: Wed, 05 Jun 2002 16:34:29 +0530

Hi Christer,

	I had an impression that Remote descriptor will be returned from the MG only if MG received the same in request from MGC.  Are you
suggesting  MG will send Remote descriptor with Some (junk or Choose) values in its response to MGC ? 

Could you please point me to the text, which gives such an impression ?

-Shambhu

-- 
-------------------------------------------------------------------
Shambhu Dayal Rai                              [email-masked] 
Infosys - India SQA Team              91-80-8520362 Ext. : 6561
-------------------------------------------------------------------

---

From: Shambhu Dayal Rai <[email-masked]>
Date: Wed, 05 Jun 2002 16:34:29 +0530

Hi Christer,

-Shambhu

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 05 Jun 2002 14:53:45 +0300

Hi,

> suggesting  MG will send Remote descriptor with Some (junk or Choose) values in its response to MGC ?

That's how I understand the spec...

> Could you please point me to the text, which gives such an impression ?

From chapter 7.1.8.

"The MGC uses Local and Remote descriptors to reserve and commit MG
resources for media decoding and encoding for the given Stream(s)
and Termination to which they apply.  The MG includes these
descriptors in its response to indicate what it is actually prepared
to support.  The MG SHALL include additional properties and their
values in its response if these properties are mandatory yet not
present in the requests made by the MGC (e.g., by specifying
detailed video encoding parameters where the MGC only specified the
payload type).

Local refers to the media received by the MG and Remote refers to
the media sent by the MG."

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 05 Jun 2002 14:53:45 +0300

Hi,

From chapter 7.1.8.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 05 Jun 2002 13:35:39 -0400

I don't believe that 7.1.8 means to suggest that the response contain a 
Local/Remote Descriptor not present in the request.  MG shall  include 
additional mandatory parameters to descriptors that are in the request 
but it should not add a Remote Descriptor where one was not present.  

item (a) does say:
    An unspecified Local or Remote descriptor is considered to be a 
missing mandatory parameter.  It requires the MG to USE whatever was 
last specified for that descriptor.  It is possible that there was no 
previously-specified value, in which cased the descriptor concerned is 
ignored in further processing of the command.

Note "USE" (my emphasis) does not imply "add to response".  If there was 
a previously specified value for the Remote descriptor, it would 
continue to apply, but if there was none, Remote has no properties until 
it is added in a future request.

See the example, in appendix A.1.2.  In step 12 the ephemeral is Added 
with only Local and LocalControl.  The response in step 13 does NOT add 
a Remote.

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked] 
Tel:732.949.5628   Fax:732.949.7016 
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 05 Jun 2002 13:35:39 -0400

item (a) does say:

--

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 06 Jun 2002 08:17:08 +0300

Hi,

I think one problem is that chapter 7.1.8 does only say that the Remote descriptor in the reply indicates what the MG is capable of sending.
When the MGC sends a Remote descriptor in a request, it does not indicate what the MG is supposed to send - it indicates what the remote party
is able to receive, and that is not mentioned.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 06 Jun 2002 08:17:08 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christian Groves <[email-masked]>
Date: Thu, 06 Jun 2002 15:38:49 +1000

G'Day Christer,

I think that its pretty much common sense that what the MG sends is the same as
what the remote MG receives. I support Terry's view.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 06 Jun 2002 15:38:49 +1000

G'Day Christer,

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 06 Jun 2002 08:45:55 +0300

Hi,

I also support Terry's view - because it is also my view :)

I just wanted to clarify, because I still DO think the spec is a little unclear on this issue.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 06 Jun 2002 08:45:55 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 06 Jun 2002 10:47:55 -0400

>is able to receive, and that is not mentioned.
I don't understand your distinction.  Remote DOES represent what MGC is 
telling MG to send.  If MGC instructs MG (in Remote) to send something 
that MGC does not know the peer MG can receive, it is a dumb MGC.  So 
the contents of Remote should also represent what the remote MG can 
receive, but it is up to MGC to know how to manage things.  How MGC 
makes management decisions is not part of the protocol and the protocol 
certainly allows MGCs to do very dumb things.  

--

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 06 Jun 2002 10:47:55 -0400

--