Subject: [Sipping] session-indep-policy

From: "Cullen Jennings" <[email-masked]>
Date: Sun, 31 Jul 2005 12:30:48 +0200

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.

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

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.

ip in ip seems undefined - which one do you mean here.

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

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.

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.

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.

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.

_______________________________________________
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