Subject: Re: [Sipping] session-indep-policy

From: Volker Hilt <[email-masked]>
Date: Mon, 01 Aug 2005 19:03:30 +0200

Cullen,

thanks much for the feedback!

> Section 4.4.3 is a little weird in a document with title indep-policy. Might
> want to make clear this defines the format used in session dependant policy
> and must not appear in a document for independent policy. Nothing wrong,
> just bit weird to read.
> 
With the way the drafts have evolved, it might make sense split them 
differently and create a "policy format" draft (covering the format that 
is currently in the session-indep draft) and a "policy delivery 
mechanisms" draft (covering the two mechanisms).

> Section 4.4.7  - <media-types> I think you should specify that when merging
> these, if you get a conflict, then treat it as a disallow. Do same with
> codecs
> 
A conflict here essentially means that a media-type/codec was marked 
mandatory in one and disallowed in the other policy. I guess one could 
argue that not using such the media-type/codec is less bad than sending 
something unwanted. However, if everything would work fine if the 
media-type/codec is not used, then why was it marked as mandatory in the 
first place? I think if policies are set up correctly this situation is 
a conflict.

> I think the media intermediaries is defined inside out. It tries to give a
> single address, then provide the type of relay inside that. I think the
> outer thing should be the type of relay, then inside that the parameters
> needed for that type of relay.
> 
> For example, turn probably needs account and password, and server URI while
> a 6to4 GW might just need an addressee and port.
> 
If it turns out that we need different elements depending on the 
intermediary type (as your example suggests) we may need to have 
different intermediary-elements for each type. Maybe a base format can 
handle things such as the URI and port and an extension could deal with 
media intermediary specific information (e.g. turn account/password).

> ip in ip seems undefined - which one do you mean here.
> 
There should be a reference to [11] (RFC2003). Thanks!

> media specific is not really a type. I can see types like SIP-proxy or
> MSRP-relay that are media specific but I think that needs to be the type
> 
Yes, if we define separate elements for each intermediary type, we 
probably need to do the same thing for media specific intermediaries.

> I would probably add in stun in as a type - it's not that stun is so much a
> media relay as it is that the NAT is and that STUN server is basically how
> you signal to control the NAT media relay.
> 
Interesting thought (and how about UPnP? :) ). I'm not sure if 
NAT/address discovery should be included here. And if so, what would be 
contained in such an intermediary element?

> I think "none" is the wrong word. I think that static-forwarding might be a
> better word for what you mean here - not sure the best word but don't really
> like none.
> 
I agree. Will try to find something better (or use static-forwarding).

> Inside a single policy document, I see no reason you could not have more
> than one media relay defined. The media would be tunneled through each of
> them in order.
> 
The document format already supports this (a policy can contain multiple 
media-intermediary elements). To make this more explicit, one could 
define a media-intermediary container and put the media-intermediary 
elements there.

> I don't want to confuse this with the place that a UA finds out about all
> the media relays available for it to use - these are the constraints on the
> ones it must use. So I want to check that we are on the same page that some
> other config defines the TURN, STUN, 6to4, etc relays that a UA has
> available to use with ICE.
> 
I agree. This is not meant to replace ICE connectivity detection. It 
defines a policy about the intermediaries the UA should use. These can 
be the intermediaries discovered through ICE or these can be other 
intermediaries the UA should use. The relation between these protocols 
probably needs to be clarified in the draft.

Volker

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP