Re: [Sipping] New I-Ds:draftdraft-dawes-sipping-debug-event-00and draft-dawes-sipping-debug-id-00

["Dawes, Peter, VF-Group" <[e-mail]>]

Thanks Dale for the thought-provoking questions and thanks Keith for the
information about how the decision is made between standards track and
informational.

In response to the questions:

>- Your example does not show how the event package is used to retrieve
the logging information.  (I assume that is its purpose.)

It is true that the example and the drafts do not show retrieving
logging information. The drafts focus on providing the capability to
centralize debugging configuration at an event package hosted by the
registrar, which allows any SIP entity to take part in debugging of a
given address of record. Once the log files have been generated, I guess
that post processing to correlate log files from all entities is needed
to piece together the sequence of signalling. I wasn't planning to
describe sending and post processing of log files in the drafts.

>- You write "The network administrators configure Alice's UA and the
>   SIP proxy that Alice uses to log SIP signalling the next time she
>   sends an INVITE request."  Looking at the following paragraph, I
>   wonder if you mean, "By subscribing to the debug-event package at
>   Alice's UA and the SIP proxy, the network administrators ..."?
> 
>   Also, it seems that the logging does not apply to "the next time she
>   sends an INVITE request" but "any dialog carrying debug ID A076D1".

I agree that the description was not clear, I have re-written it as: 

   Alice has a SIP client on her laptop, which she has been using for
   some time to make video calls to work colleagues inside her company.
   Today, she tried to set up a call to Bob, who recently installed an
   audio-only SIP phone at home, but the call failed and Alice does not
   know why.  She contacts those who manage the SIP network within her
   company to ask them to fix the problem.

   Alice's UA and the SIP proxy that Alice uses must be configured to
   log SIP signalling the next time she sends an INVITE request.  The UA
   and the proxy obtain their configuration by subscribing to the debug
   event package, which supplies XML configuration documents carried in
   NOTIFY requests.  Because debugging is rarely needed, the debug event
   package should only be subscribed to when required, which is achieved
   by triggering subscription when Alice refreshes her registration.
   The administrators cause Alice to re-register by notifying her UA
   that its subscription has expired.  When Alice's UA re-registers, an
   empty P-Debug-ID header field is included in the 200 OK response to
   the REGISTER request.  This empty P-Debug-ID header field causes both
   Alice's UA and the SIP proxy that Alice uses to subscribe to Alice's
   debug event package at the registrar, which returns them an XML
   document containing her debugging configuration.

   The configuration causes Alice's UA and the SIP proxy that Alice uses
   to log SIP signalling the next time she sends an INVITE request.
   Alice retries calling Bob and signalling is logged until the dialog
   with Bob ends.  Later examination of these logs shows that although
   requests and responses are correctly exchanged with Bob, Alice's SIP
   client is not accepting audio-only sessions and is sending BYE
   immediately.  This problem had not come to light previously as all
   calls within Alice's company are video calls.

Also, I have included an exmaple debugging configuration which specifies
the INVITE method in particular. The XML schema in the debug event draft
(listed below) allows particular SIP method(s) to be criteria for
starting logging.

<xs:element name="start-trigger">
 <xs:complexType>
  <xs:sequence>
   <xs:element ref="from"/>
   <xs:element ref="to"/>
   <xs:element ref="icsi"/>
   <xs:element ref="iari"/>
   <xs:element ref="method"/>
   <xs:element ref="time"/>
   <xs:element ref="debug-id"/> 
  </xs:sequence>
 </xs:complexType>
</xs:element>

> - Actually, there really are *two* kinds of debugging configuration,
>   one instructing a UA to apply a particular debug ID to any dialog it
>   produces (and also to log information), and the other instructing a
>   proxy or similar agent to log information about a particular debug
>   ID.  Seeing has how a single device can act as a UA in some cases
>   and a proxy in others, distinguishing these might be important.
> 

This is true. At the moment, the distinction is made by the position of
the <debug-id/> element in the configuration. If <debug-id/> is within
the <control/> element, the UA applies it to a dialog it initiates i.e.
it inserts a P-Debug-ID: header field containing the debug-id value. If
<debug-id/> is within the <start-trigger> element, it instructs a UA,
proxy, or similar agent to log information about a particular debug ID. 

> - How does this work in environments where the dialog passes through
>   several proxies in several different administrative domains?

If the proxies are authorised to subscribe to the debug event package,
then I believe it is still possible to debug such a session. 

> - Are there any recommendations for using this technique in
>   environments containing SBCs or B2BUAs?

The general intention is that any dialog related to a dialog that
contains a P-Debug-ID: header field should contain a copy of that
P-Debug-ID header field. Whether this happens depends, I suppose, either
on the B2BUA copying the header field or on configuring debugging of the
address of record that the B2BUA uses to originate requests to use the
correct value in the P-Debug-ID: header field. 

Regards,
Peter


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of DRAGE, Keith (Keith)
Sent: 28 May 2008 10:56
To: [e-mail]; [e-mail]
Subject: Re: [Sipping] New
I-Ds:draftdraft-dawes-sipping-debug-event-00and
draft-dawes-sipping-debug-id-00

In response to:

> - Why is this a P- header?  Since the event package needs to be
>   standardized, there seems to be no reason not to standardize the
>   Debug-Id header as well.
> 

If you look at RFC 3427 you will see that like headers, there are two
classes of event package documentation. One is placed in an
informational RFC and one in a standards track RFC.

So we need to evaluate RFC 3427 requirements for both the proposed
header and event package, and come to a decision on whether the proposal
has specific applicability (and therefore documented in information
RFCs), or whether it is generally applicable to the SIP world (and
therefore needs to be standards track documents).

Regards

Keith

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: Friday, May 23, 2008 11:20 PM
> To: [e-mail]
> Subject: Re: [Sipping] New I-Ds: 
> draftdraft-dawes-sipping-debug-event-00and
> draft-dawes-sipping-debug-id-00
> 
>    From: "Dawes, Peter, VF-Group" <[e-mail]>
> 
>    Thanks for taking a look at the drafts and for your comments. Below

> is a
>    first attempt at a one-page summary to illustrate the mechanism and

> its
>    purpose. I could add something like this to a future version 01 of
>    draft-dawes-sipping-debug-id.
> 
> Interesting...  A few comments:
> 
> - Why is this a P- header?  Since the event package needs to be
>   standardized, there seems to be no reason not to standardize the
>   Debug-Id header as well.
> 
> - Your example does not show how the event package is used to retrieve
>   the logging information.  (I assume that is its purpose.)
> 
> - You write "The network administrators configure Alice's UA and the
>   SIP proxy that Alice uses to log SIP signalling the next time she
>   sends an INVITE request."  Looking at the following paragraph, I
>   wonder if you mean, "By subscribing to the debug-event package at
>   Alice's UA and the SIP proxy, the network administrators ..."?
> 
>   Also, it seems that the logging does not apply to "the next time she
>   sends an INVITE request" but "any dialog carrying debug ID A076D1".
> 
> - Actually, there really are *two* kinds of debugging configuration,
>   one instructing a UA to apply a particular debug ID to any dialog it
>   produces (and also to log information), and the other instructing a
>   proxy or similar agent to log information about a particular debug
>   ID.  Seeing has how a single device can act as a UA in some cases
>   and a proxy in others, distinguishing these might be important.
> 
> - How does this work in environments where the dialog passes through
>   several proxies in several different administrative domains?
> 
> - Are there any recommendations for using this technique in
>   environments containing SBCs or B2BUAs?
> 
> Dale
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> [e-mail] for questions on current sip Use 
> [e-mail] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[e-mail] for questions on current sip Use
[e-mail] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP