Subject: RE: [SIP] Remote ringback.

From: [email-masked]
Date: Fri, 25 Aug 2000 16:33:33 -0500

> -----Original Message-----
> From: EXT Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, August 25, 2000 2:32 PM
> To: Jonathan Rosenberg
> Cc: Brett Tate; [email-masked]; [email-masked]
> Subject: Re: [SIP] Remote ringback.
> 
> 
> Below is some text trying to summarize this discussion. I'm 
> not sure we
> agreed on the parts marked with ???
> 
> 
> Informational (1xx) responses {\MAY} contain message bodies, including
> session descriptions.  

I thought a 100 could not include a body because it's not end-to-end.
However, if I recall correctly, the RFC says an unrecognized 1xx should be
treated like a 100. However, an unrecognized 1xx should be allowed to have a
body. How about the following:

"Informational (1xx) responses (not including 100 but including unrecognized
responses) {\MAY} contain message bodies, including session descriptions."

> Later session descriptions override 
> earlier ones.

Should this say "from the same UAS" to avoid the forking issue?

> The session description allows the UAC to receive special 
> announcements
> or progress tones.  

To explain the purpose of a bidirectional stream, how about adding the
following (before the period): ", and to provide responses to assist in
creating the session".

> If a 1xx response contains a session 
> description, a
> UAC {\SHOULD} cease generating local ringback tone, but resume local
> ringback tone if it receives a 1xx response without a message 
> body from
> the same destination.  

The term "message body" might be a little vague, as there could be a
non-media-related message body.

I thought the last word in the thread was that the absence of an SDP
attachment would not affect the early media. In any case, everything after
the second comma could be removed, as it is duplicated below.

> The media streams are assumed to be 
> bidirectional
> unless marked as send-only or receive-only, as described in
> Section~\ref{sec:sdp}.
  
> Removing the session description in a 
> subsequent
> provisional response restores normal ringback behavior. 

How about: 

"A provisional response without a session description has no effect on any
early media that have already been set up. A provisional response with a
session description that specifies no media (meaning the port in the "m"
line is zero)  restores normal ringback behavior."

[BTW, is it OK to refer to SDP in the main body of the RFC, or is SIP
supposed to support other media protocols as well?]

> ??? Client
> behavior
> when receiving several different session descriptions from different
> branches is undefined. ???
> 

Would anybody object to adding the following:

"A UAS that expects to interoperate with non-SIP endpoints {\SHOULD} be
prepared for the possibility that no media will be received from the UAC
before the INVITE transaction is complete, even when a bidirectional early
media stream has been set up."

> 
> Finally, there's a small bug in the current definition of the 
> send-only
> and receive-only description in Section B.2. RFC 2327 says:
> 
>  a=recvonly
>        This specifies that the tools should be started in receive-only
>        mode where applicable. It can be either a session or media
>        attribute, and is not dependent on charset.
> 
> This is presumably from the viewpoint of the receiver of the 
> SDP. (This
> would certainly be true if I used SDP to invite somebody to a 
> multicast
> conference.)  Thus, if the caller wants to only send, it should
> logically include a 'recvonly' in its SDP, since that's what the
> receiver of the SDP (the callee) would have to do.
> 
> In the current SIP B.2 definition, 
> 
>    If a session description from a caller contains a media 
> stream which
>    is listed as send (receive) only, it means that the caller is only
>    willing to send (receive) this stream, not receive (send). The same
>    is true for the callee.
> 
> This says the opposite: the caller that only sends would set the
> description to send-only. It may be too late to fix this, depending on
> whether anybody actually implements sendonly and recvonly.
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Aug 2000 17:48:43 -0400

New text:

Informational (1xx) responses other than 100 (Trying) {\MAY} contain
message bodies, including session descriptions.  The session description
allows the UAC to receive special announcements or progress tones and to
provide responses to assist in creating the call (``early media'').  If
a 1xx response contains a session description, a UAC {\SHOULD} cease
generating local ringback tone.  Session description in 1xx responses
are interpreted in the same manner as those in 2xx responses.  Later
session descriptions from the same UAS override earlier ones.  The UAS  
can remove the media stream by setting the port number to zero in a
subsequent session description contained in a provisional response and
thus restore normal ringback behavior.  A provisional response without a
session description has no effect on any early media that have already
been set up.

The media streams are assumed to be bidirectional unless marked as
send-only or receive-only.  For SDP, this is described in
Section~\ref{sec:sdp}.  Client behavior when receiving several different
session descriptions from different branches is undefined.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Aug 2000 17:49:53 -0400

[email-masked] wrote:

> media stream has been set up."

Nobody can require that I send media for anything, so I'm not sure this
is particularly special or helpful.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 26 Aug 2000 14:51:26 -0400

Henning Schulzrinne wrote:
> session descriptions from the same UAS override earlier ones. 

I think "override" is not well specified enough. We have defined rules
that make it clear what it means for A to send B an SDP, and then for B
to send an SDP back to A in such a way that we can correlate things. I
believe we must stick with that behavior by somehow mapping the sequence
of SDP we can see into this two phase process. 

So, I would propose that:

1. SDP returned in a provisional MUST be formatted in such a way that it
would be valid if it were returned in a 200 instead, 
2. If an SDP is returned in one provisional response, and then a later
provisional response contains SDP, this new SDP is treated as if it were
the original response to the SDP in the INVITE. 
3. The SDP in the 200 response is also treated as if it were the one and
only SDP received from the UAS, along the same lines as (2).

Note that this has some implications, particularly, you cannot add a
media stream from one 183 to the next.

Some other interactions to consider. We allow the INVITE to not contain
SDP, and then the 200 and ACK both contain SDP (again, everything must
be mapped to the rules for this two-phase SDP exchange). In this case,
can a 183 be sent with SDP if there was no SDP in the INVITE? I would
assume yes, but if, and only if, PRACK is used, and the PRACK contains
SDP (this way, the two phase exchange is 183/PRACK). Now, if there are
subsequent 183, each with SDP, those 183 COULD do things like add media
streams, as they represent the initial SDP in the two phase process.

Now, that raises another issue. If the original INVITE does contain SDP,
and then the 183 contains SDP, can the PRACK contain SDP? I say no -
same reason you shouldn't have SDP in the INVITE, OK and ACK.

Comments?

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 26 Aug 2000 15:22:30 -0400

Jonathan Rosenberg wrote:

> media stream from one 183 to the next.

I would hope that we keep this early media business limited to where it
is absolutely needed (old telephony interworking where charging is
involved), so allowing to add media, modify media and so on seem to go
down a path of complexity that isn't warranted by the application and
only further muddies the SIP session model.  For more complicated
scenarios where there are different logical sources of media during a
session, it seems that a regular INVITE/200 and then REFER or re-INVITE
is much cleaner. (I'm not arguing that Jonathan wants to go there, just
that I think there's a danger of making what started to be an innocent
little feature into a complexity nightmare. Thus, anything that
restricts behavior is good for me.)

> SDP (this way, the two phase exchange is 183/PRACK). 

Since PRACK isn't in 2543bis, this needs to be worded more generically.
Also, this would have to be described in the 100rel draft.

> Now, if there are

Do we really want to go there?

> same reason you shouldn't have SDP in the INVITE, OK and ACK.

Yes, again to keep it (kind of) simple.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs