Subject: [SIP] Remote ringback.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 10 Aug 2000 19:28:40 -0700

At the SIP bakeoff, a colleague had a conversation with one of the
co-authors of the 183 Session Progress draft.

He (the co-author) informed us that 183 is meant to be used when the remote
UA wants to provide 
some other, unknown message/signal - and _not_ simply remote ringback.

180 with an SDP body should be used for that purpose.

This came as quite a surprise as it seems to be at odds with RFC2543 which
makes no mention about the validity or handing 180 with SDP and states that
183 SHOULD include an SDP for session progress tones (or announcements).
[Without defining session progress tones.]

Even the 183 draft seems to only associate 180 with local alerting.

At the bakeoffs 183 seems to have been implemented widely for remote
ringback.

Can anyone shed some light on this?

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 

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

---

From: Taichi Fu <[email-masked]>
Date: Thu, 10 Aug 2000 21:30:48 -0700

>[Without defining session progress tones.]

The rfcbis (Aug. 06 from http://www.cs.columbia.edu/sip) states that 180 is to indicate that the some attemp is made to alert the called party while 183 is to indicate 'progress of the call which is not otherwise classified' (p.62). So the distinction between 180 and 183 seems clear in rfcbis. Maybe there is still a little room left to exactly define the 180 and 183 semantics, but if it is certain that a called party is located and alerting is being applied successfully, I think 180 should be used. If it is not certain, 183.

---

From: [email-masked]
Date: Tue, 22 Aug 2000 09:37:59 -0500

On the topic of one-way vs. two-way early media: Originally, I believe, the
183 response with a session description was proposed to provide PSTN
compatibility (to handle cut-through audio). If two-way early media is
allowed, doesn't that break PSTN compatibility? For example, suppose I am a
Q.931-to-SIP gateway. If I receive a 18x requesting a two-way media session,
what message do I send on the Q.931 side to set up the two-way media path
without connecting the call? In the interests of compatibility, would it not
be better to disallow early two-way media? If the callee needs to listen for
DTMF, it can always send a 200 OK.

On the question of how to stop early media that has already been started:
Again, suppose I am a Q.931-to-SIP gateway, this time carrying the Q.931
messages as SIP-T attachments. I receive a Progress message with Progress
Indicator 8 from the PSTN side (after having received an INVITE and sent a
Setup). The Prog. Ind. 8 means that cut-through audio is available, so I
send a 183 with a multi-part attachment containing an SDP part and a Q.931
part. Then I receive a Progress message with no information about
cut-through audio, but with some other progress information. I would like to
send a 183 with a Q.931 attachment, and I would not like the absence of an
SDP part to indicate the end of early media. True, I could always resend the
previous SDP part, but to me that requires a little more effort than not
having to duplicate the SDP. It would always be possible to terminate the
early media by sending an SDP that explicitly specifies no media.

---

From: [email-masked]
Date: Tue, 22 Aug 2000 10:07:31 -0500

One more point on early media: What about the handling of media attachments
in unrecognized 1xx responses (184 or whatever)? Would it not solve this
problem, and simplify SIP, to specify uniform handling of media attachments
on all 1xx responses? (Of course, the UAS could not add an attachment to a
non-end-to-end response, but the UAC wouldn't need to worry about that.)

In fact, isn't this another reason for _not_ having the absence of an SDP
attachment stop early media? The UAC could start/stop/modify an early media
stream based on the sequence of attachments received on all 1xx responses
(whether the response codes are known to the UAC or not). The receipt of a
message without an attachment would not mean stop the media, it would just
mean that the particular response was not relevant to early media. The UAC
could handle the responses and SDP attachments completely separately
(providing separation of media and signaling). For example: (1) a 1xx is
received with SDP, and the UAC starts receiving early media; (2) a 1xx with
no attachment is then received, and the UAC processes the response, but
media are not affected; (3) a 1xx is received with an SDP specifying no
media, so the UAC stops receiving early media. (It is true that semantically
a 180 is different from a 183 and a UAC could ignore the SDP on a 180 with
less detriment to the end user than in the case of a 183, but ignoring a
media attachment would hardly be the preferred behavior; the idea is that a
UAC could _choose_ to treat the SDP attachments as a set of messages
completely independent from the responses proper.)

---

From: [email-masked]
Date: Thu, 24 Aug 2000 13:16:04 -0500

Jonathan Rosenberg wrote, among other things, 
> 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?
> 

That someone was me, so I feel compelled to reply. Actually, I mentioned
Q.931, not ISUP. I would guess that the same principles apply to ISUP, but I
am not an SS7 expert.

I believe that Q.931 does allow cut-through audio to be set up during the
"overlapped dialing" phase of the call. In this scenario, while the caller
is still issuing INFO messages containing the dialed digits, the callee
sends a PROGRESS message indicating the presence of cut-through audio. The
caller sets up an audio path in the backwards direction only. Note that in
this situation, the DTMF digits are being sent in the signalling path, not
in the media path.

I believe the equivalent in SIP would be for the callee to send a 183 with a
"send only" SDP. The caller would use multiple INVITEs to extend the
destination address string.

Of course, another possibility in Q.931 would be to send a CONNECT message
to connect the call and create a two-way audio path, and then listen for
DTMF in the audio stream. The equivalent in SIP would be to issue a 200 OK.

I'm not sure of all the details of what happens when you make a calling-card
call from a pay phone, say. Perhaps someone could address that, although I'm
not sure it would be relevant to SIP.

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.

All that said, I have to admit that there is a certain attraction to having
attachments work identically whether in 1xx's or 200's. Still.... 

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?

---

From: "Culpepper, Bert" <[email-masked]>
Date: Thu, 24 Aug 2000 13:49:57 -0500

I see the use of 183 as a means to have media sent from the UAC to the UAS
prior to session establishment (bi-directional early media).  RFC2543bis
already supports sending media to a UAC if it includes a session description
in its INVITE.  I don't see sending a 183 as being required if a UAS only
wants to send early media, except in the case it wants to stop local
ringback.  (Which in almost all cases is anytime it wants to send early
media.)  Otherwise, a 183 sent by a UAS with a session description can
indicate what media it will send (IP address = 0.0.0.0 and port = 0 or
a=sendonly) as a "courtesy" to the UAC or, what media it is prepared to
receive (SDP with non-zero address and port).

Anyway, I like the proposal below. It works great for me.  It allows
pre-call announcements and the ability to receive caller "feedback" at the
UAS prior to session establishment.

Regards,
Bert

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, August 24, 2000 9:29 AM
> To: Jonathan Rosenberg
> Cc: Brett Tate; [email-masked]; [email-masked]
> Subject: Re: [SIP] Remote ringback.
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > 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
> 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.)
> 
> 
> > 
> > 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).
> 
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> 
>

---

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

> 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".
> 

Too many uses of the word "session". Something like "to assist in setting up
the call" would be better.

---

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

True enough. What I was trying to get at is that maybe the UAC is incapable
of sending early media, and if the UAS refuses to set up a call when it
doesn't receive any early media, the UAS may run into interoperability
problems. I suppose there is no need to mention this in the RFC.

> From: EXT Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, August 25, 2000 5:50 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> [email-masked] wrote:
> > 
> 
> > 
> > "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."
> 
> Nobody can require that I send media for anything, so I'm not 
> sure this
> is particularly special or helpful.
> 
> --

---

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

Sounds really good (one typo noted below)

> Sent: Friday, August 25, 2000 5:49 PM
> 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

you forgot the "s" in "descriptions" 

> 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: Sean Olson <[email-masked]>
Date: Sat, 26 Aug 2000 11:28:49 -0500 (CDT)

> > Later session descriptions override 
> > earlier ones.
> 
> Should this say "from the same UAS" to avoid the forking issue?
> 

How has this solved the forking issue?
 
> > 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.

I also thought that this was the case. Why the change?

> > ??? 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

Who is to say that this is incorrect/odd behavior. Just because a bi-directional
media stream has been established, doesn't mean that media HAS to be sent.

--
Sean Olson <[email-masked]>

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sat, 26 Aug 2000 17:02:54 -0700

Sounds great. We should also clarify the difference between 180 & 183 with
SDP. For instance specifying explicitly which response code should be used
for remote ringback during user alerting (180 seems to be the winner) verse
non-user alerting progress tones (183).

Cheers,

Robert.

> Sent: Saturday, August 26, 2000 7:49 AM

---

From: [email-masked]
Date: Mon, 28 Aug 2000 13:15:02 -0500

> From: EXT Jonathan Rosenberg [mailto:[email-masked]]
> 
> [ . . . ]
> 
> 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.
> 

Does PRACK have a way of refusing to change an existing media stream to a
new media type (i.e., in response to a second 1xx after a media stream has
already been set up)? If not, then how far can the analogy with re-INVITEs
be pushed?

On a different topic: 

> From: EXT [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 25, 2000 5:53 PM
> To: [email-masked]
> Subject: RE: [SIP] Remote ringback.
> 
> 

Maybe I was too quick to concede the point. Another way of looking at it is
that if I am writing a gateway, and I see that SIP allows bidirectional
early media streams, I may be wondering how I should handle such requests.
Assume that the PSTN protocol allows only one-way early media; then there
are two choices:
1. When the 183 is received, set up a send-only media stream, regardless of
whether two-way media are requested.
2. Connect the call early on the PSTN side, to allow the two-way media
stream to be set up (perhaps causing problems with billing).
I believe the correct choice is the first one; I am wondering if the RFC
should give guidance on this issue.