|
Hi,
Usage of SIP to debug SIP may be sufficient by
looking from different view. It depends on the problem
statement.
- SIP itself is not working: SIP itself is not working is a
local problem or problem spanning multiple SIP entities? What is not working?
If its a local problem in UA then UA should give a different error to the
user. Some thing is broken in the UA and that needs to be fixed. If the same
user registers in different UA may be the call is possible.
- A feature is not working: SIP itself is working in the UA
(or in other SIP entity) but a function or feature is not working. So this can
be a interop problem or some information is missing in the signaling etc. To
debug these kind of problems I think SIP is suitable. As proposed in
debug-id and debug-event package a SIP entity can indicate it likes to debug to
know the problem.
Debugging of features (functions) which are not working is
much harder than debugging of SIP not working. Generally if you can see a crash
or if you can locate a particular part is not working then its easy to fix. If
we see a crash then probably its easy to locate where it failed by looking at
the function call stack. However if there is a logic problem or interop problem
its much harder to find.
So before using this debug-id one has to validate the basic
SIP is working or not. Can we determine the entity has good enough SIP and it
should use debug-id?
The document needs to be improved and state the scope of
the problem. Is there any problem statement and requirements draft for
debugging? May be that is required to understand the scope.
I like this idea and its useful. I like the way to do with
SIP and the assumption is we are debugging the problems spanning multiple nodes
(sip entities) than local problems.
Regards
Krishna From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Hadriel Kaplan Sent: den 27 november 2008 05:09 To: peter.dawes@xxxxxxxxxxxx; karann.chew@xxxxxxxxxxxx Cc: sipping Subject: Re: draft-dawes-sipping-debug-event-01.txt 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
