Subject: Re: [Sipping] Re: Early media draft

From: William Marshall <[email-masked]>
Date: Tue, 26 Nov 2002 17:24:21 -0500 (EST)

Gonzalo asked:
> > > >  Also note that due to
> > > > possibilities of collision of offers, and random retry intervals, the case
> > > > of playing out media on an inactive stream may last a long time.
> > >
> > > When you think of a long time, which order of magnitude are you thinking
> > > of? Some hundreds miliseconds?... one second?... if you cannot tolerate
> > > that, you should use a tightly coupled architecture like the one
> > > provided by ISUP.
> > 
> > Just like the backoff problem with 802.3, the distribution has a long
> > tail.  The point is that the UA needs to deal with it, and any sort of
> > intelligent "play-media-for-only-a-little-while-on-inactive-channel"
> > isn't going to work.  Again, the UA needs to deal with the inconsistency
> > between signalled media characteristics (SDP) and the actual media.
> > 
> 
> Why isn't it going to work? 

What won't work, in my comment above, is any attempt by a UA to assume
the media being received over an inactive stream will only last a short
period of time.  The distribution has a long tail, and "short" could be
many seconds.  I'd consider that essentially forever, since it is not
just a few RTP packets.

> ..... You have an inactive stream and have
> received a 180. You play a locally-generated ringing back tone. Then you
> begin receiving media, and you play it out (you can also stop the
> ringback tone). All the time you were waiting for the media, you knew
> that you had to generate local ringback. If the stream was sendrecv from
> the beginning, how can you know if you have to generate local ringback?

I think a response code of 180 means generate local ringback, independent
of whether media streams are a=sendrecv or a=inactive.  The de-coupling
is good, and there is no reason to break it here.  So even if the media
says a=sendrecv, you generate a local ringback on 180... then preempt
it when any media arrives.  I think this case just follows directly
from your previous argument about playing all media.  

Bill Marshall
[email-masked]

-----original message-----
Date: Tue, 26 Nov 2002 18:31:15 +0200
From: Gonzalo Camarillo <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sipping] Re: Early media draft

Bill,

William Marshall wrote:
> 
> Gonzalo,
> 
> > I know that coming from the PSTN world is difficult to digest this
> > concept, but this is the way it is. SIP is not the PSTN.
> 
> You missed the whole point.  That is exactly what I was saying.
> Nothing in my comment was addressing the PSTN.  It is purely a
> synchronization problem in SIP, which comes about because of the
> loose coupling between the media description passed in the signaling
> and the media itself; it is not a problem at all in the PSTN.

OK, it seems that we are saying the same thing.

> However, customer expectations that their media will not be clipped
> are independent of the mechanism, whether it is being carried over
> IP or PSTN or FedEx.
> 
> The conclusion is that maintaining an accurate coupling between
> the signaling and the media has significant complications in common
> use cases, that are just not worth the effort.

Agreed.

>  We need to deal with
> the inconsistent cases in SIP for short periods, at least, and by
> doing so we solve the general case as well.

That's exactly what I was proposing.

> 
> > >  Also note that due to
> > > possibilities of collision of offers, and random retry intervals, the case
> > > of playing out media on an inactive stream may last a long time.
> >
> > When you think of a long time, which order of magnitude are you thinking
> > of? Some hundreds miliseconds?... one second?... if you cannot tolerate
> > that, you should use a tightly coupled architecture like the one
> > provided by ISUP.
> 
> Just like the backoff problem with 802.3, the distribution has a long
> tail.  The point is that the UA needs to deal with it, and any sort of
> intelligent "play-media-for-only-a-little-while-on-inactive-channel"
> isn't going to work.  Again, the UA needs to deal with the inconsistency
> between signalled media characteristics (SDP) and the actual media.
> 

Why isn't it going to work? You have an inactive stream and have
received a 180. You play a locally-generated ringing back tone. Then you
begin receiving media, and you play it out (you can also stop the
ringback tone). All the time you were waiting for the media, you knew
that you had to generate local ringback. If the stream was sendrecv from
the beginning, how can you know if you have to generate local ringback?

> While I don't doubt that having direction attributes would be useful
> information to drive a GUI, I think it can be better determined locally
> by what is actually being received, than by putting a load on the
> signaling entities.

I do not agree. It is useful to know if the remote end intends to send
media or not. Assume that I press the mute button in the middle of a
conversation. If I inform your UA that I do not intend to send media for
the time being, it can play music for you, for instance. If I do not
signal anything on the SIP plane, you cannot provide this type of
service.

>  Leaving the decision to re-offer up to local
> policy means the receiver can't depend on it, so needs the alternate
> indication if it wants to present such a GUI.
> 
> > However, your proposal does not address when to generate local ringback.
> 
> I was addressing pure SIP IP-to-IP issues, not PSTN interworking.

You can provide ringback tone in an IP-to-IP call. Why do you relate
rinback tone with the PSTN?

Thanks,

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 27 Nov 2002 10:09:59 +0200

Bill,

> many seconds.  I'd consider that essentially forever, since it is not

You are talking about a problem that has always been present in SIP, and
that has been already discussed several times in MMUSIC. It is not at
all related with the early media draft. The general problem is:

I send a re-INVITE with a new offer. When can the UAs start using the
new session parameters (e.g., codecs, IP addresses, port numbers...)?

If the UAC is unable to continue using the old parameters, it will
probably start using new parameters right away, and if the re-INVITE
fails, it will terminate the session.

Does the UAS need to wait for the ACK before using the new parameters?
What about if it is an UPDATE?

As you can see, these are issues that are caused by the loose coupling
SIP uses.

If you have some proposals to resolve them, they belong to the
offer/answer work (MMUSIC) or maybe to the main SIP spec (SIP). The
early media draft is informational in nature, and uses mechanisms
defined elsewhere. Therefore, I do not think yours is a problem related
to the early media draft. You are speaking about a general SIP problem.

> is good, and there is no reason to break it here.

No. As it has been pointed out literaly millions of times already, a 180
response only means that the remote user is being alerted. It does not
say anything about ringing, remote or local.

Here you have a brief review of the contents of the draft, so that we
are clear about what the decoupling means.

Your UA has two sources of information:

1) status of session establishment (status codes)
2) presence or absence of incoming media (SDP direction attributes)

With these two pieces of information, you make the decision about
whether or not generating ringback tone, graphical alterting, or
whatever, based on your local policy.

And if you want to have a large network where all the elements behave in
the same, expectable way, you should standardize the local policy for
all the elements in the network.

Thanks,

Gonzalo