Subject: [Sigtran] Backhauling GR-303 signaling messages

From: "Umesh Bhavsar" <[email-masked]>
Date: Tue, 7 May 2002 15:27:20 -0400

I just joined this mailing list and hence this topic may have been already discussed or may be irrelevant, in that case apologies.

Are there any drafts or discussion on backhauling Gr303 messages from MG to Call control?  Specifically backhauling TMC channel (Timeslot Management Channel) + ABCD signaling, and backhauling EOC channel (Embeded Operation Channel).  

Appreciate if anybody can direct me to any work done in this area.

Thanks
Umesh

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 May 2002 00:02:59 -0500

Umesh,

See http://www.ietf.org/html.charters/megaco-charter.html

--brian

Umesh Bhavsar wrote:                                        (Tue, 07 May 2002 15:27:20)
> 
>    I just joined this mailing list and hence this topic may have been
>    already discussed or may be irrelevant, in that case apologies.
>    
>    Are there any drafts or discussion on backhauling Gr303 messages from
>    MG to Call control?  Specifically backhauling TMC channel (Timeslot
>    Management Channel) + ABCD signaling, and backhauling EOC channel
>    (Embeded Operation Channel).
>    

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Tolga Asveren" <[email-masked]>
Date: Fri, 10 May 2002 09:32:04 -0400

Lyndon,

I propose that M3UA SG-SG communciation draft is moved to official WG item
list. In my opinion it defines a missing piece in SIGTRAN, is quite
straightforward, interacts well with SS7 entities as well as with M3UA
entities.

Also another question before it is too late, will there be a SIGTRAN session
in the 54th IETF meeting?

     Tolga

---

From: "Ranjith Mukundan" <[email-masked]>
Date: Tue, 14 May 2002 19:43:35 +0530

Umesh,

Ken and myself were in the process working on GR303UA extension to IUA for backhauling the
EOC and TMC/CSC messages from the SG to AS - I'll chk with Ken as to when this can be
submitted and revert to you.

As for the inband part there are Megaco packages (like the advanced anlog lines package)
for transporting these events and signals (for LS, GS, LRB equivalent) - though I am not
convinced that these would suffice (so dont be surprised if you see a megaco-gr303 package)
soon.

Also, on the ITU (you can get the details from one of the AVDs at the pictel site),
Coppercom have proposed a way to map events and signals specified in different POTs/analog
lines based megaco packages to the corresponding gr303 inband signaling events and signals.

hth,
ranjith..

---

From: Al Varney <[email-masked]>
Date: Tue, 14 May 2002 12:26:50 -0500

>convinced that these would suffice (so dont be surprised if you see a 

Ranjith & Ken,

    Would it be more useful to extend/modify V5UA for GR303UA, rather than 
grafting it onto IUA?  While 303 message encoding is based on Q.931-style 
ISDN, the signals, events, maintenance aspects and explicit control of 
in-band connections might be a better fit with V5UA.

    Also, unless you can find a switch that's actually implemented CSC 
messaging, you might want to reduce the effort by just marking CSC "for 
future study".  I believe CSC is considered incomplete even in the official 
GR-303-CORE requirements.  Leaving out CSC would also reduce much of the 
confusion introduced by mixing the TMC and CSC call models in a single IETF 
draft and standard.

Al Varney

---

From: Ken Morneault <[email-masked]>
Date: Wed, 15 May 2002 08:11:03 -0400

Al,

Thanks for your useful advice.  We'll definitely take it into consideration
when we finish the GR303 draft.

Regards,

Ken

At 12:26 PM 5/14/2002 -0500, Al Varney wrote:
>   Would it be more useful to extend/modify V5UA for GR303UA, rather than grafting it onto IUA?  While 303 message encoding is based on Q.931-style ISDN, the signals, events, maintenance aspects and explicit control of in-band connections might be a better fit with V5UA.
>
>   Also, unless you can find a switch that's actually implemented CSC messaging, you might want to reduce the effort by just marking CSC "for future study".  I believe CSC is considered incomplete even in the official GR-303-CORE requirements.  Leaving out CSC would also reduce much of the confusion introduced by mixing the TMC and CSC call models in a single IETF draft and standard.
>
>Al Varney
>
>
>