Re: Fwd: ReservedGroup Usage for IPV4-IPv6 calls

1st Don't refer to any RFCs ("RFC 5125 Reclassification of RFC 3525<http://tools.ietf.org/html/rfc3525> 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:[email protected]]
Sent: Montag, 9. August 2010 16:32
To: Schwarz, Albrecht (Albrecht)
Cc: [email protected]
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) <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of raj kumaradass
Sent: Montag, 9. August 2010 12:40
To: [email protected]<mailto:[email protected]>
Subject: [Megaco] Fwd: ReservedGroup Usage for IPV4-IPv6 calls

Resending the email.


---------- Forwarded message ----------
From: raj kumaradass <[email protected]<mailto:[email protected]>>
Date: Wed, Jul 14, 2010 at 10:52 AM
Subject: ReservedGroup Usage for IPV4-IPv6 calls
To: [email protected]<mailto:[email protected]>


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
[email protected]
https://www.ietf.org/mailman/listinfo/megaco