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

From: David Oliver <[email-masked]>
Date: Thu, 22 Aug 2002 15:57:18 -0500

Richard,

(More) comments inline...

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: mailto:[email-masked]
Tel:   +1.210.402.9669
Fax:   +1.210.402.6996

> -----Original Message-----
> From: Ejzak, Richard P (Richard) [mailto:[email-masked]]
> Sent: Thursday, August 22, 2002 3:12 PM
> To: 'David Oliver'; 'Christer Holmberg'
> Cc: [email-masked]'; [email-masked]'
> Subject: RE: [Sip] Local vs. Remote ringback on 180
> 
> 
> David,
> You said: "I suggest that 183 SHOULD stop generation of local 
> ringtone only when accompanied by appropriate (e.g. SDP audio)
> early media. 183 Session Progress is a "catch all", which may
> be used to convey more details about call progress: the
> message body could  reasonably be used as a form of reverse
> caller id ("callee id"), such as a message saying "Ringing
> John Smith's phone in the ABC department of XYZ Corporation".
> While this could be useful to a multi-media caller, it would
> be undesirable for it to squelch ringback for a "black phone"
> user."
> 
> May I respectfully suggest that your interpretation will make 
> it difficult to handle a scenario involving redirection from 
> a device not supporting in-band call progress to one that 
> does?  Let's assume a call from user A starts by negotiating 
> preconditions with party B and by generating local ringtone 
> in response to 180 with SDP.  If this call is then redirected 
> to party C, and party C has in-band call progress 
> information, what mechanism do I use to signal this change 
> according to your interpretation?  With your interpretation, 
> I can never switch from generation of local ringtone to 
> in-band call progress information after SDP negotiation begins.  

A would suppress local ringback when C sent a 183 with SDP in its body
indicating early media. I agree this is ugly as the coupling is indirect.

> There is an easy fix for this problem: If there is a need to 
> send a Reason-Phrase to indicate the handling of a call, then 
> use 183 to carry it if you do not want the UAC to generate 
> local ringtone (probably because there is in-band call 
> progress information), and use 180 to carry it if you wish 
> the UAC to continue to generate local ringtone.  This allows 
> you to signal unclassified call progress information back to 
> the UAC in all cases.  Every 180 in sequence after the first 
> can be interpreted as just a generic session progress response.  

This works: 180 now means "Callee is (still) being alerted; UAC MAY
(continue to) play local ringtone" - merely clarifying the semantics.

> You go on to say: "This is the area where I think the
> problem is. 3261 indicates that 180 indicates the caller
> is being alerted. 183 indicates unclassified (versus
> Ringing, Being Forwarded, and Queued) call progress,
> allowing new classifications to be added (e.g. "waiting
> for connection availability"), which would be broken by
> restricting 183 to the specific meaning of
> Ringing-Without-Local-Ringback (RWLR)."
> 
> I further stated (and the current early media agreement for 
> the sip-isup draft apparently says) that a UAS should use 183 
> to signal alerting while progress information is coming 
> in-band.  You correctly point out that this makes it 
> impossible for the UAS to report unclassified call progress 
> information while there is in-band call progress information, 
> without providing an alerting indication.
> 
> "3261/21.1.5 indicates that 183 can be qualified by the 
> Reason-Phrase (which may be language sensitive), header 
> fields (which are IANA managed) or the message body. I 
> suggest the easiest of these to adopt for RWLR would be:
> 
> 	183 180 Ringing with early media
> 
> where only the 180 is significant, the text being adaptable 
> to the requested language."
> 
> I actually like this solution very much.  A SIP entity 
> receiving an alerting indication while being prohibited from 
> generating local ringtone will behave exactly like a SIP 
> entity receiving a 183 - it will do some vendor-specific 
> thing (perhaps nothing) with the contents of the 
> Reason-Phrase.  So if you use 183 to send this Reason-Phrase, 
> there is no loss in functionality for a SIP UAC/UAS.  For an 
> MGC providing interworking with the PSTN, it adds an 
> additional processing burden local to the MGC: interwork a 
> PSTN alerting indication while there is in-band progress 
> information with a 183 response carrying a Reason-Phrase 
> beginning with "180".  I like it!  I think this is much 
> better than the "solution 1".

I must concur :-) In other words, the alerting/local ringback combinations
are:

180      (still) alerting;
         MAY (continue to) play local ringback

183 180  (still) alerting;
         SHOULD NOT (continue to) play local ringback

183      alerting unchanged; 
         local ringback unchanged

> The first change should probably be reflected in both 
> manyfolks and sip-isup.  Your proposed change only needs to 
> be in the sip-isup draft.  The ISUP event code to SIP 
> response map in the sip-isup draft would allow either 180 or 
> 183 to be used with event codes 1, 2, 3 or -.
> 
> Regards,
> Richard Ejzak
_______________________________________________
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: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 22 Aug 2002 16:56:04 -0500

David,
I would suggest the following combinations:

180      provide alerting indication when interworking;
         MAY (continue to) play local ringback

183 180  provide alerting indication when interworking;
         SHOULD NOT (continue to) play local ringback

183      provide progress indication when interworking; 
         SHOULD NOT (continue to) play local ringback

All of these combinations may include a Reason-Phrase for display of additional information for SIP UAs that can process them.

I don't think the "(still) alerting" indication is very meaningful.  The only thing a SIP UA cares about is whether or not to generate local ringtone - either message can otherwise carry a message for display.  So the first line just describes what to do at a MGC when interworking the signaling; the second line describes what to do at the media level.

The only significant change from your list is the last combination.  I suggest the use of 180 for miscellaneous progress information while playing local ringtone.  Your combinations can be made to work, but make it impossible to turn off local ringtone without sending an alerting indication.  

Regards,
Richard Ejzak

-----Original Message-----
From: David Oliver [mailto:[email-masked]]
Sent: Thursday, August 22, 2002 3:57 PM
To: 'Ejzak, Richard P (Richard)'; David Oliver; 'Christer Holmberg'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Sip] Local vs. Remote ringback on 180

Richard,

David C. Oliver
Principal Engineer
SecureLogix Corp

180      (still) alerting;

183      alerting unchanged; 
         local ringback unchanged

---

From: David Oliver <[email-masked]>
Date: Thu, 22 Aug 2002 17:07:56 -0500

Richard,

They work for me.

Regards,
 
David O.

> Sent: Thursday, August 22, 2002 4:56 PM
> All of these combinations may include a Reason-Phrase for 
> display of additional information for SIP UAs that can process them.
> 
> I don't think the "(still) alerting" indication is very 
> meaningful.  The only thing a SIP UA cares about is whether 
> or not to generate local ringtone - either message can 
> otherwise carry a message for display.  So the first line 
> just describes what to do at a MGC when interworking the 
> signaling; the second line describes what to do at the media level.
> 
> The only significant change from your list is the last 
> combination.  I suggest the use of 180 for miscellaneous 
> progress information while playing local ringtone.  Your 
> combinations can be made to work, but make it impossible to 
> turn off local ringtone without sending an alerting indication.  
> 
> Regards,
> Richard Ejzak
<...>