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

From: "Bose, Anjan" <[email-masked]>
Date: Fri, 9 Aug 2002 12:12:50 -0400

Mike,
	I think that it would be better to:
(1)  Have an entirely different message indicate local as opposed to remote
ringback (180 Ringing for local ringback and 183 Session Progress for remote
ringback)
(2)  Not being able to reach an agreement on (1), using the Alert-info
header as Bill suggests to explicitly indicate whether the ISUP/SIP Media
Gateway desires that local or remote ringback be applied.

						Anjan

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Friday, August 09, 2002 8:14 AM
To: William Marshall
Cc: [email-masked]
Subject: RE: [Sipping] new draft-ietf-sipping-isup-05

Bill,

In general, I agree that the indication of alerting and how the alerting is 
to be provided needs to be explicitly signaled for both the encapsulated 
ISUP case and the no-ISUP case.  That is, it requires an explicit element 
in both the SIP headers as it would be in the encapsulated ISUP.  Becasue 
the SDP may be part of the independent Offer/Answer and not related to 
providing tones and announcements, a call signaling element indicating 
local generation versus inband would avoid making likely false assumptions.

Related to this, section 8.2.3 "18x received":

"Upon receipt of a 18x response without any SDP, the gateway SHOULD 
generates [sic] the ringback tone to be heard by the caller on the PSTN 
side (unless the gateway knows that ringback will be provided by some other 
device on the PSTN side)."

It is possible that an ACM or CPG with "no indication" triggered this 18x.

Mike

At 09:22 AM 8/9/2002 -0400, William Marshall wrote:
>The latest version of this draft has gone a long way toward
>consistency with the offer/answer model of rfc3261, thereby
>allowing integration with the additional procedures for preconditions,
>and resolving the in-band vs. local ringback issue.  However, I
>don't think it is there yet.
>
>With in-band ringback there is a race condition with the 180-Ringing
>provisional response; the UAC may receive the 180 response and
>start a local ringback, then start receiving media and preempt it
>with the in-band ringback.
>
>This is not an acceptible user experience.
>
>The UAS in this case knows that it will be generating a media
>stream as soon as it sends the 180, so it could clearly indicate
>this in the signaling message.  I believe use of 183 instead of 180
>was discussed in Yokohama, but isup-05 stayed with 180.
>
>I'd like to propose a convention on use of the Alert-Info header
>in a 180-Ringing response, where one particular value of the header
>parameter indicates to the UAC that in-band media will be coming
>and that it should not start a local ringback.  This approach seems
>completely backwards compatible with all existing systems, and
>those that understand the convention can do the proper thing.
>Other solutions solicited.
>
>Bill Marshall
>[email-masked]
>
>_______________________________________________
>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

_______________________________________________
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: Michael Hammer <[email-masked]>
Date: Fri, 09 Aug 2002 12:37:26 -0400

The problem I have with 183 is that sometimes it means ring-back, sometimes 
it should not.  How do you handle a CPG with event=no indication?

Thus I like an explicit header or parameter.

That does not disagree with (1) below, which could also be used.  But, 
right now as I understand it a CPG with event=alerting causes a 180 to be 
sent for both local and remote.

Mike