Subject: Re: FW: some proposals for UA

From: Mart Nurmet <[email-masked]>
Date: Fri, 30 Mar 2001 07:40:51 -0600

Mr. Ming Lin:

Please correct the calendar date on your PC.  -MN

Ming Lin wrote:

> Hi all,
>
> If SUA wants to route/loadshare by TID(Transaction ID),
> OTID(Origin TID) and DTID(Destination TID)
> should be considered carefully.
>
> SUA should look at the message type of TCAP message,
> and decides whether DTID is there.
> If DTID is there, routing/loadsharing should be done
> by DTID; if not, like BEGIN message,
> routing/loadsharing should be done by OTID;
> and if there is not DTID and OTID, what should SUA do?
>
> The routing key of DTID and OTID shoud be configed
> or registered together.
>
> I still think TUA is needed, so we can implement
> TCAP in SG, and route/loadshare traffic by DID(dialog ID).
> Is there someone interesting in TUA?
>
> Thanks&Regards
> Ming Lin
>
> -----Original Message-----
> ·¢¼þÈË: Benjamin J. Wilson <[email-masked]>
> ÊÕ¼þÈË: [email-masked]
> <[email-masked]>
> ÈÕÆÚ: 2001Äê3ÔÂ29ÈÕ 2:21
> Ö÷Ìâ: Re: FW: some proposals for UA
>
> >Gery,
> >
> >If I understand this correctly, I agree.  Are you saying that it might
> >be easier
> >to avoid loadsharing altogether and break the AS/routing key into
> >logical parts
> >which support override mode?
> >
> >i.e RK ( DPC = 1.1.1, TID 1-100, Loadsharing 2 + 1 ) might be better off
> >being
> >    configured as RK1 ( DPC = 1.1.1, TID 1 - 49, Override ) and
> >    RK2 ( DPC = 1.1.1, TID 50-100, Override ).
> >
> >Cheers,
> >
> >Ben
> >
> >[email-masked] wrote:
> >>
> >> > I'll try to come up with a fairly simple but general
> >> > solution, something
> >> > along the lines of :
> >> >
> >> > - using a mask to identify relevant bits in the TID
> >> >
> >> > - each ASP gets a single, non-interrupted range of DIDs (no added
> >> > functionality if we use several non-adjacent ranges is there
> >> > ?) to process.
> >> >
> >> > The above info should be provisionable on a AS (routing key) basis.
> >> >
> >> > Any thoughts ?
> >> >
> >
> >
> >---
> >You are currently subscribed to sigtran as: [email-masked]
> >To unsubscribe send a blank email to
> [email-masked]
>
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]
---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]