Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 14 Aug 2002 13:10:50 -0500

A few comments below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Wednesday, August 14, 2002 8:55 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] new draft-ietf-sipping-isup-05
[snip]
> 
> I remain convinced that there are only two solutions:
>   1) use a 183 if remote ringback will be provided, instead of 180
>   2) include some indication (e.g. Alert-Info) in a 180 if remote ringback
> 	will be provided
> 

As I stated in a mail a couple of days ago (since which this thread has
merrily rolled on by) I am willing to put something that is roughly option
(1) in sipping-isup-06. It will appear in a few days.

I also think option (2) is worth discussing further in the context of a more
fully-featured early media system.

Can we stop talking about this now?

> Since this whole problem of early media arises because of PSTN
interworking,
> the solution needs to be documented in the ISUP-SIP draft. The issue was
> raised during WGLC, but has not yet been adequately addressed 
> in the draft.

It was raised in the context of PSTN interworking, but it is not necessary
confined to just SIP-ISUP interworking (it would apply equally to other
forms of PSTN interworking) and in my opinion it could arise for other
services in SIP networks unrelated to PSTN interworking. Again, I believe
that we need a general solution for early media, but I do not think we need
to provide it in sipping-isup-06.

> 
> Bill Marshall
> [email-masked]
> 
> -----original message-----
> Date: Wed, 14 Aug 2002 10:55:29 +0300
> From: Gonzalo Camarillo <[email-masked]>
> To: William Marshall <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Sipping] new draft-ietf-sipping-isup-05
> 
> Bill,
> 
> William Marshall wrote:
> > 
> > Gonzalo,
> > 
> > > Your local policy could look like this:
> > >
> > > 1) If there is media coming from a stream, play it (don't 
> play local
> > > ringback), regardless of the status of the callee 
> (alerted or not).
> > >
> > > 2) If there is no media coming from any stream (they are 
> all inactive or
> > > sendonly or no SDP has been received) AND the user is 
> being alerted (180
> > > has been received) play local ringback.
> > >
> > > 3) If there is no media AND the user is not being 
> alerted, do nothing.
> > >
> > 
> > The interesting case, of course, is the one you don't list. 
>  If SDP has
> > been received, and either explicitely says "a=sendrecv" or does not
> > contain the "a=inactive" nor "a=recvonly", AND the user is 
> being alerted
> > (180 received).  Do you play local ringback or not?  Both 
> choices are wrong.
> 
> I do list this example. It is number 1. There is media coming
> (sendrecv), so regardless of the status code that has been 
> received (180
> or 183) you do not play local ringback.
> 
> If the UAS did not intend to send early media, it should have set the
> stream to inactive.
> 
>  
> > Suppose this were not just a "local policy", but instead 
> was mandated
> > behavior that the UAS could depend on.  How can the UAC and 
> UAS combine
> > to provide the correct results --- (I'm assuming the UAC 
> doesn't know
> > in advance whether the UAS will be doing local or remote 
> ringback; if your
> > crystal ball works, use it, otherwise send SDP offer with 
> "a=sendrecv").
> 
> Remember that the direction attribute that the UAC sends can be
> downgraded by the UAS in the answer (offer/answer model). Therefore,
> your UAC does not need a crystal ball at all. The direction 
> attribute to
> be used will be the one the answerer chose.
> 
> >   If the action in this case is to play local ringback:
> > Consider the case when the UAC places a call to a PSTN 
> gateway, or some
> > other UAS that intends to do remote ringback.  This case 
> leads to the race,
> > between the signaling message (180) and the media.  If the 
> media arrives
> > first, then case #1 applies and all is OK. if the signaling 
> arrives first,
> > we get locally generated ringback which is then preempted 
> by the remote
> > ringback.  Result: bad user experience.
> 
> You cannot change this, whatever flag you use. The UAC sends an INVITE
> and suddently it begins receiveing media, without having received any
> SIP response besides the 100 Trying from its outbound proxy... what do
> you do? No flags will help you in this situation. Again, this is up to
> your local policy.
> 
> But this is a more general problem. What if I put a call on hold
> (a=inactive), but I still receive media... again, what to do 
> is up to my
> local policy...
> 
> 
> >   If the action in this case is to not play local ringback:
> > Consider the case when the UAC places a call to another SIP 
> endpoint that
> > does not intend to do remote ringback.  If this "normal" 
> UAS sends SDP
> > with a=sendrecv and then sends 180, there will be no 
> ringback.  So the SDP
> > from the UAS needs to be a=inactive.  Now the 180 generates 
> local ringback.
> > But when the called party answers, the UAS needs to do an 
> UPDATE/200-OK
> > exchange to change the SDP to a=sendrecv.  This kills the 
> post-cutthrough
> > delay, and clips the "hello."  Result: bad user experience.
> 
> The SIP sequence you have described is exactly how you would implement
> this scenario using current SIP. IMO, the only thing needed is a
> recommendation in the SIP spec saying that you may want to 
> play what you
> receive over an inactive stream (at least for a short while) 
> in order to
> avoid media clipping. Would you be happy with this solution? (no new
> flags are needed).
> 
> I believe that this is the best solution to this problem. The 
> flag some
> have proposed would have basically the same meaning, so we could save
> creating it.
> 
> Opinions?
> 
> > 
> > If the UAS included a flag with the 180 that indicates 
> whether it will
> > be doing in-band-ringback/announcements or not, then the UAC can
> > do the right thing.  The UAS certainly knows when it will 
> be starting
> > to transmit media packets; all it needs to do is say so.
> 
> The solution I have proposed would solve this problem without 
> the flag.
> As I said in previous mails, the flag would save a UPDATE/200 OK
> exchange, but the flag is not really needed for solving the 
> problem. The
> problem wit the flag you propose is that it breaks the offer answer
> model. Right now, the offer or the answer you receive is to be used
> "right now". With your flag, you would be sending an answer (or offer)
> to be used only when a 200 OK had been received... or even worse, you
> would be saying that the UAC should treat the first RTP packet as if a
> 200 OK had been received. Are you also going to propose to get rid of
> the 200 OK, since, at the end of the day, it would not bring extra
> info??
> 
> I would rather stick to the current approach. That is, by 
> inspecting the
> last offer/answer exchange I know what is *currently* going on.
> 
> > 
> > Bill Marshall
> > [email-masked]
> > 
> > p.s.  I really don't think the intricacies of this "local 
> policy" are
> > covered by the three sentences in isup-05 section 8.2.3 
> which explain
> > the "SHOULD generate ringback tone".
> 
> It has been said many times, and even in this thread Jon answered this
> same question once more. Anyway, the isup-sip mapping draft does not
> intend to define every SIP or ISUP mechanism that may be used 
> in an ISUP
> to SIP call. We only reference mechanisms that are defined elsewhere.
> That's why, for instance, we have not copy/pasted RFC 3261 
> and Q.767 in
> the draft. Early media needs to be defined in the SIP spec, or,
> eventually, if we discovered that it is a complex enough problem, in a
> separate document... but never in the ISUP SIP mapping draft.
> 
> Best regards,
> 
> Gonzalo
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 15 Aug 2002 08:43:20 +0300

Hi,

> >   2) include some indication (e.g. Alert-Info) in a 180 if remote ringback

I have a big problem with (1). In fact, I am surprised that Bill brings
up this proposal once again, because Adam and I have been fighting it
already for some years, with endless discussions (like this one) in the
mailing list.

Let me say it one more time: the status code informs you about the
status of the other party. Therefore, if the other party is being
alterted, NO MATTER IF THERE IS EARLY MEDIA OR NOT, a 180 MUST be sent!!
(never 183)

Now, let me introduce the philosophy of offer/answer and UPDATE. Of
course, this is the philosophy that we followed in manyfolks as well.
The idea is to decouple dialog state and media state. That is why
UPDATEs that change the media state (offer/answer) can be sent without
affecting the dialog state. This simplifies a big deal a number of
things, and it is the base of the new offer/answer model.

And now, all the "new" proposals for solving early media, try to couple
them again... why????? If folks like the ISDN state machine they should
work improving ISUP, not SIP.

To help you guys thinking a little bit more in general, a number of
persons have complained about media clipping in this situation: an
inactive stream is established with a 180 response. When the callee
answers, the UAS sends a 200 OK for the INVITE and an UPDATE making the
stream sendrecv at the same time. If the first RTP packet arrives before
hte UPDATE, there will be media clipping.

Well, think of this situation as if you had a call on hold (inactive)
and then put it off hold (sendrecv) and start speaking again. As I said,
the media handling and the dialog state are independent. Therefore, it
does not matter to have an early dialog (early media) of a confirmed
dialog (call on hold scenario). To avoid this problem (the call on hold
and the early media clipping), the only thing you can do is recommend
implementors to play (or maybe buffer for a little while) what it is
received on a inactive stream, because you cannot avoid that race
condition.

Best regards,

Gonzalo