Re: User Part Unavailable at ASP in M3UA
"Kuldeep Janjua" <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
Mahantesh, ASP Inactive have following parameters: 1.Routing Context 2.INFO I think what Brian is discussing is that ASP Inactive Message will contain the routing context parameter, which will let SGP to know that corresponding traffic range is not available and then SGP can handle the message accordingly. But its not specified anywhere in the RFC. >From my point of view Error Message with "Invalid Routing Context" should be sent, which will stop the further processing of the message at SGP. As per definition SCON is signalling congestion message so it can be sent from ASP only in the case when M3UA at ASP detects that there is congestion for the corresponding user part.So it take care of "UP unavailability" in case of "congestion at ASP for UP" only. There can be other reasons as well for user part unavailability. Those cases are also required to taken care of. Regards, Kuldeep On 12/18/06, Mahantesh <[email protected]> wrote: > > *Kuldeep,* > > What if ASP is ACTIVE and unable to send the signalling UNIT to USER PART? > In such case you can't send ASP-INACTIVE message to the other end. > > *Any FEEDBACK for the below paragraph.* > > On receiving an *MTP-TRANSFER* request primitive from an upper layer at an > ASP the M3UA layer sends a corresponding DATA message to its M3UA peer. > > Keeping the above statement in mind, we can say that there must be a way > for M3UA layer at ASP to know about the UPPER LAYER [USER PART] > availability/unavailability. When an ASP unable to send the signalling > message to the UPPER layer it will come to know about it > > UP UP > | ^ > V | > LM --> M3UA or LM <-- M3UA > > When UP is unavailable other end will be made known about the > unavailability. AND > *The optional Concerned Destination parameter is only used if the SCON > message is sent from an ASP to the SGP.* > > > *Rgrds, > -Mahantesh* > On 12/18/06, Kuldeep Janjua <[email protected]> wrote: > > > > Yes Mahantesh, > > > > Even I too could not find its reference in RFC 4666. It will be nice if > > some body can specify it. > > > > Kuldeep > > > > > > > > On 12/18/06, Mahantesh <[email protected] > wrote: > > > > > > Sorry guys!! > > > > > > SCON has only Cause field. > > > > > > Unavailability Cause field: 16-bits > > > > > > 0 Unknown > > > 1 Unequipped Remote User > > > 2 Inaccessible Remote User > > > > > > But, why ASP-INACTIVE ? > > > No where in the RFC it is mentioned that "when UP is unavailable, send > > > INACTIVE". > > > > > > > > > *Rgrds, > > > -Mahantesh * > > > > > > On 12/18/06, Brian F. G. Bidulock <[email protected] > wrote: > > > > > > > > Mahantesh, > > > > > > > > SCON does not have an MTP3-User Identity field. It is use to > > > > indicate > > > > so-called "nodal" congestion only. > > > > > > > > --brian > > > > > > > > Mahantesh wrote: (Mon, 18 Dec 2006 > > > > 12:25:39) > > > > > > > > > > Kuldeep, > > > > > > > > > > This might help you resolve ur doubt...cause/user field > > > > of SCON > > > > > message. > > > > > Unavailability Cause field: 16-bits > > > > > > > > > > 0 Unknown > > > > > 1 Unequipped Remote User > > > > > 2 Inaccessible Remote User > > > > > > > > > > MTP3-User Identity field: 16-bits > > > > > > > > > > 0 to 2 Reserved > > > > > 3 SCCP > > > > > 4 TUP > > > > > 5 ISUP > > > > > 6 to 8 Reserved > > > > > 9 Broadband ISUP > > > > > 10 Satellite ISUP > > > > > 11 Reserved > > > > > > > > > > 12 AAL type 2 Signalling > > > > > 13 Bearer Independent Call Control (BICC) > > > > > 14 Gateway Control Protocol > > > > > 15 Reserved > > > > > > > > > > Rgrds, > > > > > -Mahantesh > > > > > > > > > > > > > > > > > -- > > > > Brian F. G. Bidulock > > > > [email protected] > > > > http://www.openss7.org/ > > > > > > > > > > > > > > > > -- > > > > > > > > > > -- > _______________________________________________ Sigtran mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sigtran