Subject: RE: [Sipping] Summary of: Meaning of status codes

From: "Francois Audet" <[email-masked]>
Date: Mon, 9 Dec 2002 11:15:22 -0800

I don't think that there is necessarily a problem with having two camps here
on the issue
of 180 versus 183 with SDP, when the gateways knows that in-band ringing is
being provided 
and that the user is alerting.

- If a manufacturer (or operator) wants to preserve the logical integrity of
the call
  setup, he may use the 180 to explicitely state that the far-end user is
being alerted.
  It may be important for the calling party's application to know that the
far-end is being
  alerted in order to provide the suitable indication: it could even affect
the application
  itself (presenting new options to the user for example). I suspect that
this is the most 
  common scenario, and is also the scenario that is more "sippish". It is
what we should 
  shoot for. Including an SDP for early media (for clipping avoidance or for
in-band 
  tones or announcement) can also be done. However, the manufacturer or
operator must 
  realize that by doing so, it is possible that certain implemenations may
give priority
  to the logical indication as opposed to the in-band media (and perhaps
provide locally-
  generated ringback). These implemenations may not be optimal, but they are
certainly possible.
  In the vast majority of cases, it will not matter because rinback is
ringback, be it
  in-band or locally generated, it is the same for the end-user. 

- If a manufacturer (or operator) wants to be absolutely sure that in-band
announcements or
  rinback is received by the calling party, he can use a 183. But that means
that he is
  willing to loose the logical alerting indication. This may be perfectly
acceptable in
  certain situation. It may not be so acceptable in other scenarios (for
example when it 
  is important the the application on the calling user side receives the
alerting indication
  in order to have a different treatment). But using a 183 with SDP can
certainly be a 
  good alternative when the announcement is important enough that it has to
be provided to
  the calling party.

I believe that those 2 mechanisms offer sufficient flexibility to implement
a wide variety of
services. I would propose that we document those 2 cases in the early-media
draft. Of course
we would also have the part about SDP in 180 (avoid clipping, real in-band
media should override 
any locally-generated media, etc.).

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: Sunday, December 08, 2002 8:09 AM
> To: Peterson, Jon
> Cc: 'Rohan Mahy'; Audet, Francois [SC100:4K02:EXCH]; 'William 
> Marshall'; [email-masked]'; 
> [email-masked]'; [email-masked]'; 
> 'Alan Johnston'; 'sipping'; 'Adam Roach'
> Subject: [Sipping] Summary of: Meaning of status codes
> 
> 
> Folks,
> 
> I will try to summarize all the discussions so far in this thread. 
> 
> Adam, Fracois Audet, Rohan, Jon and Gonzalo stated that if 
> the callee is being alerted, 180 is the right status code to use.
> 
> Alan, John Hearty and Michael Hammer said that current 
> gateways send a 183 (even if the user is being alerted) when 
> there is early media. Therefore, in order to be backward 
> compatible, they would like to avoid using 180 with SDP.
> 
> Jon said that vanilla SIP UAs should not send early media 
> with the same offer/answer context of the original INVITE. He 
> gave some alternatives to the 18x with SDP approach. 18x with 
> SDP would be used only by gateways.
> 
>  
> As I see this, we have two issues:
> 
> 1) how big is the backwards compatibility problem that Alan 
> brought up.
> 
> 2) 18x with SDP for early media: is it conceptually correct 
> for vanilla UAs? are there technical issues?
> 
> I will send a separate note about 2).
> 
> About 1), I am not sure whether or not we face a backwards 
> compatibility problem. The issue is that an ingress gateway 
> (UAC) will generate local ringback upon reception of a 180 
> (even if it has SDP).
> 
> Let's suppose that we do not have early media in a particular 
> call. A current gateway that uses the strategy described 
> above, will have to be prepared to stop local ringback when 
> the first media packets (the "hello" from the callee) arrive, 
> because it cannot rely on receiveing the 200 OK first (there 
> is a race condition).
> 
> Therefore, current gateways are already prepared to stop 
> local ringback if inband alerting is received (the gateway 
> will not know if what is being received is the "Hello" or 
> "beep, beep...")
> 
> I do not see any issue here that keep us from sending a 180 
> and inband ringing at the same time. Alan, can you elaborate 
> on what you believe is the problem?
> 
> 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: "Francois Audet" <[email-masked]>
Date: Tue, 10 Dec 2002 14:44:32 -0800

> Mike,
> 
> While some folks might send an initial sacrifice packet to help with 
> middlebox traversal, nobody I've seen sends dead air or 
> comfort noise.  
> It actually doesn't help avoid clipping, and it takes work.

There might be dead air if the called party is a PSTN gateway. The gateway
may be relying on
far-end ringback (or an out-of-band indication). But the seizing of the
trunk will happen 
locally, resulting on the media session to be set. Unless there is silence
suppression involved,
you are very likely to have in-band silence sent.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 11 Dec 2002 11:13:51 -0500

Francois,

Yes.  That is why silence suppression should be required and will kick in 
with sending of periodic "I'm suppressing because of silence" RTP 
packets.  Further, a requirement that such packets won't trigger stopping 
of alerting started with 180 would be needed.

Mike

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Wed, 11 Dec 2002 08:29:16 -0800

Exactly. We are in agreement.

> From: Michael Hammer [mailto:[email-masked]] 
> Sent: Wednesday, December 11, 2002 8:14 AM
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Rohan Mahy'; 'Gonzalo Camarillo'; 'sipping'
> Subject: RE: [Sipping] Summary of: Meaning of status codes
> 
> 
> Francois,
> 
> > > middlebox traversal, nobody I've seen sends dead air or comfort 
> > > noise. It actually doesn't help avoid clipping, and it takes work.
> >

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 11 Dec 2002 11:12:07 -0800

Agreed. We just need to document the tradeoffs in the draft so people
understand what the consequences are.

> Hi Mike,
> 
> I believe we are in agreement. If you have received a 180 
> Ringing, your GUI should be in the alerting state, regardless 
> of the media status.
> 
> Then, if somebody uses ringback tones instead of visual 
> alerting and wants to mix local alerting with the early media 
> received or wants to give priority to one of them, is up to 
> the local policy of that device.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 11 Dec 2002 14:24:46 -0500

Agree.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 13 Dec 2002 11:09:43 -0800

I am in 100% agreement with Michael's comments.

If one really wants to override locally-generated alerting with in-band
tones, it
is not sufficient just to look at the presence of RTP packet. It needs to be
resonably sure that the packets have useful media (i.e., not silence). How
to implement (and if) is a design decision (detect energy level in packets,
etc.).

> Sent: Tuesday, December 10, 2002 11:03 AM
> To: Gonzalo Camarillo
> Cc: Peterson, Jon; 'Rohan Mahy'; Audet, Francois 
> [SC100:4K02:EXCH]; 'William Marshall'; [email-masked]'; 
> [email-masked]'; 'Alan Johnston'; 
> 'sipping'; 'Adam Roach'
> Subject: Re: [Sipping] Summary of: Meaning of status codes
> 
> 
> Gonzalo,
> 
> My main issue was the possibility that a 180 with SDP could 
> be received, 
> where the receipt of RTP packets contained dead air or 
> comfort noise rather 
> than tones or announcements for the purpose of avoiding clipping.
> 
> I don't have a problem with the idea that receipt of SDP 
> means be ready to 
> play media upon Answer.
> 
> I do have an issue with the assumption that receipt of RTP means that 
> meaningful media is present.
> 
> When 180 is received, it means alerting and so long as the 
> user is alerted 
> by visual or audio means (I don't care which, that is 
> implementation) I am 
> fine.
> 
> I am inclined to think that such alerting should continue 
> until Answer.  I 
> do not think it wise to base that on RTP receipt.  See faulty 
> assumption above.
> 
> If a SIP phone continued visual alerting and played RTP media when 
> received, that would be fine too.
> 
> I have a problem with the idea that receipt of SDP or RTP 
> abdicates the 
> signaling responsibility to signal the user thereby 
> re-entangling signaling 
> and media.
> 
> I don't think there is an issue with sending 18x with SDP in 
> those cases 
> where the gateway has no idea what 
> ring-back/tones/announcements are in the 
> media stream.
> 
> Mike
> 
> 
> At 06:08 PM 12/8/2002 +0200, Gonzalo Camarillo wrote:
> >Folks,
> >
> the callee 
> >is being alerted, 180 is the right status code to use.
> >
> gateways send a 
> >183 (even if the user is being alerted) when there is early media. 
> >Therefore, in order to be backward compatible, they would 
> like to avoid 
> >using 180 with SDP.
> >
> with the same 
> >offer/answer context of the original INVITE. He gave some 
> alternatives 
> >to the 18x with SDP approach. 18x with SDP would be used only by 
> >gateways.
> >
> >
> (UAC) will 
> >generate local ringback upon reception of a 180 (even if it has SDP).
> >
> >Let's suppose that we do not have early media in a 
> particular call. A 
> >current gateway that uses the strategy described above, will 
> have to be 
> >prepared to stop local ringback when the first media packets (the 
> >"hello" from the callee) arrive, because it cannot rely on 
> receiveing 
> >the 200 OK first (there is a race condition).
> >
> local ringback 
> >if inband alerting is received (the gateway will not know if what is 
> >being received is the "Hello" or "beep, beep...")
> >
> and inband 
> >ringing at the same time. Alan, can you elaborate on what 
> you believe 
> >is the problem?
> >
> >Thanks,
> >
> >Gonzalo
> >Use [email-masked] for questions on 
> current sip Use 
> >[email-masked] for new developments of core SIP
>