Re: Upper boundary of Adaptation Layers

Brian,
   
  You actually confirm my point -> attaching/deattaching, activation/deactivation... all of these activities are performed by non-SCCP functionality, i.e. it is not SCCP that attaches or activates an SCCP subsystem but user that attaches to the service or activates itself for the traffic exchanged with the service! Users attach to service not vice versa!
   
  You cannot also find in SCCP specifications that SCCP service attaches local users...
   
   
  Anyway, our dispute was that according to you N-STATE_request is not a primitive between SCCP and SCCP-user but between SCCP and SCCP-LM. As I showed this is not the case but instead as I pointed it is the primitive between SCCP and SCCP-user application!
   
  By the way, are you saying that N-STATE_request from an SCCP-user application should not generate ASP_INACTIVE on the external interface??? Do you remember our last week's discussion about this -> your point was that ASP is not allowed to send DUNA reflecting N-STATE_request but instead that is to be done by ASP_ACTIVE/INACTIVE? Look at http://www1.ietf.org/mail-archive/web/sigtran/current/msg05667.html
   
   
  best regards/ Stanislav Ivanovich
    
  

"Brian F. G. Bidulock" <[email protected]> wrote:
  Stanislav,

Perhaps you can point to where in Q.711 the SCCP user is attached to
or removed from an NSAP. ;)

This is a local management function. Attaching to an NSAP is equivalent
to activating an AS, detaching, deactivating. The address of the NSAP
itself is the RK. Attaching and detaching a user at an NSAP is ASP Active
and ASP Inactive for the AS with the RK associated with the NSAP.

Understand?

--brian

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


		
---------------------------------
 Yahoo! DSL Something to write home about. Just $16.99/mo. or less

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