Re: Media flow managed by 2 terminations

Javi <[email protected]> Fri, 29 Jul 2011 13:45:57 +0200
Newsgroups gmane.ietf.megaco
Message-ID <[email protected]>
Albrecht,

The entire network picture is similar to "ETSI_ARGW[TS 183 002 
v3.3.1]/Clause 7.3.2" or "draft-bouwen-megaco-isdn-data-00":

ISDN TE <-> AGW (MG) <-> PH or FH <-> PSPDN

where PH "Packet Handler" and FH "Frame Handler" are different 
equipments (I propose a descomposal architecture for PH: "MGC-PH <-> 
AGW-PH(SG/MG-PH) <-> PSPDN"; and similar for FH)

So, AGW/MG terminates ISDN D-channel, and p-,f- LAPD frames would be 
sent to PH/FH. The IP termination may be: RawFR, IUA, XOT or PWs 
(HDLCPW, FRPW, TDMPW).

A D-channel packet mode outgoing call may start with a LAPD p-frame (PLP 
Restart) from ISDN TE, without previous Q.931 signalling. So, a 
D-channel physical termination is necessary in MG (MG detects that 
p-frame and sends a MeGaCo notify to MGC; then, MGC sends a SIP INVITE 
message to PH, signalling the call).

So, the D-channel physical termination would be neccessary. The doubt 
would be: two single-stream-per-terminations (an ephemeral termination 
per packet or frame connection, apart from the D-channel physical 
termination) versus one dual-stream-per-termination (only the D-channel 
physical termination with two StreamIDs).

PH and FH are different equipments, and D-channel supports simultaneous 
packet and frame connections. So, I don't understand alternative "3".

Javi



El 28/07/2011 10:43, Schwarz, Albrecht (Albrecht) escribió:
> Javi,
> I was hesitating to reply because I was wondering myself, whether I firstly got to know the entire network picture. So far we did consider just a "half-call" model by looking at one termination of the context only.
> However, I don't guess that the H.248 MG would be the termination point of the D-channel traffic, right?
>
> What would be the 2nd termination?
> Guess this information could clarify the intended function of the H.248 MG, e.g., by just "transparent forwarding" of D-channel frames, or any interworking (?), or ...?
>
> That information may provides answers
> to (3):
> E.g., the termination is initially configured for "TDM awareness", but "unawareness concerning D-channel traffic type". After detection the termination may become "aware of specific D-channel type frames" ... (but again, would be dependent on your aimed network use case).
> [Note: sth similar to IP-IP border gateways, initially configured in media-agnostic mode, possibly later modified to media aware modes, dependent on ...]
>
> to (a,b):
> The question concerning the alternatives of two single-stream-per-terminations versus one dual-stream-per-termination structure could dependent again on your network use case. (E.g., do you consider a physical or ephemeral termination; any common properties on termination level?)
>
> Just some thoughts, Albrecht
>
>
>
>    
>> -----Original Message-----
>> From: Javi [mailto:[email protected]]
>> Sent: Mittwoch, 27. Juli 2011 20:02
>> To:[email protected]
>> Cc: Schwarz, Albrecht (Albrecht)
>> Subject: Re: [Megaco] Media flow managed by 2 terminations
>>
>> Thanks Albrecht.
>>
>> I don't undesrtand your alternative "3)". May you clarify it?
>>
>> Also, if the D-channel carries p- or/and f-type frames, what
>> is preferable?:
>>
>> a) An ephemeral termination for each one (at least, for p-
>> anf f-frames).
>>
>> b) An streamID for each one (alternative "2").
>>
>> Thanks,
>>
>> Javi
>>
>>
>>
>>
>>
>> El 15/07/2011 13:24, Schwarz, Albrecht (Albrecht) escribió:
>>      
>>>> Does H.248.1 allow this?
>>>>
>>>>          
>>> I think so.
>>> Guess that following aspect might be also relevant:
>>>
>>> Does the D-channel carry
>>> a) just a single type of frames (e.g. exclusively X.25 traffic); or
>>> b) a multiplex of s-, p- or/and f-type frames (e.g., a mix
>>>        
>> of Q.921 signalling, X.25 packet and frame relay traffic).
>>      
>>> Possible alternatives to the considered ephemeral
>>>        
>> termination for the "X.25/D-channel/{16|64}TDM bearer":
>>      
>>> 1) static configuration, i.e., without any H.248 context,
>>>        
>> see ETSI TS
>>      
>>> 183002, § 7.3.2.2
>>> ->   using an X.25-over-SCTP bearer
>>> ->   7.3.2.4.2	IUA/SCTP for X.25 or frame relay traffic
>>>
>>> 2) H.248 Mux termination
>>> use case here: Figure 9 (ex 6)/H.248.1 - Multiplexed termination
>>> scenario - Single-to-multiple terminations
>>> ->   Circuit 1 = D-channel
>>> ->   StreamID = x: p-type (X.25) frames
>>>
>>> 3) SDP for TDM (old proposal: draft-taylor-mmusic-sdp-tdm-01.txt)
>>> ->   single physical termination
>>> ->   initially 'TDM'
>>> ->   after detection modified to 'PKT/TDM'
>>>
>>> The attributes
>>>      a=netprof:<profile>
>>>      a=e2eprof:<profile>
>>> could be used to "profile the D-channel" for the specific
>>>        
>> type frames
>>      
>>> Just some thoughts,
>>> Albrecht
>>>
>>>
>>>
>>>
>>>        
>>>> -----Original Message-----
>>>> From:[email protected]
>>>> [mailto:[email protected]] On Behalf Of Javi
>>>> Sent: Mittwoch, 13. Juli 2011 17:36
>>>> To:[email protected]
>>>> Subject: [Megaco] Media flow managed by 2 terminations
>>>>
>>>> Is it possible to manage a same flow by 2 termination (one
>>>>          
>> physical
>>      
>>>> and another ephymeral)?
>>>>
>>>>
>>>> Specifically, I need to manage the packet flows (SAPI 16) in a
>>>> D-channel ISDN. My proposal is to use:
>>>>
>>>> + A physical termination to manage the overall D-channel. When that
>>>> termination detects a packet flow (SAPI 16/TEI x), it would send a
>>>> notify to the MGC.
>>>>
>>>> + MGC would create an ephemeral termination to manage that
>>>> packet flow
>>>> (SAPI 16/TEI x) and the physical termination should continue to
>>>> manage the rest of packet flows (with different TEI) in that
>>>> D-channel.
>>>>
>>>> Does H.248.1 allow this?
>>>>
>>>>
>>>> _______________________________________________
>>>> Megaco mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/megaco
>>>>
>>>>
>>>>          
>>>        
>> _______________________________________________
>> Megaco mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/megaco
>>
>>
>>      
>