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: "Kevin Boyle" <[email-masked]>
Date: Thu, 17 Oct 2002 06:00:15 -0400

All,

I have done some thinking on this, and it seems to me that we actually have
two pieces of the same puzzle here:

1. MGC-MG Local "negotiation" via underspecified SDP from the MGC
2. MG-MG Remote negotiation

In piece 1, the MGC can put restrictions upon the MG's chosen SDP options by
sending underspecified (or, I suppose, fully specified) SDP.  In this case,
we may or may not want the MG to reject a particular SDP if it cannot
comply.

In piece 2, the far-end and near MGs must find some common ground to set up
the bearer.

In 1, I agree that this is a master-slave relationship.  However, in 2 it is
clear to me that this is a peer-peer relationship, even though the Remote
descriptor is being passed to the MG by the MGC, and may have been altered
by the MGC.

So, I assume we are limiting our scope to piece 1.  Even therein, it is hard
to determine what should constitute an error, and what should not.  For
example, if the MGC is specifying bandwidth limitation that the MG cannot
comply with, then we have a potential billing problem that the MGC probably
should know about.  On the other hand, if the a line is specifying that the
MG should be looking for 2833 events 0-255, and it can only do 0-15, should
that generate an error?  I wouldn't think so, as it probably has no bearing
on the call as a whole.

Because it is very hard to specify which parts of SDP should cause errors
and which should not without, essentially, writing a new "H.248 SDP"
specification, we should be very careful how we tread here.  Christer's idea
about using profiles to convey whether the MGC wants the MG to ignore or
nack unknown/unsupported SDP options is interesting, and bears further
investigation.

I think we need to put some serious thought into how all this will work, and
we also need to attempt to minimize further divergence from the rest of the
SDP world.  I believe that we want to provide something that will minimize
error scenarios and maximize bearer setup successes, while still maintaining
the integrity of the MGC master role as it relates to the MG.  I,
personally, am unable to commit to a particular option at this time, until I
get the chance to do a little more analysis of the consequences of choosing
any of the options laid out earlier by Terry.

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Thursday, October 17, 2002 4:56 AM
To: Terry L Anderson
Cc: megaco Mailing List
Subject: Re: [Megaco] Non-standard a lines in SDP

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

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.
> 
> #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.
> 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: "Kevin Boyle" <[email-masked]>
Date: Thu, 17 Oct 2002 06:00:15 -0400

All,

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Thursday, October 17, 2002 4:56 AM
To: Terry L Anderson
Cc: megaco Mailing List
Subject: Re: [Megaco] Non-standard a lines in SDP

G'Day Terry,

Regards, Christian