raj kumaradass | 9 Aug 12:39 2010
Picon

Fwd: ReservedGroup Usage for IPV4-IPv6 calls

Resending the email.


---------- Forwarded message ----------
From: raj kumaradass <rajkumaradass <at> gmail.com>
Date: Wed, Jul 14, 2010 at 10:52 AM
Subject: ReservedGroup Usage for IPV4-IPv6 calls
To: megaco <at> ietf.org


Greetings,


Would like to know if the below handling of reservedGroup&underspecified SDP are valid:

Originating Side MG1(IPV6) -- MGC (supports both IPv4/IPv6) --Terminating MG2 (IP details Not Yet known)

When there's notification for offhook msg reported from the MG 1, the next transaction which consists of AddTermination to context, Apply dialtoneSG to physical term, requset on/flashhook from phy.term and add eph. termination ctxt.  Along with this, when there's a underspecified SDP to be sent in the Local SDP, it's mandatory to set the reserveredGroup flag to ON in LCO and include underspecified sessiondescriptors for IPV4 & IPV6, since the terminating side support is not known at this point.

Appreciate your inputs.

thanks,
...Raj


_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco

Re: Fwd: ReservedGroup Usage for IPV4-IPv6 calls

[MG1 supports only IPv6, right? Or supports MG1 dual-stack?]
 
There are multiple call & gateway control options from perspective of the MG1-associated MGC:
 
1st Clarify IP version first end-to-end on call control level
    Implies SDP Offer/Answer in case of SIP.
    The MGC may use "a=ccap" (draft-ietf-mmusic-sdp-misc-cap) and potential configurations.
 
2nd Parallel establishment of IP transport connection in bearer plane.
If MG1 supports only IPv6, then just exact specification
If MG1 supports dual-stack, then two local destination IP transport endpoints may be reserved ... (with preference on IPV6).
 
Thus, multiple options, nothing normative from my understanding.
 

From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of raj kumaradass
Sent: Montag, 9. August 2010 12:40
To: megaco <at> ietf.org
Subject: [Megaco] Fwd: ReservedGroup Usage for IPV4-IPv6 calls

Resending the email.


---------- Forwarded message ----------
From: raj kumaradass <rajkumaradass <at> gmail.com>
Date: Wed, Jul 14, 2010 at 10:52 AM
Subject: ReservedGroup Usage for IPV4-IPv6 calls
To: megaco <at> ietf.org


Greetings,


Would like to know if the below handling of reservedGroup&underspecified SDP are valid:

Originating Side MG1(IPV6) -- MGC (supports both IPv4/IPv6) --Terminating MG2 (IP details Not Yet known)

When there's notification for offhook msg reported from the MG 1, the next transaction which consists of AddTermination to context, Apply dialtoneSG to physical term, requset on/flashhook from phy.term and add eph. termination ctxt.  Along with this, when there's a underspecified SDP to be sent in the Local SDP, it's mandatory to set the reserveredGroup flag to ON in LCO and include underspecified sessiondescriptors for IPV4 & IPV6, since the terminating side support is not known at this point.

Appreciate your inputs.

thanks,
...Raj


_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
raj kumaradass | 9 Aug 16:32 2010
Picon

Re: Fwd: ReservedGroup Usage for IPV4-IPv6 calls

MG1 and MGC supports dual stack.  In such cases, a underspecified SDP template alike below will be included with RG set to required in the Add msg:

M{
O{MO=RC,RV=NOTREQ,RG=REQUIRED},
L{
v=0
c=IN IP6 $
t=0 0
m=audio $ RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:10
v=0
c=IN IP4 $
t=0 0
m=audio $ RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:10
}

Is the above approach valid? And also would like to know if there are any guidelines/standards available upon the usage of reservedGroup, as RFC3525 does elaborates little on this.

thanks,
...Raj

On Mon, Aug 9, 2010 at 5:14 PM, Schwarz, Albrecht (Albrecht) <albrecht.schwarz <at> alcatel-lucent.com> wrote:
[MG1 supports only IPv6, right? Or supports MG1 dual-stack?]
 
There are multiple call & gateway control options from perspective of the MG1-associated MGC:
 
1st Clarify IP version first end-to-end on call control level
    Implies SDP Offer/Answer in case of SIP.
    The MGC may use "a=ccap" (draft-ietf-mmusic-sdp-misc-cap) and potential configurations.
 
2nd Parallel establishment of IP transport connection in bearer plane.
If MG1 supports only IPv6, then just exact specification
If MG1 supports dual-stack, then two local destination IP transport endpoints may be reserved ... (with preference on IPV6).
 
Thus, multiple options, nothing normative from my understanding.
 

From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of raj kumaradass
Sent: Montag, 9. August 2010 12:40
To: megaco <at> ietf.org
Subject: [Megaco] Fwd: ReservedGroup Usage for IPV4-IPv6 calls

Resending the email.


---------- Forwarded message ----------
From: raj kumaradass <rajkumaradass <at> gmail.com>
Date: Wed, Jul 14, 2010 at 10:52 AM
Subject: ReservedGroup Usage for IPV4-IPv6 calls
To: megaco <at> ietf.org


Greetings,


Would like to know if the below handling of reservedGroup&underspecified SDP are valid:

Originating Side MG1(IPV6) -- MGC (supports both IPv4/IPv6) --Terminating MG2 (IP details Not Yet known)

When there's notification for offhook msg reported from the MG 1, the next transaction which consists of AddTermination to context, Apply dialtoneSG to physical term, requset on/flashhook from phy.term and add eph. termination ctxt.  Along with this, when there's a underspecified SDP to be sent in the Local SDP, it's mandatory to set the reserveredGroup flag to ON in LCO and include underspecified sessiondescriptors for IPV4 & IPV6, since the terminating side support is not known at this point.

Appreciate your inputs.

thanks,
...Raj



_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco

Re: Fwd: ReservedGroup Usage for IPV4-IPv6 calls

1st Don't refer to any RFCs ("RFC 5125 Reclassification of RFC 3525 to Historic"), rather instead to the ITU-T H.248.x-series of Recommendations!
 
2nd IP transport: don't mix the IP transport of
    a) H.248 non-Root "IP terminations" ("bearer plane")
    b) H.248 Control Association ("control plane")
 
Just (b) relates to MGC capabilities, please refer to H.248.67 for instance.
Concerning your scenario (-> a), it doesn't take any effect whether the MGC supports IP interfaces of IPv4 only, IPv6 only or dual stack!
That hasn't any impact on the H.248 signalling scenario!
 
3rd ReserveGroup for two IP transport connection endpoints in bearer plane
-> your scenario looks OK on a first glance ("the specific encoding might be incorrect, e.g. the value of ReserveGroup")
 
-Albrecht
 

From: raj kumaradass [mailto:rajkumaradass <at> gmail.com]
Sent: Montag, 9. August 2010 16:32
To: Schwarz, Albrecht (Albrecht)
Cc: megaco <at> ietf.org
Subject: Re: [Megaco] Fwd: ReservedGroup Usage for IPV4-IPv6 calls

MG1 and MGC supports dual stack.  In such cases, a underspecified SDP template alike below will be included with RG set to required in the Add msg:

M{
O{MO=RC,RV=NOTREQ,RG=REQUIRED},
L{
v=0
c=IN IP6 $
t=0 0
m=audio $ RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:10
v=0
c=IN IP4 $
t=0 0
m=audio $ RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:10
}

Is the above approach valid? And also would like to know if there are any guidelines/standards available upon the usage of reservedGroup, as RFC3525 does elaborates little on this.

thanks,
...Raj

On Mon, Aug 9, 2010 at 5:14 PM, Schwarz, Albrecht (Albrecht) <albrecht.schwarz <at> alcatel-lucent.com> wrote:
[MG1 supports only IPv6, right? Or supports MG1 dual-stack?]
 
There are multiple call & gateway control options from perspective of the MG1-associated MGC:
 
1st Clarify IP version first end-to-end on call control level
    Implies SDP Offer/Answer in case of SIP.
    The MGC may use "a=ccap" (draft-ietf-mmusic-sdp-misc-cap) and potential configurations.
 
2nd Parallel establishment of IP transport connection in bearer plane.
If MG1 supports only IPv6, then just exact specification
If MG1 supports dual-stack, then two local destination IP transport endpoints may be reserved ... (with preference on IPV6).
 
Thus, multiple options, nothing normative from my understanding.
 

From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of raj kumaradass
Sent: Montag, 9. August 2010 12:40
To: megaco <at> ietf.org
Subject: [Megaco] Fwd: ReservedGroup Usage for IPV4-IPv6 calls

Resending the email.


---------- Forwarded message ----------
From: raj kumaradass <rajkumaradass <at> gmail.com>
Date: Wed, Jul 14, 2010 at 10:52 AM
Subject: ReservedGroup Usage for IPV4-IPv6 calls
To: megaco <at> ietf.org


Greetings,


Would like to know if the below handling of reservedGroup&underspecified SDP are valid:

Originating Side MG1(IPV6) -- MGC (supports both IPv4/IPv6) --Terminating MG2 (IP details Not Yet known)

When there's notification for offhook msg reported from the MG 1, the next transaction which consists of AddTermination to context, Apply dialtoneSG to physical term, requset on/flashhook from phy.term and add eph. termination ctxt.  Along with this, when there's a underspecified SDP to be sent in the Local SDP, it's mandatory to set the reserveredGroup flag to ON in LCO and include underspecified sessiondescriptors for IPV4 & IPV6, since the terminating side support is not known at this point.

Appreciate your inputs.

thanks,
...Raj



_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Christian Groves | 31 Aug 09:06 2010

Result for July ITU-T Q.3/16 meeting

Hello all,

FYI, the results of the July Q.3/16 meeting are now publicly available at:
http://wftp3.itu.int/av-arch/avc-site/2009-2012/1007_Gen/

H_248_48.zip

	

Editor's output of draft new H.248.48 (ex H.248.QHR), "Gateway Control 
Protocol: RTCP XR Block Reporting Package"

H_248_50.zip

	

Draft new ITU-T Rec. H.248.50 (ex H.248.NATTT) “Gateway control 
protocol: NAT Traversal Toolkit Packages” for Consent

H_248_66.zip

	

H.248.66 (ex H.248.RTSP) “Packages for RTSP and H.248 interworking”: 
Output Draft

H_248_73.zip

	

Draft new ITU-T Rec. H.248.73 (ex H.248.MSCML) “Gateway control 
protocol: Packages for MSCML and H.248 interworking” for Consent

H_248_74.zip

	

H.248.74 (ex H.248.MRCP) “Media Resource Control enhancement Packages”: 
Output Draft

H_248_75.zip

	

H.248.75 (ex. H.248.PIPA) “Package Identifier Publishing and Application 
Package”: Output Draft

H_248_76.zip

	

Draft new ITU-T Rec. H.248.76 (ex H.248.Filter) “Gateway Control 
Protocol: Filter Group Package and Guidelines” (for Consent)

H_248_77.zip

	

Draft new ITU-T Rec. H.248.77 (ex H.248.SRTP) “Gateway Control Protocol: 
SRTP Package and Procedures” (for Consent)

H_248_78.zip

	

Draft new H.248.78 (ex H.248.ALG) “Bearer-level Application Level 
Gateway” (for Consent)

H_248_79.zip

	

H.248.79 (ex H.248.Packets) “Gate Control Protocol: Guidelines for 
Packet-Based Streams”: Input draft

H_248_80.zip

	

Output draft of new H.248.80 (ex H.248.SDPMapper) “Usage of the revised 
SDP offer / answer model with H.248”

H_248_DPI.zip

	

H.248.DPI “Gateway control protocol: H.248 Support for Deep Packet 
Inspection”: Output draft (Ed. 0.2)

H_248_ETS.zip

	

H.248.ETS “Gateway Control Protocol: Guidelines on the Use of the IEPS 
Call Indicator and Priority Indicator in H.248 Profiles”: Output Draft

H_248_IG.zip

	

Draft revised H.248 Sub-series Implementors’ Guide (for Approval)

H_Supp_2.zip

	

Draft revised H-Series Supplement 2: “H.248.x sub-series packages guide 
– Release 14” (for Approval)

Q3_Report.zip

	

Report of Question 3/16 “Multimedia Gateway Control Architectures and 
Protocols”

Regards, Christian

Gmane