Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Apr 2001 13:54:51 -0400

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2001 6:01 AM
> To: [email-masked]
> Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt
> 
> 
> The initial enquiry and Brett's response assume that the 
> result of hold is
> asymmetrical. While the service examples draft is an attempt 
> to emulate PSTN
> services, the service result in this case is not the same.
> 
> The service-examples draft contains the following key words
> 
> .  Note that either party can take the other party off
>    of hold.  
> 
> SIP hold removes the media stream(s). They are removed at 
> both ends. If A
> holds B, then both parties are in the state of having no media stream.

No, that is not true.

If A sends B a re-INVITE with a stream held (meaning its connection address
is 0.0.0.0), the only thing this means is that A does not wish to receive
media from B. It does not mean that A should cease sending media to B,
although it can always do that as a UI issue.

The whole idea of the 0.0.0.0 "hack" was that it achieved call hold as a
natural side-effect of an existing operation. By assigning it the meaning of
"hold" as well, we allow UI's to take advantage of knowing about being on
hold, yet allow for the service to work for devices that don't know anything
about hold. All they know is that they cannot send packets to the
nonexistent 0.0.0.0 address.

As a consequence, no special behavior should be implied from SDP with
0.0.0.0 in the c line, beyond, "don't send me media".

> The process of coming out of hold requires merely adding a 
> media stream and
> therefore either end can invoke this function. 

No, a stream is not "added". Adding a stream implies the addition of a new m
line in the SDP. That is not the case. One comes off of hold by sending a
reinvite with the c line of the existing, held stream changed back to a
valid IP address.

The only note 
> I would make is
> that if A held B, then A presumably did it to release 
> resources to perform
> some other function (this is the purpose of hold in both the 
> PSTN and ISDN).
> If B tries to resume the call before A is ready, then those 
> resources may
> still be unavailable, and A may reject the request (e.g. with 
> "busy here" or
> "busy everywhere"). 

This complication is non-existent with the correct, unidirectional
interpretation of hold.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.