Hi Bruce, thanks for the reply, I agree with you.
I think I missed the point.
For the implementors, it is not clear (please correct me if I am wrong Michael):
The draft says:
"For example, if a P2PSIP node wishes to
establish a SIP dialog with another P2PSIP node, it will use
AppAttach to establish a direct connection with the other node. This
new connection is separate from the peer protocol connection. It is
a dedicated UDP or TCP flow used only for the SIP dialog."
and
" AppAttach: used to form application layer connections between
nodes."
and the paragraph 5.5.2:
This could mean two things at least (the third is for completeness):
1. An application issues an AppAttach to RELOAD and receives the
candidates. The application then have to form the connection itself.
2. An application issues a command to RELOAD that does the AppAttach
stuff ( AppAttach -> ICE -> TLS/D/TLS) and RELOAD provides an
application connection to the application (an "OverlayLinkType
connection")
(3. For completeness: Same as 2, but RELOAD provides a pure TCP or UDP
connection to the application (AppAttach -> ICE -> TCP/UDP). The
application then has to perform TLS/DTLS itself.)
I assume, with respect to your answer, you mean point 2. applies. Am I
right ? That means An application somehow tells RELOAD to make a
connection and RELOAD provides a application connection the
application then uses to exchange the application messages.
Best Regards,
Frédéric
On Sat, Oct 29, 2011 at 10:40 PM, Bruce Lowekamp <[email protected]> wrote:
> The OverlayLinkTypes that reload includes are all message-oriented
> protocols. It's up to the usage defining the application-id to
> indicate what is actually passed in these messages. e.g. the sip
> usage specifies SIP messages for application-id 5060.
>
> Beyond the application-id, I don't think it's the role of an IETF
> draft to specify how that is presented to the upper layers, though a
> usage has to specify what is on the wire clearly enough that
> compatible implementations can be written, obviously.
>
> Bruce
>
>
> On Wed, Oct 26, 2011 at 3:20 PM, Frederic-Philippe Metz
> <[email protected]> wrote:
>> Hi all,
>>
>> I definitely support Michaels question into the P2P group. The draft
>> doesn't clearly figure out how the connection "description" is
>> presented to the upper layers. In short terms, the reference point of
>> a usage using AppAttach is not defined which connection it should
>> expect. It may cause incompatibility if the same usage (i.e. SIP)
>> would expect different connection type "formats" from RELOAD.
>> Best Regards >>> Frédéric
>>
>> On Wed, Oct 26, 2011 at 1:04 AM, Michael Chen <[email protected]>
>> wrote:
>>> Hi,
>>>
>>> We had some discussions at the [email protected] list, and I like
>>> to post this question here. The base draft makes no mention of whether
>>> the link between two peers from an AppAttach may/should/must also
>>> establish D/TLS connection. Without an agreement, two peer will not be
>>> able to forward the actual SIP dialog traffics.
>>>
>>> This could be a big inter-op issue, so I would like the principles of
>>> this draft address it.
>>>
>>> Thank you
>>>
>>> --Michael
>>>
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>
>> _______________________________________________
>> P2PSIP mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/p2psip
>>
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
