Subject: [Sipping] comments on draft-holmberg-sipping-199-02

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2007 14:09:49 -0400

I have a bunch of comments on the mechanism in here; but this is sipping 
and not sip, so I thought I'd deviate from the discussion so far and 
talk about requirements.

I understand the technical issue - that there is no way to know prior to 
the final response that the early dialog has ended. However, I don't 
really understand the use cases and actual problems you are trying to 
solve here with this. You talk about 'releasing resources'. Are you 
talking about dialog state? Is the cost of maintaining dialog state for 
a few more seconds a big deal? Maybe media resources? But most early 
dialogs end up turning into confirmed so there is nothing to save.

I think this needs to have a lot more motivation in terms of use cases 
that demonstrate actual scenarios where the UAC is suffering because it 
doesn't know from the signaling that the early dialog has terminated.

Indeed, it is the use cases that will show us whether this is the same 
issue as HERFP, or something different, a topic which came up in another 
thread.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 16 Jul 2007 12:49:50 +0200

Hi Jonathan, 

>I have a bunch of comments on the mechanism in here; but this 
>is sipping and not sip, so I thought I'd deviate from the 
>discussion so far and talk about requirements.
> 
>I understand the technical issue - that there is no way to 
>know prior to the final response that the early dialog has 
>ended. However, I don't really understand the use cases and 
>actual problems you are trying to solve here with this. You 
>talk about 'releasing resources'. Are you talking about 
>dialog state? Is the cost of maintaining dialog state for a 
>few more seconds a big deal? Maybe media resources? But most 
>early dialogs end up turning into confirmed so there is 
>nothing to save.

It is true that most early dialogs will end up turning into confirmed,
so the use of this is to what happens before that.

I am using the word "resources", but I am not only talking about memory
used for dialog state, or codecs which has been reserved for a specific
dialog and can be released. I am also talking about "procedures".

For example, if pre-conditions are used, the UAC can immediately
terminate procedures, and release resources, related to resource
reservation for a specific dialog, without e.g. having to finish the
procedures, sending an UPDATE and then receive an error response
indicating that the dialog doesn't exist anymore. Those resources can
then be re-used for another early dialog.

Another example is procedures taking place on the media plane, e.g. ICE,
keep-alive and media security (see RTPSEC). Of course, the UAC will at
some point detect that the remote end doesn't reply to messages sent on
the media plane, but by using 199 they could terminate those procedures
without having to wait for a "re-transmisson failure" type of event, and
in some cases waste battery power and/or network resources.

Another example is early media. No, the 199 draft does not solve the
generic early media problem, and is not intended to do so. But, at least
it could help, because the UAC know how many dialogs there are from
where early media may come (it has been identified that it would also be
useful to be able to associate a media stream with a dialog, and that is
something we should probably work on as a separate item).

Regards,

Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Jul 2007 14:09:17 -0400

Christer,

I'm unconvinced that hanging onto the resources you describe below for 
the extra time (64*T1 though I suspect most folks set this timer 
shorter), really saves you anything. That is what I am looking for - 
show me a case where this brief amount of time has a measureable impact 
on system capacity in some way.

-Jonathan R.

---

From: Venkatesh <[email-masked]>
Date: Mon, 16 Jul 2007 12:03:31 -0700

Hi:

I am not sure hanging onto resources for an extra 64*T1 at the proxy is the
only side effect for these call scenarios. The amount of time becomes much
more pronounced at the UA on behalf of which a request got forked. For
example consider an application such as call hunting/sequential find
me-follow me type of service that is implemented as a 'sequential' forking
application at a Proxy. Each hunt attempt can result in an 'early' dialog at
the UA that initiated the call (and potential media reservations and such in
case of some call flows) and all of these would all have to be 'held on to
until' one of the end points in the sequence finally answer.

Venkatesh