Subject: [Megaco] SDP question - scope of $ in m= line fmt parameter

From: "Matia Marcu" <[email-masked]>
Date: Mon, 19 Oct 2009 13:10:24 +0200

According to rfc 4566, it is possible to use "$" in the fmt field of the
media description lines.

Does the "$" cover a mixture of fixed and dynamic payloads? For example:
is the following exchange legal (assuming ReserveValue=true)?

command:         m=audio $ RTP/AVP $

reply:                m=audio 4444 RTP/AVP 8 18 120 13

                        a=rtpmap:120 telephone-event/8000

a=fmtp:120 0-15

a=fmtp:18 annexb=yes

Many thanks,

Matia

---

From: Javi <[email-masked]>
Date: Mon, 19 Oct 2009 13:21:36 +0200

When an optional secondary unit of a MG detects a maintenance or failure 
outage of the
primary MG unit and the primary is unable to notify the MGC of the 
failure, the secondary
MG shall send a ServiceChange Command to the MGC with ServiceChangeMethod
"Failover"

How does secundary MG detects that primary MG is failing?, may primary 
MG sends
any command warning about it?

Javi

---

From: "Raphael Tryster" <[email-masked]>
Date: Mon, 19 Oct 2009 13:27:15 +0200

By whatever proprietary means are available in the design of the MG.  It
is outside the scope of Megaco.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Javi
Sent: Monday, 19 October 2009 1:22 PM
To: [email-masked]
Subject: [Megaco] Failover

outage of the
primary MG unit and the primary is unable to notify the MGC of the 
failure, the secondary
MG shall send a ServiceChange Command to the MGC with
ServiceChangeMethod
"Failover"

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

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Mon, 19 Oct 2009 13:30:51 +0200

Peer-to-peer synchronization (& notification) protocols between primary
and secondary H.248 entities (e.g. MG_primary to MG_secondary,
MGC_primary to MGC_secondary, MGC_primary to MGC_2nd,secondary, etc) are
OUT OF SCOPE of H.248.
See also H.Sup7.

This limits such type of changeover scenarios, you got in mind, to
"intra-vendor failovers" (e.g. all primary and secondary entities from
the same manufactures). Inter-vendor failovers would require an
agreement on a common interface.

Please note that this is not limiting other, well-known changeover
scenarios. They may be all provided in inter-vendor environments ...

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Javi
> Sent: Montag, 19. Oktober 2009 13:22
> To: [email-masked]
> When an optional secondary unit of a MG detects a maintenance 
> or failure outage of the primary MG unit and the primary is 
> unable to notify the MGC of the failure, the secondary MG 
> shall send a ServiceChange Command to the MGC with 
> ServiceChangeMethod "Failover"
> 
> How does secundary MG detects that primary MG is failing?, 
> may primary MG sends any command warning about it?
> 
> Javi

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 20 Oct 2009 02:52:55 +0200

Matia,
 
three comments:
 
1) relevant SDP for H.248 is defined in § 7.1.8/H.248.1, and not in RFC 4566
    -> below a copy of H.248.1 Version 3 Amendment 2 ("the latest text on that subject")
    => still RFC 2327 is here referred!
 
2) please have a look in  H.248.49 Gateway control protocol: Session description protocol RFC and capabilities packages  
    => see App. I wrt RFC 2327 vs 4566 (below copied text)
 
3) Allowed wildcarding in SDP lines in H.248 LD/RDs: see H.248.39 Gateway control protocol: H.248 SDP parameter identification and wildcarding 
    => your question is addressed in H.248.39

Further: use of SDP is also subject of H.248 profile specifications. See eg. ETSI TISPAN 283 018 and 183 018 concerning allowed SDP for that H.248 border gateway profiles.
 
-Albrecht

Copied text: 
H.248.1 Version 3 Amendment 2:
7.1.8.1.1   Specific syntax for H.248 text encoding

7.1.8.1.1.1          Rules

When text encoding the protocol, the descriptors consist of session descriptions as defined in SDP ([IETF RFC 2327]). In session descriptions sent from the MG to the MGC, the SDP must comply with [IETF RFC 2327].  In session descriptions sent from the MGC to the MG, the following exceptions to the syntax of [IETF RFC 2327] are allowed:

*            the "s = ", "t = " and "o = " lines are optional;

*            the use of CHOOSE is allowed in place of a single parameter value; and

*            the use of alternatives is allowed in place of a single parameter value.

A Stream Descriptor specifies a single bidirectional media stream, a session description consists of a session-level section followed by a media-level section and so a single session description must not include more than one media description ("m = " line). A session description should not contain duplicate SDP lines on session-level and media-level. If duplication occurs the media level line takes precedence.

A Stream Descriptor may contain additional session descriptions as alternatives. Each media stream for a termination must appear in distinct Stream Descriptors. When multiple session descriptions are provided in one descriptor, the "v = " lines are required as delimiters; otherwise they are optional in session descriptions sent to the MG. Implementations shall accept session descriptions that are fully conformant to RFC 2327 according to the above restrictions. 

If a MG does not understand the SDP provided rather than ignoring that piece of SDP an appropriate error response shall be provided.

7.1.8.1.1.2          Summary - H.248 usage of SDP

Figure 10 provides an overview of the structure of the H.248 Media Descriptor. SDP is used within the H.248 Stream Descriptor in the Local Descriptor (LD) and Remote Descriptor (RD). There are thus separate SDP specifications for ingress traffic (provided by the H.248 LD) and egress traffic (provided by the H.248 RD). The (SDP) media description within that SDP block is reflected in the LD and RD and determines the H.248 media gateway behaviour. 

Figure 10 - Overview Structure of H.248 Media Descriptor 
(H.248 "Media Descriptor" vs SDP "Media Description")

----
H.248.49
Appendix I

Comparison of SDP variants between RFC 4566 and RFC 2327

(This appendix does not form an integral part of this Recommendation)

This Appendix provides a comparison between the two core RFCs for SDP.

I.1     Introduction

Local Descriptor (LD) and Remote Descriptor (RD) consisting of "session" descriptions are based on the Session Description Protocol (SDP) when text encoding is used for the H.248 gateway control protocol (see clause 7.1.8/[ITU-T H.248.1]). SDP information elements are as a consequence embedded in the H.248 protocol syntax. The "text codec" for H.248 Messages (i.e. the encoder/decoder for Annex B/[ITU-T H.248.1] text mode) comprises therefore an SDP encoder/decoder in addition to the basic H.248 encoder/decoder.

The core SDP is specified in [IETF RFC 4566], which obsoletes [IETF RFC 2327]. There are many additional RFCs available, which extend SDP. Figure I.1 illustrates the purpose of this Appendix and indicates only some other SDP RFCs, which may be of particular importance for H.248/SDP implementations.

Figure I.1 - SDP evolution and primary scope of this Appendix

The differences between [IETF RFC 4566] and [IETF RFC 2327] are listed in clause I.2. Specific conclusions for H.248/SDP implementations are summarized in clause I.3.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Matia Marcu
	Sent: Montag, 19. Oktober 2009 13:10
	To: [email-masked]
	Subject: [Megaco] SDP question - scope of $ in m= line fmt parameter

	According to rfc 4566, it is possible to use "$" in the fmt field of the media description lines.

	Does the "$" cover a mixture of fixed and dynamic payloads? For example: is the following exchange legal (assuming ReserveValue=true)?

	a=fmtp:120 0-15

	a=fmtp:18 annexb=yes

	Many thanks,

	Matia