Subject: [Sipping] petrie-sipping-sip-dataset

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 29 Jul 2005 12:29:06 -0400

This whole config framework stuff is the most important thing missing in SIP
right now and I really want to see this stuff more forward quickly. I think
this draft has a bunch of significant changes needed.

1) is has stuff that is at best on optional stuff included. we really don't
need to be able to configure the methods that are allowed to deploy working
system. Focus on just what is needed for now and get that done, non critical
stuff can be done later. I doubt that sip_mmethods and options tags are
critical. I actually doubt that even the transports are critical. The proxy
can force one or another using the transport= tag in the outbound proxy URI.

2) There is stuff that is critical missing. This needs a way to download the
various AOR, usernames, and passwords  to the device. I know that
sipping-profile-datasets implies this might happen elswhere but I'm lost on
where and how.

More detailed comments:

I think you need to add a section on setting display name, AOR, password
(and perhaps realm). Also need to identify this draft as containing
information that requires privacy protection at this point.

I hate that the title of this draft has both sip and sipping in it. I don't
even know which list to send this email to.

transport data set
is this to receive on, send on both? what? Are ephemeral allowed where it
changes? Could you get rid of the allow disallow mandatory stuff by just
setting the port to -1 for don't care and 0 for must not use then letting
precedence select the correct one? If I am ok with anything in a given
range, how do I specify? Basically I don't think this is needed. The proxy
can tell the UA what it can do via something like SRV and the UA can prick
one and tell the servers what it used in the register.

outbound - this one is important and we need it. However, I think the merge
rules are wrong. If my localnetwork says I have to use local.net and my main
server says I have to use foo.net, my UA should merge by forming a loose
route through both of theses.

sip_methods - I see very little value in configuring these. The purpose of
these was so that the UA could advertise what it supported. What would it
mean to have "REFER" mandatory on a device that did not support REFER? What
would this configuration get used for?

Option-tag - similar comments to above. Think you should nuke it from this
draft - another profile can be defined with it once we get this out the
door.

I'm really not seeing the value in the mandatory, allow, disallow approach
to things - it is very limited yet complex all at the same time. Given the
various constraints are being set by uncoordinated administrators - I find
it easy to imagine cases where the UA will have no idea what to do. Most UA
implementers, when confused, will just ignore whatever is confusing them. I
mean if the local net wants to say that TCP is ok but not below port 1024
there is no way to express that. It could just say that port 7000 was OK and
hope none one had a conflict but what would happen if there was a conflict.

I'd rather see the Nat traversal stuff, http proxy stuff in here as well
(but not the buddy list or address book stuff) - I'm borderline about the
dial maps because I know there will be so much disagreement on them.

_______________________________________________
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