Subject: RE: [SIP] Remote ringback.

From: [email-masked]
Date: Mon, 21 Aug 2000 10:16:48 -0500

> -----Original Message-----
> From: EXT Brett Tate [mailto:[email-masked]]
> Sent: Thursday, August 17, 2000 1:19 PM
> To: Fairlie-Cuninghame, Robert; [email-masked]
> Subject: Re: [SIP] Remote ringback.
> 
> [ . . . ] 
> 
> If A receives 18x with SDP from B, can/should A start sending to B?  I
> assume no for 180 and yes for 181, 182 and 183 but I have not found it
> explicitly stated anywhere.

Am I reading this wrong? Surely any 18x with SDP from B to A means that B
will be sending one-way audio and A cannot send audio to B???

> 
> There were some test cases that I was hoping to test at the 
> bakeoff, but
> didn't get the chance.  Text relating to the test cases may 
> be useful in the
> rfc.
> 
> - A invites B.  B replies 180 with SDP.  B then replies 180 
> without SDP.
> Expected result: A should start providing local ringback.
> 

I would disagree with this for a few reasons:
1. In the case of PSTN interoperability, once the remote end starts sending
one-way audio, the remote end has to continue sending one-way audio until
the call is either answered or disconnected. (E.g., in ISDN, a PROGRESS with
no indicator for cut-through audio doesn't mean the far end has stopped
sending cut-through audio.)
2. Certainly in the case of 183, there may be attachments other than an SDP
attachment, so receiving no SDP should not mean "stop receiving audio", and
it would not be good if the interpretation of attachments were different for
180 than for 183.
3. Unless PRACKs are being used, A doesn't know whether the 180's have been
received out of order. (Which isn't really much of an objection, given that
B may send a new 180 with a different codec, but still, B should be required
to explicitly state that there is no more audio; see next point.)
4. In an INVITE, the absence of an SDP attachment doesn't mean "create a
session with no media". So if B wants to stop sending cut-through audio, it
should send a 180 with an SDP attachment without an "m=" line. Then the SDP
attachments in the 180 and the INVITE would work the same way. (And it would
still be possible for B to tell A to start providing local ringback, despite
the rather weak first point.)

> - A invites B with multiple codecs.  B replies 180 SDP with 
> codec 0; then B
> replies 180 SDP with codec 2.  Expected result: A should stop 
> using codec 0
> and start using codec 2.
>

Agree.
 
> - A invites B.  A forking proxy was involved.  A forking 
> proxy returned two
> 18x with SDP and different "TO" tags.  Should the received 
> media be mixed?
>  I assume no until maybe after having received a 200 on one 
> of the legs.
> 
> 
> [ . . . ]

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

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 21 Aug 2000 15:11:57 -0400

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, August 21, 2000 11:16 AM
Subject: RE: [SIP] Remote ringback.

> will be sending one-way audio and A cannot send audio to B???

I agree if B uses 0.0.0.0 as a connection address.  However if B uses a
valid
connection address, I have not explicitly seen in rfc2543 how A should
handle
it.  I think that there is a potential concerning a 182 for A to pass inband
DTMF
to move up in the queue.

I also foresee the same sort of DTMF possibility concerning a 181.  It could
be
used concerning calling-verses-forwarding billing acceptance, to pick a
forwarding
location, or to allow an attempt to bypass the forwarding.

I also foresee using the same sort of DTMF possibilities with a 183.  The
user could
select various options relating to the "special announcement".

I agree that the thought of two way media being established before 200/ACK
seems strange.  But I think that one way media is just as strange though
useful
from a PSTN perspective.

> sending cut-through audio.)

It does if the proxy CANCEL B that provided remote media, and proxy INVITE C
which does not provide remote media.

> to explicitly state that there is no more audio; see next point.)

I completely agree the PRACKs are the means to help ensure order.  However
if PRACK is not used, only reception order or Date can be used.

> the rather weak first point.)

This is one way to do it; I'm not sure if it is the best way.  However my
main
point is to hopefully get rfc2543 to clearly state what 18x means when used
in a variety of test flows.  I think that a 180 without SDP could/should be
used for clarity from a normal 180 with/without SDP perspective.  However
if the working group wants to do some sort of media alignment, connection
address, media port means to resolve the issue,  I won't protest.

Just seeking clarity and resolution.

-Brett

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Aug 2000 02:06:58 -0400

Brett has asked for a clear semantic to the inclusion of SDP in 183.
Here is my proposal.

To keep ourselves sane, and to simplify life, I would propose that the
semantics of SDP in 183 be identical to those if the SDP were returned
in a 200. The difference is only in the call state; 200 OK means the
call is established, 183 (or any 1xx) means progress.

Based on this rule, SDP in the 183 with a 0.0.0.0 line means that the
UAS does not want to receive, just send audio. Classic one way cut
through. SDP in the 183 with a non-zero IP address and port means that
bidirectional audio is allowed; the UAC should send whatever the user is
saying. Of course, any good implementation will let the user know that
this is happening. Someone pointed out that bidirectional audio before
call acceptance doesn't work in ISUP. How, in this case, are things like
calling card numbers, etc. which require DTMF collection before call
completion, handled?

This also answers the question about turning off media stream. Same as
how re-INVITEs work. If you want to turn it off, return an SDP in
another 1xx with that m line set to port zero. Sending a 1xx later with
no SDP has the same effect as a re-invite with no SDP (which means no
change in session state at all). 

-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.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 24 Aug 2000 09:29:23 -0400

> calling card numbers, etc. which require DTMF collection before call

I don't like this alternative as it makes it impossible for the caller
to send RTCP in response to early media. Instead,

a=sendonly

seems like the more appropriate mechanism. (There's also a security
implication: if the UAS sends an IP address, the receiver at least has a
chance of rejecting bogus audio packets as long the attacker can't
intercept the SDP *and* forge IP addresses. Without this, it would be
pretty easy to just send RTP as 'early media' to any local SIP phone,
for example.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Benny Prijono <[email-masked]>
Date: Thu, 24 Aug 2000 18:29:20 +0100

> change in session state at all).

If UDP is used, then the 1xx responses from UAS can arrive out of
order in the UAC. So how can the UAC knows which response sent first?

Or should we mandate that the version number in the SDP origin field
MUST be increased when UAS changes the SDP in 1xx?

-- 
cheers,
Bennylp

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Aug 2000 00:33:39 -0400

> pretty easy to just send RTP as 'early media' to any local SIP phone,

OK, I like this much better too.

> MUST be increased when UAS changes the SDP in 1xx?

You will need to use reliable provisional responses whether you send one
183 or more. Reliable provisional responses also gives you ordering.

Cliff writes:
> Certainly it is true that SIP is not a telephony protocol, and it is not
> necessarily the case that things in SIP should work the same way they do in
> PSTN protocols. However, purely from the point of view of semantics, if the
> purpose of an INVITE is to create a session, and if a full two-way media
> stream is created before the INVITE transaction is complete, things seem a
> little wonky: a session has been created, therefore the INVITE transaction
> should have terminated. All the examples that Brett gave relating to the
> early two-way media stream involved DTMF collection. In a sense, then, the
> early two-way media stream is a work-around for not being able to, or not
> wanting to, send DTMF tones in the signalling path.

No; one can imagine "early media" that uses speech recognition. 

I agree its on the clunky side; in the absence of the PSTN I would argue
for sending a 200 and forgetting about this early media stuff. But,
we've been through it before and it appears critical for PSTN
interoperability. To minimize damage, I am proposing that the handling
of SDP in 183 mirror that of SDP in 200 OK, so that they are nearly the
same.

> It may well be that a given UAC is unwilling or unable to set up a two-way
> early media path as requested by a UAS. Perhaps it would be worthwhile to
> specify what the UAC should do in that case: should it set up a one-way
> media path, or should it refuse to set up any media at all?

Nothing forces a client to send media even if the other side indicates
it wishes to receive it. A UAC that refuses to do two way early media
simply won't sent early media irrespective of the SDP in the 1xx.

We should be sure to capture all of this in the bis draft.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 25 Aug 2000 14:31:46 -0400

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.  Later session descriptions override earlier ones.
The session description allows the UAC to receive special announcements
or progress tones.  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 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. ??? Client
behavior
when receiving several different session descriptions from different
branches is undefined. ???

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.

---

From: "Rick Workman" <[email-masked]>
Date: Fri, 25 Aug 2000 15:40:25 -0400

> provisional response restores normal ringback behavior. ??? Client

I'd really prefer if no SDP content meant no change in the current media
configuration regardless of what message carried it. If a UAS wants to
terminate early media, shouldn't it send a media description with port=0 as
in any other stream removal (Section B.5)?

I haven't been following this thread in detail, so apologies if I've mssed
some key issue in the discussion.

Rick

---

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

Rick Workman wrote:

> 
> I'd really prefer if no SDP content meant no change in the current
> media configuration regardless of what message carried it. If a UAS
> wants to terminate early media, shouldn't it send a media description
> with port=0 as in any other stream removal (Section B.5)?
> 

Good point. Changed.

---

From: Benny Prijono <[email-masked]>
Date: Wed, 30 Aug 2000 15:01:36 +0100

Hello all,

As Henning has pointed out below regarding the meaning of
recvonly/sendonly attribute in SDP body, it seems that there's an
incompatibility between SDP draft and SIP one.

Has this been confirmed to the SDP authors? Because I got the
impression that Henning was not sure about this. And if this is really
the case, then has a consensus been made regarding which one to use?

Personally, although I have implemented them as in the SIP draft, I
don't mind if it has to be changed.

cheers,
Bennylp