Re: [SCCP] Return on Error option in SCCP XUDT

Santhana,

This is not an SS7 forum; however, that section of Q.714 means
what it says: when the user requests return on error and the
message is to be segmented into XUDT messages, the implementation
can decide which XUDT messages making up the segments can contain
return on error.  Also, when receiving XUDTS messages that
represent returned segments, the implementation must decide how
to place those into the user data field of an N-NOTICE indication
primitive.

The XUDTS or LUDTS messages are being returned to the user that
set them in the first place in this case.  Therefore, the
implementation sending the segmented XUDT messages should expect
to receive XUDTS messages only for those messages upon which it
set return on error in the first place.

Because inter-working between LUDT messages and XUDT messages may
require segmentation, and because the next paragraph of
4.1.1.1.3 says that when segmenting an LUDT into an XUDT for
inter-working, only the first segment (XUDT) will have the return
on error set; the only part of a message that one can expect to
receive in this case is the first.

So, the LUDT to segmented XUDT inter-working is different and
demands that only the first segmented XUDT have return on error
set.

The most sane way for the implementation to handle the first
case, of course, is to set the return on error in each XUDT
segment, starting with the first, that represents a sufficient
portion of the message so that the SCCP-User can identify it if
returned (maybe only the first segment).  For TCAP, this off
course means the first part of the message (transaction portion
and dialogue portion), otherwise the failed transaction cannot
be identified.  The transaction and dialogue portions of a TCAP
message can fit within the first segment depending on the
segmentation thresholds set by the implementation as described
in Q.714/4.1.1.1.

You see, when these standards say "implementation decision" it
really means that the specification cannot proscribe one way or
the other, or even identify clearly the criteria of the
decision.  To consider the criteria requires knowledge of the
implementation (such as my TCAP example above).  "Implementation
decision" does not mean "how ever your feel today", but a
careful decision based on knowledge of the protocol, its
application, and the specific implementation.

Hope that helps.

--brian


Santhana wrote:                            (Thu, 04 Feb 2010 11:43:56)
> 
>    Hi Brian
> 
>                In SCCP, for XUDT message,
> 
> 
>    Can "Return on Error" option be set in the Second or Subsequent
>    segments of XUDT as per standard ? Some sections in SCCP standards are
>    confusing.
> 
> 
>    For ex: In section
> 
>    4.1.1.1.3 Message return Procedure
> 
>    If message return is requested by the SCCP user, then it is an
>    implementation decision that
> 
>    determines which XUDT or LUDT messages have return on error requested.
> 
> 
>    If "Return on Error" set this way in the second or subsequent
>    segments(not set in the First Segment), what should be the behavior ?
>    Should XUDTS be returned in this case ?
> 
> 
>    Regards
> 
>    Santhanakrishnan

> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sigtran


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