Subject: RE: [Sip] Local vs Remote ringback on 180

From: "Chris Hogg" <[email-masked]>
Date: Thu, 27 Jun 2002 10:12:34 +0100

Hi Christer,

Comments in-line.

Thanks,

Cheers
Chris.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: 27 June 2002 00:08
To: Hogg, Chris [MOP:MA01:EXCH]
Cc: Flemming Andreasen; Jonathan Rosenberg; Watson, Mark
[MDN05:EP10:EXCH]; [email-masked]; Bob Penfield
Subject: Re: [Sip] Local vs Remote ringback on 180

Hi Chris,

Chris Hogg wrote:

>
>
> Hi Christer,
>
> I'm a bit late into this discussion, but I'll put my thoughts in
> anyway.
>
> >>However, if you mean that it doesn't change what is sent to the
> listener either
> >>I think what is written in some drafts is wrong. It IS said (at
> least that is my
> >>understanding) that SDP/no-SDP in 180 DOES indicate if a remote
> ringback tone
> >>will be generated or not.
>
>
> >>[CH] It is my understanding that previous (pre-"UNIFY" draft) versions
> >>of the bis did indicate that you could use the presence or absence of
> >>SDP to indicate whether or not the UAC should generate local ringback
> >>or play media.  If my understanding is correct, this was removed
> >>because of the need to solve many other problems (e.g. HERFP, early
> >>media etc) which all arose out of the dependence of session state on
> >>the SIP signalling.  By creating the offer-answer model (and the
> >>additional SIP specific offer-answer rules within RFC3261) then
> >>independence of session state from SIP signalling state was achieved.
> >>I believe the current version of SIP only says that the 180 MAY be
> >>used to generate local ringback but does not say how this is achieved
> >>since it is implementation dependent.

>Yes. My UAC MAY choose to stop forwarding any possible early media
>(again, without changing the state of the session) to the caller, and
>instead generate local ringback, if 180 without SDP is received. My
>proposal was that a 180 without SDP should be used to indicate that the
>UAS is currently not sending any early media (announcement or early
>media) on the session, and that the UAC therefore MAY choose to generate
>local ringback.

[CH] I think the problem you have here is that you are creating a difference
between session state and the caller's perceived view of the session state
and this is confusing the discussion.  I don't think its' quite right to say
that a 180 without SDP is not sending any early media, however I think that
the 180 could still give the UAC the option of playing early media as
currently defined.   

Let me have a go at trying to understand your solution.  As I understand it,
when a Manyfolks/preconditions call setup is underway, if you send a 180
Ringing after the preconditions have been met then (according to the rules
of offer-answer and SIP specific rules surrounding offer-answer) then the
180 Ringing will normally not contain any SDP.  In this case, your proposal
would mean that in the Manyfolks call setup scenario the 180 Ringing would
always result in local ringing.  Your implementation would then treat
receipt of the 200 OK(INVITE) as the trigger to switch off local ringing and
back to media (the session for which is already setup). 

In a non-manyfolks call / non 100 REL / basic call setup flow the 180
Ringing may or may not contain SDP.  If it contains SDP (which is a
pre-answer) then your implementation would play out early media, if it does
not contain SDP then local ringing may be played instead.

Is this a fair analysis of your solution?  If this is the case, then I don't
think there are any changes needed to SIP to be able to support this.

>> I believe that the most likely way to do this currently is to initiate
>> a new offer-answer exchange in an UPDATE/200 OK(UPDATE) with the new
>> offer (from the UAS) indicating that the media stream direction is
>> a=recvonly or a=inactive.  Its' then up to the UAC/implementation to
>> decide what to do now that it knows that there is no media coming from
>> the far end.  This could be playing local ringback or playing an
>> announcement or popping a window up on a screen. I understand the
>> reasoning behind trying to reduce the number of messages sent to
>> achieve this aim, however I am also concerned about creating a special
>> case for local ringing.

>I don't think that is a good idea. Just because the UAS sends UPDATE,
>and stop sending media, it doesn't mean the called party has been
>reached. I think the 180 shall, the way it is defined today, be the
>ringback "trigger".

[CH] The call flow I had in mind was something like:

 <-----180 Ringing
 <----UPDATE(SDP offer)
 -----200 OK(UPDATE) (SDP answer)

Where the UPDATE and 200 OK(UPDATE) are being used to alter the session
state (effectively signalling that the direction of the media (from the UAS
point of view) is now a=inactive or a=recvonly.  The 180 Ringing is still
sent but the additional messages allow the UAS to signal to the UAC that the
far-end media is on hold.  The implementation can then do what it likes
(e.g. play local ringing / play a local announcement etc).

Cheers

Chris.
Nortel Networks

Regards,

Christer Holmberg
Ericsson Finland

> Just my 2 cents.
> Best Regards,
> Cheers
> Chris
> Chris Hogg
> Nortel Networks

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2002 19:53:15 +0300

Hi Chris,

Thanks for your comments!

> [CH] I think the problem you have here is that you are creating a
> difference between session state and the caller's perceived view of
> the session state and this is confusing the discussion.  I don't think
> its' quite right to say that a 180 without SDP is not sending any
> early media, however I think that the 180 could still give the UAC the
> option of playing early media as currently defined.

[CHH] The UAS may still send early media, but since it sends 180 without
SDP it allows the UAC to generate local ringback tone, so the UAC now
can assume that it can "cut" the early media from the caller during that
time. If the UAS does NOT want the UAC to generate local ringback, the
180 would also contain SDP (the same SDP which was used in the 183 to
establish the early dialog, ie the SDP is not a new offer/answer -
simply a ringback "indicator").

> Let me have a go at trying to understand your solution.  As I
> understand it, when a Manyfolks/preconditions call setup is underway,
> if you send a 180 Ringing after the preconditions have been met then
> (according to the rules of offer-answer and SIP specific rules
> surrounding offer-answer) then the 180 Ringing will normally not
> contain any SDP.  In this case, your proposal would mean that in the
> Manyfolks call setup scenario the 180 Ringing would always result in
> local ringing.  Your implementation would then treat receipt of the
> 200 OK(INVITE) as the trigger to switch off local ringing and back to
> media (the session for which is already setup).
>
> pre-answer) then your implementation would play out early media, if it
> does not contain SDP then local ringing may be played instead.

[CHH] My case is when the UAC FIRST receive 183 with SDP, with possible
early media, and THEN receives 180 without SDP. My question is what the
UAC does when it receives that 180? I know bis says that the UAC MAY
play ringback, but the problem is that since it is a MAY it means some
servers may still send early ringback, while other servers actually want
me to generate local ringback (and they will not send early media during
that time, EVEN if the are "allowed" to from a session state point of
view), and THAT is what I am trying to get a clarification on :)

Another issue here is if have a early dialog established in this case in
the first place. Yes, the 183, and/or 180, may contain SDP, but since
they are not sent reliably can they SDP be treated like an answer????
Bis-09 says that the answer MUST be sent reliable, which in a basic SIP
node is in the 200 for INVITE...

> Is this a fair analysis of your solution?  If this is the case, then I
> don't think there are any changes needed to SIP to be able to support
> this.

[CHH] Again, I don't think I am proposing any changes in SIP - all I
want is a general clarification on what is already written in bis- and
the ISUP/SIP mapping drafts :)

> Where the UPDATE and 200 OK(UPDATE) are being used to alter the
> session state (effectively signalling that the direction of the media
> (from the UAS point of view) is now a=inactive or a=recvonly.  The 180
> Ringing is still sent but the additional messages allow the UAS to
> signal to the UAC that the far-end media is on hold.  The
> implementation can then do what it likes (e.g. play local ringing /
> play a local announcement etc).

So, assuming we DO use UPDATE for this, I have a couple of questions on
that:

1. When the called party answers, the UAS has to send a second UPDATE,
to allow media again, because to my understanding it is not allowed to
send a new offer in the 200 for INVITE? In that case we are actually
talking about TWO UPDATE transactions, instead of one, for this
purpose...

2. If the called party answers before the second, or first AND second,
UPDATE transactions have been completed, does the UAS have to "buffer"
the 200 for INVITE until the the UPDATE transactions are completed
(since they both contain offers/answers)? OR, is the UAS in this
scenario allowed to send 200 for INVITE even if there are active UPDATE
transactions with offers/answers?

Regards,

Christer Holmberg
Ericsson Finland

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