Subject: Re: [Sipping] draft-dawes-sipping-debug-event-01.txt

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 Nov 2008 23:08:59 -0500

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Krishna Prasad Kalluri" <[email-masked]>
Date: Thu, 27 Nov 2008 17:03:43 +0100

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: den 27 november 2008 05:09
To: [email-masked]; [email-masked]
Cc: sipping
Subject: Re: [Sipping] 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