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

---

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:

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 15 Mar 2007 17:4From [email-masked] Thu Mar 15 12:43:34 2007

Hi Jason,

Regards, Martin

> this may be all that we real1:26 +0100
To: "Beck01, Wolfgang" <[email-masked]>, <[email-masked]>,
	<[email-masked]>, <[email-masked]>
Cc: 

Hi Wolfgang, Jason,

using 'suspend' and 'resume' is a question of the effectiveness of running the service, because if a UAC knows that the user is busy and sends a 'suspend', the UAS doesn't has to initiate a call-completion recall to that user, wait for his response, cancel the recall, not knowing anyway if there is still a need to recall this user, and first then recall the next user in the queue.

You are right 'add' is a synonyme for SUBSCRIBE with Expires > 0, the advantage of it's usage is that it can very easily be interworked with the PSTN TCAP ccbsRequest invoke component.

For the denial reasons, there might be SIP response codes which match those reasons, but for me they seem to be more appropriate for the SIP transactions itself then for the call-completion event. So we decided to use an extra parameter, to have a clear separation between those two things.

For the caller parameter, there might be the service operation scenario where not the originating user is initiating the call-completion request, but an Application Server handles the call-completion operations for the user. In this case the UAC on the terminating side cannot derive the served user from the From header or P-Asserted ID, but the caller must be explicitly identified.

Regards, Martin

> Von: Beck, Wolfgang 
> Gesendet: Dienstag, 6. März 2007 15:15
> An: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Betreff: [BLISS] AW: [Sipping] 
> drafdraft-poetzl-sipping-call-completion-02.txt; queue-operation
> 
> 
> Roland,
> 
> is the queue-operation parameter really necessary?
> 'add' is just a synonym for a SUBSCRIBE with an Expire > 0
> 
> The 'suspend' / 'resume' functionality can be done by the 
> calling UA: it
> can ignore ('suspend') or handle ('resume') incoming NOTIFYs.
> 
> What's the point of the 'caller' parameter? The SUBSCRIBE 
> request already
> contains 'From' and possibly P-Asserted-Id. 
> 
> Aren't the 'short-term-denial' and 'long-term-denial' 
> parameters already
> covered by existing SIP response codes?
> 
> 
> Wolfgang
> 
> 
> [non-standard sig as required by dubious EU regulations]
> --
> T-Systems Enterprise Services GmbH
> Aufsichtsrat: René Obermann (Vorsitzender)
> Executive Committee: Lothar Pauly (Vorsitzender)*, Helmut 
> Binder, Albert Henn, Olaf Heyden*, Katrin Horstmann, Ulrich 
> Kemp, Axel Knobe*,
> Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger*
> Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
> Sitz der Gesellschaft: Frankfurt am Main
> WEEE-Reg.-Nr. DE87523644
> *Geschäftsführer gem. § 35 GmbHG
> 
> BLISS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bliss
>=ly need here.
>