Subject: [Sipping] comments on draft-poetzl-sipping-call-completion-02

From: Jason Fischl <[email-masked]>
Date: Mon, 12 Mar 2007 08:55:15 -0700

Hello,

High level comments:
- Is it possible to use a restricted version of the dialog-event  
package to communicate this information to the UAC? I realize that  
dialog-event would only communicate that the callee is available but  
this may be all that we really need here.

- How would you handle the case where the notifier goes offline  
unexpectedly?  e.g. Notifier is a softphone or mobile device and  
loses network connectivity or is restarted.

- Should the invite after a notification of user-free-for-recall be  
sent in the same dialog as the original INVITE and SUBSCRIBE?  If  
not, then the INVITE may fork and be answered by a different UAS  
which will leave the subscription intact. In this case, the UAC  
should remove the subscription upon successful call completion.

Specific comments:
6.10 Handling of Forked Requests
- implies that the SUBSCRIBE MUST be sent within the existing dialog  
formed by the INVITE or sent to a gruu discovered from the response  
to the INVITE. This should probably be called out.

7.1 queue-nature
- typo SUBSRIBE -> SUBSCRIBE

7.2 queue-operation
- are subscribe/resume operations really necessary? It seems to me  
that these could be handled entirely by the subscriber.
- what is the behavior of the notifier if an invalid call-completion  
information format is received? i.e. what error response code should  
be sent?

7.4 caller
- why is this component needed? Isn't this always the same as the  
 From header?

7.5 service-retention
- Is this option needed? Isn't this always the desired behavior?

8. P-Service-Indication Header
- the text here is confusing. I think I understood what the header  
was for after reading the entire section but the first paragraph was  
hard to understand.
- I'm not sure the UAC and UAS behavior sections are clear as they  
are written. There should probably also be a Proxy behavior section.
- seems like this header could be easily abused.

Proposed text:
The P-Service-Indication header is used to indicate to intermediate  
elements or to the UAS that  special processing may be applied. Any  
elements in the path that do not understand the header or the service  
indication must ignore it. The header consists of a list of service  
indications represented by tokens.

I think it would be helpful to describe an example of how a proxy  
might use the SI ccss.

8.1 UAC Behavior
- the text describing behavior in ACK and CANCEL requests that is a  
bit confusing.

9. Signaling Flows
- F3 has a typo in CSeq. Should be SUBSCRIBE not SUBSCRIBEOLO
- the first example should show the termination of the subscription  
after a successful call completion.

_______________________________________________
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