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

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 21 Aug 2002 14:39:24 -0500

Christer,
I only recently began looking into this issue on the sip and sipping archives, so I apologize for entering the discussion at such a late date.  (That explains the unusual format of the attached copy of your email on July 3 from the sip archive.)

I am very confused by this discussion.  Why should the meaning of 180 be changed according to the negotiated value of the directionality attribute of the media?  According to your proposal below, a UAC receiving 180 will not generate local ringing if SDP has been negotiated with UAS media active (not on hold).  And a UAC receiving 180 MAY generate local ringing if either no SDP has been negotiated or the SDP that has been negotiated has UAS media "on hold".  (Essentially the same semantics are described in the manyfolks draft.)

I think this coupling of the meaning of 180 to the state of the media is unwarranted and should be removed from the manyfolks draft.  The text in question is: "Note that now the media stream has been already established, and A has received a 180 (Ringing) response. Since the direction of the stream is "sendrecv", A will not generate local ringback, since it assumes that it will receive early media over this stream. However, if B wants A to generate local ringback, it can put the media stream on hold in SDP4. In this case, B would put the media stream off hold by sending an offer in an UPDATE request which would be sent at the same time as the 200 (OK) for the INVITE (10)."  Note that this is the only text I could find anywhere that couples the meaning of 180 with the state of the UAS media.

Here is some other relevant text from various documents.  First of all, Jon Peterson (from the sipping archive) has recently added the following clarification of the meaning of 183 to the sip-isup draft: "Accordingly, we have amended this text in 7.2.6 and 8.2.3 to reintroduce the 183 response code as the code that should be sent when locally-generated ringtone is undesirable or inappropriate."  In describing the 180 ringing response, RFC 3261 says: "The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback."  But manyfolks clearly says: "A user agent server that receives an offer with preconditions SHOULD NOT alert the user until all the mandatory preconditions are met; ..."  These mandatory preconditions can only be met via successful SDP negotiation.  Just for the record, I completely agree with these three quotes.
Furthermore, there is a timing issue that absolutely requires us to eliminate clipping at answer.  Some of us have been down this road before and there is no possibility of compromise here.  Any procedure requiring the use of UPDATE immediately before (or possiblity during) 200 (INVITE) to take the UAS off hold is unlikely to be reliably acceptable to the end user (IMHO).
Allow me to propose an alternative approach.   Allow 180 and 183 to toggle the generation of local ringing, independent of the state of the media.  If the UAC gets a 180, it MAY initiate local ringtone.  If media is in sendrecv, it becomes an implementer's choice how to deal with this (as discussed in other mails in the archive).  If the UAC gets a 183, it stops any locally-generated ringtone.  If you get another 180 afterwards, the UAC MAY initiate local ringtone again, etc.  Just because the UAS is not on hold does not mean that it's sending any media.  Even if it is, it would be implementer's choice whether to mix or give priority to UAS media or local ringtone.  A well-behaved UAS would only send 180 if it had no media to send until its final response (even during or after negotiating SDP with active UAS), and would send 183 if it had in-band call progress or wants to negotiate media but does not yet want to initiate local ringtone.  Any piggy-backing of SDP would just f!
ollow existing rules.  In more complex call progress scenarios, you could freely switch between these states.  And this allows generation of local ringtone after negotiation of mandatory preconditions, without need for a final UPDATE before 200 (INVITE).  Any changes in the media path during call setup after the initial offer/answer cycle would be independently negotiated with UPDATE.
This approach eliminates coupling between the semantics of 180 and the state of the media, eliminates the need for final UPDATE before 200 (INVITE) in a common manyfolks scenario, is consistent with current text in all RFCs and most drafts (except the one quote and some related text from manyfolks), and easily supports complex call progress scenarios involving UAS endpoints with different in-band call progress media capabilities.
The only other consideration I can think of is that this proposal seems to make it impossible to signal an ISUP alerting indication from a CPG within SIP once in-band call progress has been established (in either direction).  [E.g., it precludes 180 after 183 when you don't want local ringtone but want in-band information instead.  So how do you signal ISUP alerting after in-band call progress is established?]  I propose that for this case (which I think is only needed for ISUP bridging), the ISUP alerting indication be optionally passed in a MIME attachment to a 183 response rather than a 180 response, to make it clear that the UAC should not generate local ringtone.  [This minor change should go in the sip-isup draft.]
Another way of looking at my proposal is that there would be no explicit SIP indication for "the UAS is being alerted; do not generate local ringtone".  A SIP UAC would do nothing if it got such an indication anyway.  If ISUP needs it in a bridging scenario, the ISUP MIME attachment to 183 satisfies that need.
I would greatly appreciate any comments on my proposal.
Regards,
Richard Ejzak
Lucent Technologies

------------------------------------------------------------------------------------------------------
email from Christer Holmberg dated July 3, 2002:

Hi Bert, As a conclusion to this discussion my proposal for a clarification would be that the local ringback generation depends on if a early media session has been established or not when the 180 arrives. And, IF a UAS sends early media, and then wants the UAC to generate local ringback, it first have to put the early media on hold, using UPDATE, then send 180 (the UAC MAY now generate local ringback, since there is no early media), and when the called party answers the UAS will first send a new UPDATE, to un-hold the media, then send 200 for the INVITE. I still think this process is very messy, and "much pain for little gain", but since that's the only way SIP allows us to do it I am not going to argue against it :) I still would like to get a clarification on the "UPDATE-and-buffering-of-200) issue I brought up, though :) Personally I see no reason why to buffer the 200, but the UAS may have to buffer the second UPDATE (used to un-hold the media) until it has completed th!
e first UPDATE (used to put media on hold), which means there is again a chance of media clipping. Now, as Bert mentioned, the UAS may start sending early media without indicating it (sending 183 with SDP), and then still send 180 without SDP even if it sends early media, so in that case I guess there is a risk the local ringback WILL get mixed with the early media (but, we can get early media mixing in forking scenarios, anyway) - UNLESS the UAC is able to do some decissions based on detected media (I don't think that would work very well, but it's up to each implementor to decide for him/herself). Or, does anyone have another proposal? Thanks! Regards, Christer Holmberg Ericsson Finland 

: end of email from Christer Holmberg dated July 3, 2002
------------------------------------------------------------------------------------------------------

_______________________________________________
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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Aug 2002 23:22:17 +0300

Hi Richard,

>I only recently began looking into this issue on the sip and sipping archives, so I apologize for entering the discussion at such a late date.  (That explains the unusual >format of the attached copy of your email on July 3 from the sip archive.)
>
>I am very confused by this discussion.  Why should the meaning of 180 be changed according to the negotiated value of the directionality attribute of the media?  >According to your proposal below, a UAC receiving 180 will not generate local ringing if SDP has been negotiated with UAS media active (not on hold).  And a >UAC receiving 180 MAY generate local ringing if either no SDP has been negotiated or the SDP that has been negotiated has UAS media "on hold".  (Essentially >the same semantics are described in the manyfolks draft.)

[CHH] First, the conclusion you have copied into this mail was sent BEFORE the latest discussion, where a slightly different solution was found. One difference now is that the generating of local ringback is NOT coupled to the media state - 180 now indicates that no early media is sent, so the UAC may generate local ringback no matter the media at the same time. 183 indicates that early media MAY be sent, but the UAC is recommended not to generate local ringback even if early media is sent or not.

> I think this coupling of the meaning of 180 to the state of the media is unwarranted and should be removed from the manyfolks draft.  The text in question is: "Note that now the media stream has be…

[CHH] Well, because of the latest agreement 180 would not trigger local ringback - no matter if the media state is "sendrecv".

However, the latest agreement DOES have some impacts on the manyfolks draft. The draft currently specifies that 180 is sent when the caller has been alerted (when the resource reservation has been done), but if the UAS wants to send early media 183 shall be sent instead of 180 (the sending of the FIRST 183, when the INVITE has been received, remains unchanged).

Jon, could you please comment this manyfolks issue?

> Here is some other relevant text from various documents.  First of all, Jon Peterson (from the sipping archive) has recently added the following clarification of the meaning of 183 to the sip-isup…

[CHH] Again, the first provisional response sent in manyfolks is 183, which means the UAS MAY send early media, and which means the UAC should NOT generate local ringback. Of course, if the resource reservation is not done when the first 183 is sent, no early media will be sent, and no local ringback will be generated - so the caller will NOT be "alerted". Or, did I missunderstand your question?

> Furthermore, there is a timing issue that absolutely requires us to eliminate clipping at answer.  Some of us have been down this road before and there is no possibility of compromise here.  Any pr…

[CHH] The agreement means that is IS possible to set up a "sendrecv" media state using a single offer/answer transaction, even if no early media is sent, which means it's not mandatory to first set the media state to "inactive", and then to "sendrecv" when the called party answers the phone. Of course, if either party (for whatever reason) wants the media state to be "inactive" until the call has been answered it can still be done, but the major change is that it's not mandatory anymore - again, since the media state does NOT affect the decission if, or if not, to generate local ringback.

> Allow me to propose an alternative approach.   Allow 180 and 183 to toggle the generation of local ringing, independent of the state of the media.  If the UAC gets a 180, it MAY initiate local ringtone.  If media is in sendrecv, it becomes an implementer's choice how to deal with this (as discussed in other mails in the archive).  If the UAC gets a 183, it stops any locally-generated ringtone.

[CHH] That's IS what we just have agreed upon a few days ago :)

>  If you get another 180 afterwards, the UAC MAY initiate local ringtone again, etc.  Just because the UAS is not on hold does not mean that it's sending any media.

[CHH] Exactly.

> Even if it is, it would be implementer's choice whether to mix or give priority to UAS media or local ringtone.  A well-behaved UAS would only send 180 if it had no media to send until its final response (even during or after negotiating SDP with active UAS), and would send 183 if it had in-band call progress or wants to negotiate media but does not yet want to initiate local ringtone.

[CHH] Yes.

> Any piggy-backing of SDP would just follow existing rules.  In more complex call progress scenarios, you could freely switch between these states.  And this allows generation of local ringtone after negotiation of mandatory preconditions, without need for a final UPDATE before 200 (INVITE).  Any changes in the media path during call setup after the initial offer/answer cycle would be independently negotiated with UPDATE.

[CHH] The "indicator" you mention was one of the options in the latest discussion on this. I think you should read THAT thread, because - again  - the "conclusion" of mine that you attached to your mail was from a previous discussion :)

Regards,

Christer Holmberg
Ericsson Finland

> Hi Bert, As a conclusion to this discussion my proposal for a clarification would be that the local ringback generation depends on if a early media session has been established or not when the 180 arrives. And, IF a UAS sends early media, and then wants the UAC to generate local ringback, it first have to put the early media on hold, using UPDATE, then send 180 (the UAC MAY now generate local ringback, since there is no early media), and when the called party answers the UAS will first send a new UPDATE, to un-hold the media, then send 200 for the INVITE. I still think this process is very messy, and "much pain for little gain", but since that's the only way SIP allows us to do it I am not going to argue against it :) I still would like to get a clarification on the "UPDATE-and-buffering-of-200) issue I brought up, though :) Personally I see no reason why to buffer the 200, but the UAS may have to buffer the second UPDATE (used to un-hold the media) until it has completed !
th!