[bfcpbis] Section 6.3.2 issue - Re: Comments on draft-ietf-bfcpbis-rfc4582bis-04

[Tom Kristensen <[e-mail]>]

On 07/16/2012 07:47 PM, Pal Martinsen (palmarti) wrote:
> Den 16. juli 2012 kl. 14:51 skrev "Alfred E. Heggestad"<[e-mail]>:
>
[...]


>>> 6.3.2. NAT Traversal
>>>
>>> ...
>>>
>>>    In order to facilitate the initial establishment of NAT bindings, and
>>>    to maintain those bindings once established, BFCP over UDP entities
>>>    are RECOMMENDED to use STUN [11] for keep-alives, as described for
>>>    SIP [10].
>>
>> reference [10] points to sip-outbound, to make this explicitly more clear
>> we could rename the text to "SIP Outbound [10].

Will do!

>> using STUN for keepalive in SIP-outbound is done from the SIP-client to
>> the SIP-server, which has an embedded STUN server to reply to STUN messages.
>> it is not very clear to me how this usage is defined in BFCP.
>>
>> for example, what should happen if a STUN Request/Response exchange times out?
>> should we try again or treat it as an implicit Goodbye message ?
>
> If ICE is not used BFCP must do keep alive with no help. Maybe specify STUN      binding indication?

The approach taken here was to not add redundant text and not specify 
behaviour when not necessary. However, if the recommendation is unclear 
- as it seems - we may have to add some amount of "advice" regarding this.

>>>    This results in each BFCP entity sending a packet, both to
>>>    open the pinhole and to learn what IP/port the NAT assigned for the
>>>    binding.
>>
>> I think the text about learning IP/port should be deleted, I dont think
>> that this information should be used for anything.
>
> +1

Fine with me.

>> I believed that STUN/BFCP is mainly about NAT keepalive, and not about
>> NAT traversal as should be defined outside this document (e.g. ICE).
>
> +2

Yes, I believe that is the approach chosen - althoug not followed as 
cleanly as it should apparently!

-- Tom