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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Apr 2007 19:02:39 -0400

Adam's post just jogged me - I had started to write up some comments on 
the latest version of this draft before the meeting, but I never got 
around to sending them. Here they are (updated based on Adam's comments):

1) I concur with Adam that using SUBSCRIBE to add an entry to the queue, 
and unSUBSCRIBE to remove an entry from the que is wrong. He has given a 
lengthly explanation that I don't need to repeat.

2) It is a little unclear to me whether the UAS that rejects the initial 
call is also the one to host the queue, or whether some other server is 
expected to host the queue. There is mention that no state agents are 
used, and the examples show the same UAS doing both jobs, but I question 
whether this is realistic. In a practical sense I expect it will often 
be a separate server for this, with selective routing by the home proxy 
sending the SUBSCRIBE to the required server. This is practically a 
necessity if there is more than one UA registered for the same AOR, 
because otherwise there is no guarantee that the SUBSCRIBE will get to 
the correct UA.

If there will ever be a separate server managing the queue then using 
Allow-Event in the response to invite to indicate that this capability 
is available is inappropriate.

3) While the implementation does require a queue, it doesn't appear that 
the subscription is really to the status of the queue, since there is no 
visibility to the queue itself. Instead, each subscription seems to be 
to a unique resource - a queue *entry* - that is created by the 
subscription. But there is no name for this resource. This might make it 
impossible to establish a new subscription to the queue entry if the old 
one expires.

4) Section 3 talks about two queues (A-queue and B-queue) but this is 
never mentioned again. If this is intended then the concept should be 
further expanded.

5) The message examples following Figure 1 are not consistent with the 
flow shown in the figure.

	Thanks,
	Paul

_______________________________________________
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: Adam Roach <[email-masked]>
Date: Thu, 05 Apr 2007 21:09:55 -0500

Paul Kyzivat wrote:
> 2) It is a little unclear to me whether the UAS that rejects the 
> initial call is also the one to host the queue, or whether some other 
> server is expected to host the queue. There is mention that no state 
> agents are used, and the examples show the same UAS doing both jobs, 
> but I question whether this is realistic. In a practical sense I 
> expect it will often be a separate server for this, with selective 
> routing by the home proxy sending the SUBSCRIBE to the required 
> server. This is practically a necessity if there is more than one UA 
> registered for the same AOR, because otherwise there is no guarantee 
> that the SUBSCRIBE will get to the correct UA.
>

This was another objection I raised to the mechanism in draft-poetzl -- 
it is designed and described almost exclusively in the context of PSTN 
interoperation. Its application to pure SIP networks is difficult to 
deduce from the current document, and it suffers from a number of 
shortcomings (such as the one you describe above). *If* we decide to 
take the mechanism down the path proposed in draft-poetzl, it will need 
a fairly radical re-write so that it describes the mechanism in terms of 
a pure SIP network (with discussion of how it applies to PSTN interwork) 
instead of being written as if it were primarily a PSTN interworking 
document.

/a