|
Howdy, I read your draft and find the topic very interesting. Operational
issues for SIP such as troubleshooting are a clear area for improvement, which
I think we need to tackle to get SIP to the next level. When I first read
the draft I thought it was about setting/getting debug info from SIP nodes like
proxies, B2BUA's and servers, and I kind of glossed over the endpoint phone
aspects to it. (which is natural since I don't build phones :) But in reading it again and looking at the 3GPP document for this, it
seems to me the critical aspect to your draft is in fact the phones/UAs. The
reason I say that is for network-based devices (proxies, b2bua's, app-servers, registrars,
etc.), using SIP to debug SIP will not be sufficient, because if SIP itself
isn't working right then one can't use it for this. And the security
aspects and addressing and privilege access issues are far more complicated if
you try to do that through SIP to such node types - really they need a separate,
lighter-weight, northbound management protocol to do this type of thing:
essentially a provisioning protocol like SOAP or NETCONF. But for phones, the only pragmatic way to even access them would be
through SIP itself, because (1) if it's a soft-phone you don't want to talk to
the PC, you want to talk to the SIP app; (2) if it's behind a NAT one of the
few if not the only way you can even get to it through the NAT is through SIP;
and (3) SIP is the common denominator protocol for talking to all UA types.
There are still a host of security and privilege issues surrounding that idea (and
they would be a big deal), but I think it's valuable and important enough you
should try to get this to be a standards-track document rather than
informational. Because this isn’t just a 3GPP thing – it affects
other SIP provider admins, including Enterprises, or anyone managing a set of distributed
SIP phones on the Internet. One way to do that would be to focus only on phone/UA scenarios,
describe the reasons SIP would have to be the chosen protocol, and to relate it
to the current SIP config framework drafts. That last part is the key I
think, because you can point out that the IETF is already using SIP to
configure the UA, and basically what you're looking for is a temporary configuration
of specific fields: namely SIP debug-logging-related configuration. -hadriel |
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
