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

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 15 Mar 2007 17:42:31 +0100

Hi Jason,

thanks for your comments.

It's conceivable to add oneself to  a call-completion queue by subscribing to the dialog-event and being informed the the called user is available when one's position in the queue is reached, but I think that is not the intention of the dialog-event, and as answered in the other mail, also the other queue-manipulation operations are needed, so the dialog-event is not enough here.

A mistake at the notifier is not considered in the draft. But as there is a limit for the subscription duration, the served user knows that he has to try again after 45 min, if there was no recall notification during this time.

The adding of text for the recall INVITE is noted. I agree there is text missing what happens to the subscription in the case of a successful recall. The idea is in fact that a successful recall terminates the subscrition.

An invalid call-completion information subscription format can be handled by the existing SIP error responses, I will add some text.

8. P-Service indication: thanks for your comments, they will be considered for the revision.

Regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: Jason Fischl [mailto:[email-masked]] 
> Gesendet: Montag, 12. März 2007 16:55
> An: [email-masked]
> Cc: Pötzl, Joachim; Hülsemann, Martin; [email-masked]
> Betreff: comments on draft-poetzl-sipping-call-completion-02
> 
> 
> 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.
> 
> 
> 

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss