# Calling AETITLE and storage AETITLE

**URL:** https://discourse.slicer.org/t/calling-aetitle-and-storage-aetitle/8805
**Category:** Support
**Tags:** dicombrowser, dicom
**Created:** [October 16, 2019, 9:16pm UTC](https://discourse.slicer.org/t/calling-aetitle-and-storage-aetitle/8805 "2019-10-16T21:16:05Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![NormandRobert](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/normandrobert/32/4818_2.png) [@NormandRobert](https://discourse.slicer.org/u/NormandRobert)
#### Post date: [October 16, 2019, 9:16pm UTC](https://discourse.slicer.org/t/calling-aetitle-and-storage-aetitle/8805/1 "2019-10-16T21:16:05Z")

</div>

Operating system: All  
Slicer version: All  
Can someone clarify why some medical image viewers make a distinction between a calling AETITLE and a storage AETITLE? I never really understood why. Is it to send back images on a different port than is used to query?

---

<div class="post-metadata">

### Author: ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)
#### Post date: [October 17, 2019, 3:09am UTC](https://discourse.slicer.org/t/calling-aetitle-and-storage-aetitle/8805/2 "2019-10-17T03:09:19Z")

</div>

The reason is that the protocol is defined like this in the DICOM standard. Maybe they added this string because usually DICOM services do not use any other kind of user identification.

---

<div class="post-metadata">

### Author: ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)
#### Post date: [October 17, 2019, 8:12pm UTC](https://discourse.slicer.org/t/calling-aetitle-and-storage-aetitle/8805/3 "2019-10-17T20:12:08Z")

</div>

I try not to remember the details of DIMSE (too much DIMSE can lead to mental health issues), but I’ve always understood the idea to be that both ends, the provider and the user, can be configured to restrict which AETITLEs they will talk to. This becomes a kind of minimal form of security. DICOMweb is much more logical in the sense that you can put it inside standard web security frameworks.
