Hi,

I have a general question on the separation
of functionality between a codec and a
system adapter.

In my understanding of the TTCN-3 architecture,
the SA is acting as the transport layer for the
encoded message (encoded by the codec) to the SUT.
It looks like the SA does not play a role in
building the content of the message to be sent.

Are there any guidelines as to whether or not
the SA can manipulate the message payload encoded
by the codec? For example, say I have a SIP
message data structure defined in TTCN-3 and
say I build a codec which converts that TTCN-3
data structure to a SIP message and this SIP
message is passed on to the SA to send to a
SIP SUT.

For implementing a system adapter in this case,
I have two options -

1. send the SIP message using UDP/TCP to the SUT.
2. use a SIP stack to send the SIP message.

Using 1, I don't have to change the message
content, but in the second case for sending
the message thru the SIP stack, I'd have to
reconstitute the message within the context
of the SIP stack and then send it. Using 2,
I get the benefits of a SIP stack like
retransmission handling and so on which I
don't get in 1. On the other hand, approach
2 may require the encoded message to be
"peeped into" by the SA, which would require
the SA to know about the encoding mechanism
which was used by the codec.

Any thoughts/guidelines on how I would go
about making these choices?

Thanks
Venkita

Dear Venkita,

your description of the TRI/TCI architecture is completely right.

However, in order to answer your question, I would have to elaborate a
little bit more on the the term "encoding" of messages in a protocol
scenario.

You take the term "encoding" literally, i.e. you say that when encoding
you build the complete PDU in the codec and that this encoded message
should under all circumstance only be used as payload. Of course this is
what you do in (1), why doing something else?

But as you said, for (2) this seems at least questionable.

In other words, if you plan to feed a SIP stack I don't think encoding
the *PDU* is the right "encoding rule" for your codec. Perhaps, encoding
the data *structure* is much simpler and more efficient, so that you can
get access to the SIP structure without an expensive decoding in the SA.
And of course this would then couple the codec to the SA much tighter.
But sometimes it is worth.

And as matter of fact, this is what is typically been done in procedure
based communication.

And to answer your question. Choose the SA implementation that fits to
your needs, and the provide the right codec.

Hope this helps.

Best regards, Theo


Venkita Subramonian schrieb:
> Hi,
>
> I have a general question on the separation
> of functionality between a codec and a
> system adapter.
>
> In my understanding of the TTCN-3 architecture,
> the SA is acting as the transport layer for the
> encoded message (encoded by the codec) to the SUT.
> It looks like the SA does not play a role in
> building the content of the message to be sent.
>
> Are there any guidelines as to whether or not
> the SA can manipulate the message payload encoded
> by the codec? For example, say I have a SIP
> message data structure defined in TTCN-3 and
> say I build a codec which converts that TTCN-3
> data structure to a SIP message and this SIP
> message is passed on to the SA to send to a
> SIP SUT.
>
> For implementing a system adapter in this case,
> I have two options -
>
> 1. send the SIP message using UDP/TCP to the SUT.
> 2. use a SIP stack to send the SIP message.
>
> Using 1, I don't have to change the message
> content, but in the second case for sending
> the message thru the SIP stack, I'd have to
> reconstitute the message within the context
> of the SIP stack and then send it. Using 2,
> I get the benefits of a SIP stack like
> retransmission handling and so on which I
> don't get in 1. On the other hand, approach
> 2 may require the encoded message to be
> "peeped into" by the SA, which would require
> the SA to know about the encoding mechanism
> which was used by the codec.
>
> Any thoughts/guidelines on how I would go
> about making these choices?
>
> Thanks
> Venkita
>

Hello Venkita and Theo,

I have nothing to add to Theo's good expllanation from a technical point of view.

Let me just point that if you want to do SIP testing and use a SIP implemenation for transport, which is your approach 2), you have to be very carefully that the test and the SIP stack do not interfere. As an example, if your SIP stack provides automated retransport, but if you want to test the behaviour of the SUT exactly in the case that the retransport does not take place, you might get into problems with controlling the SA. I do not know whether this would really be a problem, but you have to take care of this. If you follow approach 1), then you have more control over what is happening in your test system.

Best regards

Thomas

---

| Thomas Deiß, Nokia Research Center Street address: |
| P.O. Box 101823 Meesmannstrasse 103 |
| D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
| Phone: +49 234 984 2217, Mobile: +49 163 984 2217 |
| Fax: +49 234 984 3491, E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

Sitz der Nokia GmbH: Bochum * Amtsgericht Bochum:HRB 4112 * Umsatzsteueridentifikationsnummer: DE 811163 495 * WEEE-Reg.-Nr. DE 51797011* Vorsitzender des Aufsichtsrates: Veli Sundbäck * Geschäftsführer: Timo Elonen, Klaus Goll, Dr. Ulrich Halka, Razvan Olosu (Sprecher), Karsten Schilly


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>Theofanis Vassiliou-Gioles
>Sent: Thursday, 15. March 2007 07:28
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: SA and codecs
>
>Dear Venkita,
>
>your description of the TRI/TCI architecture is completely right.
>
>However, in order to answer your question, I would have to
>elaborate a little bit more on the the term "encoding" of
>messages in a protocol scenario.
>
>You take the term "encoding" literally, i.e. you say that when
>encoding you build the complete PDU in the codec and that this
>encoded message should under all circumstance only be used as
>payload. Of course this is what you do in (1), why doing
>something else?
>
>But as you said, for (2) this seems at least questionable.
>
>In other words, if you plan to feed a SIP stack I don't think
>encoding the *PDU* is the right "encoding rule" for your
>codec. Perhaps, encoding the data *structure* is much simpler
>and more efficient, so that you can get access to the SIP
>structure without an expensive decoding in the SA.
>And of course this would then couple the codec to the SA much tighter.
>But sometimes it is worth.
>
>And as matter of fact, this is what is typically been done in
>procedure based communication.
>
>And to answer your question. Choose the SA implementation that
>fits to your needs, and the provide the right codec.
>
>Hope this helps.
>
>Best regards, Theo
>
>
>Venkita Subramonian schrieb:
>> Hi,
>>
>> I have a general question on the separation of functionality
>between a
>> codec and a system adapter.
>>
>> In my understanding of the TTCN-3 architecture, the SA is acting as
>> the transport layer for the encoded message (encoded by the
>codec) to
>> the SUT.
>> It looks like the SA does not play a role in building the content of
>> the message to be sent.
>>
>> Are there any guidelines as to whether or not the SA can manipulate
>> the message payload encoded by the codec? For example, say I have a
>> SIP message data structure defined in TTCN-3 and say I build a codec
>> which converts that TTCN-3 data structure to a SIP message and this
>> SIP message is passed on to the SA to send to a SIP SUT.
>>
>> For implementing a system adapter in this case, I have two options -
>>
>> 1. send the SIP message using UDP/TCP to the SUT.
>> 2. use a SIP stack to send the SIP message.
>>
>> Using 1, I don't have to change the message content, but in
>the second
>> case for sending the message thru the SIP stack, I'd have to
>> reconstitute the message within the context of the SIP stack
>and then
>> send it. Using 2, I get the benefits of a SIP stack like
>> retransmission handling and so on which I don't get in 1. On
>the other
>> hand, approach
>> 2 may require the encoded message to be "peeped into" by the
>SA, which
>> would require the SA to know about the encoding mechanism which was
>> used by the codec.
>>
>> Any thoughts/guidelines on how I would go about making these choices?
>>
>> Thanks
>> Venkita
>>
>

Hello Venkita, Theo and Thomas,

I would add only a small philosophical remark to the excellent
explanations provided by both Theo and Thomas.

Using a protocol stack may save you some coding but the real
benefits could come only once you determine what the purpose of the test is:

1. testing the SIP application
2. testing the SIP protocol stack

Both are of course possible and desirable, but if something goes wrong it
may take a while to determine who is the culprit, the application or the
protocol stack.

As Theo mentioned, if you want to use the protocol stack, you may as
well change your ATS completely to handle the stack more efficiently and
avoid lots of redundancy. However, your standard ATS for the SIP protocol
could be still used to test the stack by itself or in conjunction with the
application testing. In such a configuration, failures should be able to be
attributed to the correct source with much more ease.

Hope this helps

Bernard Stepien

---

Original Message

---

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Thomas Deiss
Sent: Thursday, March 15, 2007 3:08 AM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: SA and codecs

Hello Venkita and Theo,

I have nothing to add to Theo's good expllanation from a technical point of
view.

Let me just point that if you want to do SIP testing and use a SIP
implemenation for transport, which is your approach 2), you have to be very
carefully that the test and the SIP stack do not interfere. As an example,
if your SIP stack provides automated retransport, but if you want to test
the behaviour of the SUT exactly in the case that the retransport does not
take place, you might get into problems with controlling the SA. I do not
know whether this would really be a problem, but you have to take care of
this. If you follow approach 1), then you have more control over what is
happening in your test system.

Best regards

Thomas

---

| Thomas Deiß, Nokia Research Center Street address: |
| P.O. Box 101823 Meesmannstrasse 103 |
| D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
| Phone: +49 234 984 2217, Mobile: +49 163 984 2217 |
| Fax: +49 234 984 3491, E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

Sitz der Nokia GmbH: Bochum * Amtsgericht Bochum:HRB 4112 *
Umsatzsteueridentifikationsnummer: DE 811163 495 * WEEE-Reg.-Nr. DE
51797011* Vorsitzender des Aufsichtsrates: Veli Sundbäck * Geschäftsführer:
Timo Elonen, Klaus Goll, Dr. Ulrich Halka, Razvan Olosu (Sprecher), Karsten
Schilly


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext
>Theofanis Vassiliou-Gioles
>Sent: Thursday, 15. March 2007 07:28
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: SA and codecs
>
>Dear Venkita,
>
>your description of the TRI/TCI architecture is completely right.
>
>However, in order to answer your question, I would have to
>elaborate a little bit more on the the term "encoding" of
>messages in a protocol scenario.
>
>You take the term "encoding" literally, i.e. you say that when
>encoding you build the complete PDU in the codec and that this
>encoded message should under all circumstance only be used as
>payload. Of course this is what you do in (1), why doing
>something else?
>
>But as you said, for (2) this seems at least questionable.
>
>In other words, if you plan to feed a SIP stack I don't think
>encoding the *PDU* is the right "encoding rule" for your
>codec. Perhaps, encoding the data *structure* is much simpler
>and more efficient, so that you can get access to the SIP
>structure without an expensive decoding in the SA.
>And of course this would then couple the codec to the SA much tighter.
>But sometimes it is worth.
>
>And as matter of fact, this is what is typically been done in
>procedure based communication.
>
>And to answer your question. Choose the SA implementation that
>fits to your needs, and the provide the right codec.
>
>Hope this helps.
>
>Best regards, Theo
>
>
>Venkita Subramonian schrieb:
>> Hi,
>>
>> I have a general question on the separation of functionality
>between a
>> codec and a system adapter.
>>
>> In my understanding of the TTCN-3 architecture, the SA is acting as
>> the transport layer for the encoded message (encoded by the
>codec) to
>> the SUT.
>> It looks like the SA does not play a role in building the content of
>> the message to be sent.
>>
>> Are there any guidelines as to whether or not the SA can manipulate
>> the message payload encoded by the codec? For example, say I have a
>> SIP message data structure defined in TTCN-3 and say I build a codec
>> which converts that TTCN-3 data structure to a SIP message and this
>> SIP message is passed on to the SA to send to a SIP SUT.
>>
>> For implementing a system adapter in this case, I have two options -
>>
>> 1. send the SIP message using UDP/TCP to the SUT.
>> 2. use a SIP stack to send the SIP message.
>>
>> Using 1, I don't have to change the message content, but in
>the second
>> case for sending the message thru the SIP stack, I'd have to
>> reconstitute the message within the context of the SIP stack
>and then
>> send it. Using 2, I get the benefits of a SIP stack like
>> retransmission handling and so on which I don't get in 1. On
>the other
>> hand, approach
>> 2 may require the encoded message to be "peeped into" by the
>SA, which
>> would require the SA to know about the encoding mechanism which was
>> used by the codec.
>>
>> Any thoughts/guidelines on how I would go about making these choices?
>>
>> Thanks
>> Venkita
>>
>