Subject: [Megaco] Non-standard a lines in SDP

From: Terry L Anderson <[email-masked]>
Date: Wed, 16 Oct 2002 09:10:54 -0400

RFC 2327 on SDP states:

> Some attributes (the ones listed in this document) have a defined
>    meaning but others may be added on an application-, media- or
>    session-specific basis.  A session directory must ignore any
>    attribute it doesn't understand.

Behavior of an MG when it receives a descriptor containing SDP with an a 
line it does not understand is not well defined in H.248.  Possible 
behaviors are:

1. accept the command, ignore the attribute it does not understand and 
respond as normal, with no descriptor, if there were no wildcards, or if 
there are wildcards, with a descriptor containing the selected values of 
wildcards but including the a line it does not understand.

2. same as #1, except omitting the a line it does not understand so that 
MGC is aware of the fact that it will not use the attribute

3. reject the command with an Unsupported error but no indication of 
which a line is unsupported.

4. reject the command with an Unsupported error but indicating the a 
line(s) unsupported by returning the descriptor with the unsupported a 
line(s) removed

5. same as #4 except that only the unsupported lines are returned rather 
than SDP with these removed.

#1,2 seem to be most compatible with the RFC's "ignore" behavior
#1 leaves the MGC unaware of the fact that the attribute will not be 
used.  This seems unacceptible.
#2 gives the info, but if the MGC prefers to not make the connection 
without it, it must send a Modify or Subtract but the connection will 
exist for a brief time without it.
#3-5 avoid the problem of #2, but introduces more delay if the MGC 
wishes to make the connection anyway (if it was really optional) and 
must resend the command without the line..
#3 may require "polling" to discover which a line is unsupported (if 
there were more than one non-standard line).
#4 avoids this but MGC must use a "diff" to find which was omitted.
#5 may be simplest but means that the returned descriptor will not be 
valid SDP (no v= line,...) and so MGC may not have a parser that can 
handle the isolated a line.

Christian Groves has argued (in a private discussion) that what we send 
between MGC and MG is not a session proposal (peer-to-peer) as most 
other uses of SDP but rather a command to MG (master-slave), so the 
"ignore" behavior is not appropriate here and MG should reject the 
command (#3-5).

Another argument is to use the solution that introduces the least delay 
or least extra traffic, but that depends on whether the MGC will most 
often ignore the lack of support or will drop the connection or modify 
it in some other way in response to lack of support.

After considering all these, I tend toward #4.  Are there other opinions.

Another issue is whether the MG can ADD an additional a line to the SDP 
and return this in the response (even if there was no wildcard in the 
SDP sent).  7.1.8 states:

> 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).

This appears to allow the addition of a lines (although these may not 
always be "mandatory").

I suggest that we choose one of the choices for the first problem for 
the Implementors Guide and consider whether a slight rewording is needed 
for the second issue.

-- 

------------------------------------------------------------
Terry L Anderson, CMTS          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

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

---

From: Troy Cauble <[email-masked]>
Date: Wed, 16 Oct 2002 10:52:39 -0400

Note that the RFC quote refers to media attribute lines (a=*).
Anything that is not (a=*) and not understood should definitely
be rejected.

The larger RFC 2327 quote is:

>   The set of `type' letters is deliberately small and not intended to
>   be extensible -- SDP parsers must completely ignore any announcement
>   that contains a `type' letter that it does not understand. The
>   `attribute' mechanism ("a=" described below) is the primary means for
>   extending SDP and tailoring it to particular applications or media.
The first part of the paragraph refers to a "parser" ignoring an 
"announcement".
We could try to be pedantic and treat the H.248 message as if there was no
SDP portion, but I think rejection is appropriate in this case.  An 
invalid SDP
portion causes an H.248 message to be invalid.

The rest of the paragraph clearly states that attribute lines (a=*) are 
an extension
mechanism and such *LINES* that are not understood should be ignored.

For the case of an MG receiving a Remote Descriptor, I think we should honor
that and just ignore the line (this is close to #2 below, without the 
stuff about
returning descriptors).

For the case of an MG receiving a Local Descriptor (which is what Terry is
addressing below), I think #2 is best because it is closest to the case 
above
and the MGC can always stop things if it doesn't like the reply.

-troy

Terry L Anderson wrote:

> Behavior of an MG when it receives a descriptor containing SDP with an 
> a line it does not understand is not well defined in H.248.  Possible 
> behaviors are:
>
> respond as normal, with no descriptor, if there were no wildcards, or 
> if there are wildcards, with a descriptor containing the selected 
> values of wildcards but including the a line it does not understand.
>
> 2. same as #1, except omitting the a line it does not understand so 
> that MGC is aware of the fact that it will not use the attribute
>
> 5. same as #4 except that only the unsupported lines are returned 
> rather than SDP with these removed.
>
> Christian Groves has argued (in a private discussion) that what we 
> send between MGC and MG is not a session proposal (peer-to-peer) as 
> most other uses of SDP but rather a command to MG (master-slave), so 
> the "ignore" behavior is not appropriate here and MG should reject the 
> command (#3-5).
>
> Another argument is to use the solution that introduces the least 
> delay or least extra traffic, but that depends on whether the MGC will 
> most often ignore the lack of support or will drop the connection or 
> modify it in some other way in response to lack of support.
>
> Another issue is whether the MG can ADD an additional a line to the 
> SDP and return this in the response (even if there was no wildcard in 
> the SDP sent).  7.1.8 states:
>
> the Implementors Guide and consider whether a slight rewording is 
> needed for the second issue.
>

---

From: Troy Cauble <[email-masked]>
Date: Wed, 16 Oct 2002 10:52:39 -0400

-troy

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2002 19:55:22 +0300

Hi,

After a first look, I would probably also go for some of the reject solutions
(#3-5).

HOWEVER, before making any decission I think we should think about the
purpose of H.248 PROFILES, and how/if they can be used in this case.

Assume that the specific profile defines which attributes the MG supports.

Now, arguing that the MGC shall make sure no other attributes are used,
solution #3-5 I probably the best solution, because the MGC does something
wrong.

But, arguing that the MGC should not "filter" any attributes (it may eg have
received the SDP from a remote SIP endpoint), except attributes we don't use
in H.248 in the first place, solution #1-2 could work, since the profile
would tell that those attributes are going to be ignored.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2002 19:55:22 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christian Groves <[email-masked]>
Date: Thu, 17 Oct 2002 18:55:58 +1000

G'Day Terry,

I think rather than looking at this from a parsing perspective we have to look
from more of a network view. SDP in H.248 is used in a MasterSlave relationship
rather than the peer to peer relationship as used in SIP. This I believe imposes
slightly different rules. The MGC typically orders the MG to perform particular
functionality and it should be aware if the MG has not implemented it. Therefore
I think any scenario whereby the MG does not report back to the MGC that it has
not implemented something is flawed. eg. The MGC may be charging for certain
characteristics and if the MG doesn't implement all these characteristics then
this is an overcharging situation. I'm sure end-user will not be happy with this
and will complain to their operator and I think its safe to assume that the
operator will come looking for the vendor that implemented it such a way. So 1
is definately not an option. 

Option 2 falls into something similar. You have an MG that may through connect a
bearer that has the incorrect characteristics. The MGC once it finds out would
have to release this bearer and re-establish/modify a bearer. This causes a
higher load for the MGC/MG and intermediate switching network that is largely
unnecessary. Again operators don't paricularly like this situation and will
complain that this occurs. So option 2 from a network perspective is not
desirable.

That then leaves options 3-5. From a network perspective this is better because
resources (other than H248 stack processing) are not seized avoiding the problem
of unecessary signalling and load. 3 is less desirable than 4 and 5 because the
error is very helpful as you don't know what line is invalid. 

So from my point of view option 4 and 5 are the most applicable solutions.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Thu, 17 Oct 2002 18:55:58 +1000

G'Day Terry,

Regards, Christian