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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 10 May 2001 10:50:27 +0100

I was looking for the normative specification of this 0.0.0.0 in the SDP c
line. The RFC does not specify it, and the service examples mentions it but
this is informational. Given that the interpretation of this particular c=
line would appear to be not to send data, then I would judge thsi requires
some statement in a standards track SDP specification.

Have I missed it somewhere?

We also need a change to the service-examples draft to change the text that
states that either party may take the session off hold, as you have
indicated that is wrong.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Jonathan Rosenberg[SMTP:[email-masked]]
> Sent: 	25 April 2001 18:54
> To: 	'Drage, Keith (Keith)'; [email-masked]
> Subject: 	RE: [SIP] I-D ACTION:draft-ietf-sip-service-examples-01.txt
> 
> 
> 
>  
> 
> > -----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.

---

From: [email-masked]
Date: Thu, 10 May 2001 13:23:14 -0500

> Have I missed it somewhere?

Putting media streams on hold isn't a generally applicable
SDP feature (e.g. it would make no sense in, say, a multicast
of a space shuttle launch); it's something SIP needs to
define in the context of multimedia. So, you won't find it
in any SDP drafts.

The normative text you're looking for is in appendix B of
the bis-02 draft, which describes SIP's *usage* of SDP. In
particular, look at section B.6.

/a