Subject: Re: [Sipping] New version of the early media draft

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 04 Mar 2003 13:20:32 +0200

Francois,

Thanks for the feedback.

About your suggestion, the paragraph you are referring to does not
recommend any particular behaviour. It only says that one possible
choice is mixing them. I do not think that we need to list all possible
things a gateway could do in that case. I believe that the reader gets
the idea by reading the paragraph as it is (i.e., there are multiple
behaviours to choose from).

Thanks,

Gonzalo

Francois Audet wrote:
> 
> Gonzallo,
> 
> I finally had a chance to read the new version of early media draft.
> Kind of interesting
> that this version didn't get much feedback at all.
> 
> It is a very good document. I think you have captured very well the
> very many issues that
> were discussed last year. I am very comfortable with this new version.
> 
> I have only one suggestion (and a minor one). In section 2.2 on page
> 7, in the paragraph that
> starts with "Note" just below point 3, I would change the lst sentence
> to the following:
> 
>    This type of gateway could choose to generate local ringback upon
> reception
>    of a 180 (Ringing) response, and override or mix it with any
> incoming media that
>    happens to arrive (if it does at all).
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:[email-masked]]
> > Sent: Monday, February 10, 2003 3:41 AM
> > To: sipping
> > Subject: [Sipping] New version of the early media draft
> >
> >
> > Folks,
> >
> > I have just sumitted a new version of the early media draft.
> > Until it appears in the archives, you can fetch it from:
> >
> http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-media-01.txt
> 
> I have included all the (long and useful) discussions we had in the
> mailing list. Therefore, the draft now keeps separate the "gateway"
> and the "application server" models. I have also removed the parts we
> did not agree on.
> 
> Feedback is, as usual, appreciated.
> 
> 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
_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 04 Mar 2003 13:42:18 +0200

Ejzak,

the main problem with any SIP-layer mechanism that allows the UAS to
tell the UAC whether local ringback has to be generated or not is race
conditions. It really does not matter whether you use an Alert-Info
header field in a reponse, or a special status code, or a special body,
or whatever to signal it. You always have race conditions.

Let's say that the UAS tells the UAC to generate local ringback. After a
while, the callee picks up. The UAS sends back a 200 OK and starts
sending media. The 200 OK, for some reason, arrives much later than the
first media packets... what is the UAC supposed to do in the mean time?
Ignore the media? Play the media anyway?

Another scenario. The UAC starts receiving media before a provisional
response is received... what does it have to do?

The main point is that, since signalling and media are loosely
synchronized, you will always have race conditions and you will have to
make guesses about what to do during those race conditions anyway.

Thanks,

Gonzalo

"Ejzak, Richard P (Richard)" wrote:
> 
> Gonzalo,
> It seems the single greatest difficulty with the gateway model (as you point out in your draft) is the difficulty of depending on the arrival of media packets to determine whether or not to generate local ringing.  I have previously (last summer) suggested a solution to this (use 180 exclusively to indicate that local ringing should override any inband media and 183 otherwise) that is unacceptable since it does not satisfy the requirement that 180 be used to indicate alerting of the called party.
> 
> Have you considered using the Alert-Info header in the following way? Since the real problem is that we would like to be able to discriminate between cases when 180 should cause local ringing and when 180 should not (since inband media is available), and it is the UAS that knows conclusively which case applies, let's agree on an encoding of the Alert-Info header that indicates that local ringing should not be applied.  The following line is a syntactically valid header:
> 
> Alert-Info: <data:,>
> 
> This header identifies the Alert-Info as the null string, which seems unambiguously and efficiently interpretable within a 180 response as "do not play local ringing even though the called party is being alerted."  If the UAC does not recognize it or chooses not to interpret it for security reasons, it can be safely ignored.
> 
> This modest addition to your draft (or an equivalent mechanism) would make it unnecessary for the gateway model to depend on local policy or incoming media packet detection and is completely consistent with all of the constraints you have documented.
> 
> Another approach may be to actually specify the rtp stream as the source of the alert info (although this would require the definition of a new URI scheme type).  It might look like:
> 
> Alert-Info: <rtp:/12.34.56.78:90>
> 
> where the Alert-Info specifies the address and port of the rtp stream.  I don't like this mechanism since it is redundant with SDP and prone to error.  It is also ambiguous in the event of any subsequent media change using UPDATE (Do I begin to generate local ringing if the rtp stream source address changes?  Or do I continue to listen to the address specified in the Alert-Info and ignore any UPDATEs?  No to both.)
> 
> May I suggest including such a mechanism (preferably the first one) in your draft.
> 
> Richard Ejzak
> Lucent Technologies
> 
> Sent: Monday, February 10, 2003 5:41 AM
> To: sipping
> I have just sumitted a new version of the early media draft. Until it
> appears in the archives, you can fetch it from:
> 
> mailing list. Therefore, the draft now keeps separate the "gateway" and
> the "application server" models. I have also removed the parts we did
> not agree on.
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~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: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 4 Mar 2003 13:15:13 -0600

Gonzalo,
Thanks for your response.  I understand and agree with your concerns about race conditions as well as the discussion of how to handle them.  But I do not want the UAS to blindly control when the UAC should apply local ringing.  I want the UAS to be able to indicate when the UAC should NOT apply local ringing.  There is a very important distinction here.  According to your draft, when a UAC receives a 180 it should be prepared to generate local ringing, and it is a matter of local policy what the UAC should do when there is concurrent in-band media.  Gateway resources should be allocated to detect in-band media and decide whether or not to generate ringing.  But under some circumstances the UAS knows that call progress information is available in-band and the UAC does not need to bother to allocate extra resources to monitor the media flow and optionally inject ringing.  I believe it is important for a UAS to be able to indicate this situation to a UAC.  These are processing !
resources that could be put to use elsewhere.  There are no race conditions in this situation - only the recognition that local ringing and packet detection are unnecessary.

I stand by my original suggestion and continue to request a modest addition to your draft based on this general approach (my previous email indicates one possible detailed solution).  Please let me know if you see any further issues.

Regards,
Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Tuesday, March 04, 2003 5:42 AM
To: Ejzak, Richard P (Richard)
Cc: sipping
Subject: Re: [Sipping] New version of the early media draft

Ejzak,

Thanks,

Gonzalo

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 5 Mar 2003 12:07:16 -0800

Would this alert info say:
1 - Do not play local ringback, or
2 - In-band alerting indication present?

My take is that 2 makes more sense since (1) is only applicable to
telephony applications.

> Sent: Wednesday, March 05, 2003 10:22 AM
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: 'Ejzak, Richard P (Richard)'; sipping
> Mark,
> many of your points have been discussed either in the draft 
> or in the mailing list before. The MGC-MG decomposition 
> problem is discussed in the draft, and the indication of the 
> presence in-band media was discussed in the previous version 
> of the draft.
> 
> My initial proposal was to include an SDP parameter that 
> provided information about the intention of the sender. That 
> is, the sender intended to send early media... that was seen 
> as too complex (and I agree with that, by the way).
> 
> But using some type of *simpler* mechanism that only 
> indicates that the UAS does not want the UAC to generate 
> local ringback (like the mechanism proposed in this thread), 
> would be sensible, IMO. 
> 
> How do people feel about using the header field below in a 
> 18x response to indicate that the UAS would like the UAC not 
> to provide local ringback (as proposed previously in this thread)?
> 
> Alert-Info: <data:,>
> 
> To me, once we have defined Alert-Info, this is not an 
> unreasonable thing to do with this header. Opinions?
> 
> Gonzalo
> 
> 
> Mark Watson wrote:
> > 
> > Gonzalo,
> > 
> > I would support this addition (or something like it - I 
> confess to not 
> > having followed all the details of this thread).
> > 
> > This same problem has come up again and again over the last 
> two years. 
> > The root issue is a distinction between explicit application layer 
> > indications and implicit media layer indications. If the UAC is a 
> > distributed system (e.g. Media Gateway and Media Gateway 
> Controller), 
> > then the general model is that the MG is controlled by the MGC. The 
> > MGC has only explicit app. layer indications to work from - 
> it cannot 
> > take actions on the basis of receipt of not of media 
> packets because 
> > it does not see them.
> > 
> > Sure, the MG can report and 'RTP received' event and the 
> MGC can then 
> > instruct it appropriately, but this takes time & I don't think it's 
> > standardised.
> > 
> > So, there should be enough information *in the SIP 
> signalling* for the 
> > UAC to take an intelligent decision on whether to play 
> media or local 
> > ringing. I don't want to prescribe how it takes this 
> decision, but at 
> > present there is information available to the UAS at the SIP layer 
> > which is not communicated to the UAC (at the SIP layer) - 
> namely the 
> > availability of in-band media. This can only result in the 
> UAC taking 
> > inappropriate decisions in some scenarios.
> > 
> > Perhaps we should not be telling the UAC to 'play local ringing' or 
> > 'don't play local ringing', but if the UAS knows there is in-band 
> > information, it should tell the UAC in SIP.
> > 
> > Regards...Mark
> > 
> > > From: Ejzak, Richard P (Richard) [mailto:[email-masked]]
> > > Sent: 04 March 2003 19:15
> > > To: 'Gonzalo Camarillo'
> > > Cc: sipping
> > > Subject: RE: [Sipping] New version of the early media draft
> > >
> > >
> > > Gonzalo,
> > > Thanks for your response.  I understand and agree with 
> your concerns 
> > > about race conditions as well as the discussion of how to handle 
> > > them.  But I do not want the UAS to blindly control when the UAC 
> > > should apply local ringing.  I want the UAS to be able to 
> indicate 
> > > when the UAC should NOT apply local ringing.  There is a very 
> > > important distinction here. According to your draft, when a UAC 
> > > receives a 180 it should be prepared to generate local 
> ringing, and 
> > > it is a matter of local policy what the UAC should do 
> when there is 
> > > concurrent in-band media.  Gateway resources should be 
> allocated to
> > > detect in-band media and decide whether or not to generate
> > > ringing.  But under some circumstances the UAS knows that
> > > call progress information is available in-band and the UAC
> > > does not need to bother to allocate extra resources to
> > > monitor the media flow and optionally inject ringing.  I
> > > believe it is important for a UAS to be able to indicate this
> > > situation to a UAC.  These are processing !
> > > resources that could be put to use elsewhere.  There are no
> > > race conditions in this situation - only the recognition that
> > > local ringing and packet detection are unnecessary.
> > >
> > > I stand by my original suggestion and continue to request 
> a modest 
> > > addition to your draft based on this general approach (my 
> previous 
> > > email indicates one possible detailed solution).  Please 
> let me know 
> > > if you see any further issues.
> > >
> > > Regards,
> > > Richard Ejzak
> > > Lucent Technologies
> > >
> > >
> > >
> > > header field in a reponse, or a special status code, or a special 
> > > body, or whatever to signal it. You always have race conditions.
> > >
> > > Let's say that the UAS tells the UAC to generate local ringback. 
> > > After a while, the callee picks up. The UAS sends back a 
> 200 OK and 
> > > starts sending media. The 200 OK, for some reason, arrives much
> > > later than the
> > > synchronized, you will always have race conditions and 
> you will have 
> > > to make guesses about what to do during those race conditions 
> > > anyway.
> > >
> > > Thanks,
> > >
> > > Gonzalo
> > >
> > >
> > >
> > > > It seems the single greatest difficulty with the gateway
> > > model (as you point out in your draft) is the difficulty of 
> > > depending on the arrival of media packets to determine whether or 
> > > not to generate local ringing.  I have previously (last summer) 
> > > suggested a solution to this (use 180 exclusively to 
> indicate that 
> > > local ringing should override any inband media and 183 otherwise) 
> > > that is unacceptable since it does not satisfy the 
> requirement that 
> > > 180 be used to indicate alerting of the called party.
> > > >
> > > > Have you considered using the Alert-Info header in the
> > > following way? Since the real problem is that we would like to be 
> > > able to discriminate between cases when 180 should cause local 
> > > ringing and when 180 should not (since inband media is 
> available), 
> > > and it is the UAS that knows conclusively which case 
> applies, let's 
> > > agree on an encoding of the Alert-Info header that indicates that 
> > > local ringing should not be applied.  The following line is a 
> > > syntactically valid header:
> > > >
> > > > Alert-Info: <data:,>
> > > >
> > > > This header identifies the Alert-Info as the null string,
> > > which seems unambiguously and efficiently interpretable 
> within a 180 
> > > response as "do not play local ringing even though the 
> called party 
> > > is being alerted."  If the UAC does not recognize it or 
> chooses not 
> > > to interpret it for security reasons, it can be safely ignored.
> > > >
> > > > This modest addition to your draft (or an equivalent
> > > mechanism) would make it unnecessary for the gateway 
> model to depend 
> > > on local policy or incoming media packet detection and is 
> completely 
> > > consistent with all of the constraints you have documented.
> > > >
> > > > Another approach may be to actually specify the rtp stream
> > > as the source of the alert info (although this would require the 
> > > definition of a new URI scheme type).  It might look like:
> > > >
> > > > where the Alert-Info specifies the address and port of the
> > > rtp stream.  I don't like this mechanism since it is 
> redundant with 
> > > SDP and prone to error.  It is also ambiguous in the event of any 
> > > subsequent media change using UPDATE (Do I begin to 
> generate local 
> > > ringing if the rtp stream source address changes?  Or do 
> I continue 
> > > to listen to the address specified in the Alert-Info and 
> ignore any 
> > > UPDATEs?  No to both.)
> > > >
> > > > From: Gonzalo Camarillo 
> [mailto:[email-masked]]
> > 
> > and
> > > 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 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 5 Mar 2003 16:38:17 -0600

Francois,
I am comfortable with either meaning, and understand the preference expressed for (2).  I have a strong preference for using the Alert-Info header to provide this indication, however, since it exists.  It took me quite a while to come up with a syntactically valid absoluteURI (using the data scheme type) that could be immediately parsed to mean "null."  (Note that the Alert-Info header requires an absoluteURI.)  I think it would be a real abuse of this mechanism to include any text in the URI other than the null string (i.e. Alert-Info: <data:,>) to make it more "meaningful" (e.g. Alert-Info: <data:,In-band Alerting>).  Perhaps others don't share my concern here.
 
Do you think a null Alert-Info is sufficient to indicate in-band alerting?  (To me (1) is a more natural interpretation of null Alert-Info, but I don't have a problem with (2).)  Or do you have another suggestion?
 
Regards,
Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 2:07 PM
To: 'Gonzalo Camarillo'; Mark Watson
Cc: 'Ejzak, Richard P (Richard)'; 'sipping'
Subject: RE: [Sipping] New version of the early media draft

> From: Gonzalo Camarillo [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > From: Ejzak, Richard P (Richard) [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > From: Gonzalo Camarillo [ mailto:[email-masked] <mailto:[email-masked]> ] 
> [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > 
> http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-e <http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-e>  
> > arly-media-01.txt 
> > 
> > > 
> https://www1.ietf.org/mailman/listinfo/sipping <https://www1.ietf.org/mailman/listinfo/sipping>  
> > 
> > > This 
> > Finland                   http://www.hut.fi/~gonzalo <http://www.hut.fi/~gonzalo>  
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping <https://www1.ietf.org/mailman/listinfo/sipping>  
> Finland                   http://www.hut.fi/~gonzalo <http://www.hut.fi/~gonzalo>  
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping <https://www1.ietf.org/mailman/listinfo/sipping>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 5 Mar 2003 16:49:49 -0800

I agree with Jon's proposal of stating explicitly that 183 implies 
that local ringback should not be used. 

The null Alert-Info seems a little cludgy (and redundant) to me.

The way I am reading RFC3261, I see that Alert-Info can NOT be used
in 183 (only in INVITE or 180). This makes sense to me. Is this
true?

If this is correct, then the procedures seems consistent to me:
1  - 183 Progress. Implies NO locally generated alerting (i.e., it
     is NOT 180, and can not have Alert-Info). In-band media can be
     present.
2a - 180 with Alert-Info. You can play the Alert-Info (can potentially
     be overridden by in-band media based on local policy)
2b - 180 without Alert-Info. You can provide locally generated default
     treatment (can potentially be overridden by in-band media, based
     on local policy). The fact that no Alert-Info is present simply
     means that default treatment can be provided.

I really hope we can settle this thing once and for all...

> From: Peterson, Jon [mailto:[email-masked]] 
> Sent: Wednesday, March 05, 2003 3:40 PM
> To: 'Gonzalo Camarillo'; Watson, Mark [MOP:EP10:EXCH]
> I don't think that the Alert-Info header proposal will really 
> assuage the stated problem. Mr. Marshall raised a 'null' 
> Alert-Info proposal in the previous discussion, and it was 
> rejected then, as it should be now. Here's the thread:
> 
> http://www1.ietf.org/mail-archive/working-groups/sipping/curre
> nt/msg02545.ht
> ml
> 
> Null Alert-Info wouldn't express anything more than just 
> sending a 183 does
> - a UAS should send a 183 when it knows it has some 
> non-ringing in-band media. Null Alert-Info certainly wouldn't 
> give you any additional leverage in cases where media arrives 
> before signaling. I'm not sure what new properties it would 
> grant. The text already suggests a policy of:
> 
>         1.   Unless a 180 (Ringing) response is received, 
> never generate
>              local ringback.
> 
> ... which essentially entails 'don't play local ringback if 
> 183 is received'. I'm not sure how it would be any better to 
> recommend a similar (and redundant) policy relating to Alert-Info.
> 
> As an aside, I do agree with Mr. Audet that we should 
> discourage mixing local ringback tones with received media.
> 
> Jon Peterson
> NeuStar, Inc.

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 5 Mar 2003 21:43:40 -0500

Just to be clear, I wasn't arguing for any changes to the existing text. I
was just saying that the current text describes (but does mandate) a local
policy which entails that 183 would not result in local ringback. I think
the existing text can stand.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Wednesday, March 05, 2003 4:50 PM
To: 'Peterson, Jon'; 'Gonzalo Camarillo'; Mark Watson
Cc: 'Ejzak, Richard P (Richard)'; 'sipping'
Subject: RE: [Sipping] New version of the early media draft

> From: Peterson, Jon [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> http://www1.ietf.org/mail-archive/working-groups/sipping/curre
<http://www1.ietf.org/mail-archive/working-groups/sipping/curre>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Mar 2003 17:06:19 -0500

Well,

> From: Gonzalo Camarillo [mailto:[email-masked]]
[snip]
> 
> The scenario he is after is as follows; a gateway *knows* that the user
> is being alerted and also *knows* that it will be sending in-band
> ringing.
> 

If the gateway knows that it will be sending in-band ringing, my position is
that the gateway shouldn't be sending that media. It's just ring tone. The
UAC can generate that itself. Let's not waste the bandwidth sending ringing,
especially in forking cases, especially because the UAC might not even
render this provisional media (if it's a PC UAC, for example).

If media arrives at the UAC, it should override local ringtone, agreed. And
I have no problem with the idea that a UAC would delay local ringtone for a
short interval in order to see if any media is coming, even when 180 is
received. But we should not encourage gateways to send ringing media.

Jon Peterson
NeuStar, Inc.

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 6 Mar 2003 16:39:33 -0600

Jon,
I must disagree with your blanket recommendation that the gateway not sent in-band ringing media.  This may be possible in some cases - and nothing we have suggested would prevent a gateway from using out-of-band indications.  But ringing is not the only in-band call progress information you may receive while trying to establish a call from SIP to ISUP.  The transition from alerting to other forms of in-band call progress information is not guaranteed to be clearly signaled by ISUP within an ACM or CPG (since every switch in the network can safely assume in-band call progress after a certain point in the call), and it is essential that this subsequent information (when it exists) be presented to the UAC/user.  And the notion of having the gateway intelligently filter what it thinks is ringing and detect a transition to other forms of call progress is not acceptable.

Regards,
Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 4:06 PM
To: 'Gonzalo Camarillo'
Cc: Mark Watson; 'Ejzak, Richard P (Richard)'; sipping
Subject: RE: [Sipping] New version of the early media draft

Well,

[snip]

Jon Peterson
NeuStar, Inc.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 6 Mar 2003 09:04:52 -0800

I agree with your analysis. 

Of course an alternative is for locally generated tones to override the
in-band
ringing. In the case of forking, I don't think we have much choice anyways.
But again,
this is a local policy.

> Sent: Thursday, March 06, 2003 5:46 AM
> To: Peterson, Jon
> Cc: Watson, Mark [MOP:EP10:EXCH]; 'Ejzak, Richard P 
> (Richard)'; sipping
> Hi,
> well, I can see which scenario he is after, but I agree that 
> the solution would not bring much value.
> 
> The scenario he is after is as follows; a gateway *knows* 
> that the user is being alerted and also *knows* that it will 
> be sending in-band ringing.
> 
> He is proposing a flag (i.e., null Altert-Info) for resolving 
> that situation.
> 
> We have two situations:
> 1) media packets arrive to the UAC before the 180.
> 
> 2) the 180 arrives before the first media packets.
> 
> Situation 1) is not a problem, since the UAC will (most 
> likely) not play local ringback, since it is already 
> receiving (and playing) media.
> 
> A null Alert Info would be helpful in Situation 2), but only 
> to avoid that the UAC plays local ringback during the 
> instants (it is a race
> condition) between the arrival of the 180 until the arrival 
> of the first media packets. A simpler solution would be to 
> always wait for, say, a second, before generating local 
> ringback after reception of a 180 (if during that second 
> media is not received).
> 
> In fact, this is what my mobile (GSM) does today. I dial a 
> number, and when the terminal knows that the other user is 
> being paged, it emits a beep (it also displays a message on 
> the screen). Ringback (in this case remote ringback, but it 
> really does not matter) starts a second or so later. Millions 
> of users (me included) find this behaviour acceptable, so it 
> would be acceptable as well for SIP-based systems.
> 
> If the only useful scenario for a null Alert-Info is a race 
> condition of this type, I agree that we should not adopt it.
> 
> Gonzalo
> 
> 
> 
> "Peterson, Jon" wrote:
> > 
> > I don't think that the Alert-Info header proposal will 
> really assuage 
> > the stated problem. Mr. Marshall raised a 'null' Alert-Info 
> proposal 
> > in the previous discussion, and it was rejected then, as it 
> should be 
> > now. Here's the thread:
> > 
> > 
> http://www1.ietf.org/mail-archive/working-groups/sipping/current/msg02
> > 545.ht
> > ml
> > 
> sending a 183 
> > does
> non-ringing in-band
> > media. Null Alert-Info certainly wouldn't give you any 
> additional leverage
> > in cases where media arrives before signaling. I'm not sure what new
> > properties it would grant. The text already suggests a policy of:
> > 
> > ... which essentially entails 'don't play local ringback if 183 is 
> > received'. I'm not sure how it would be any better to recommend a 
> > similar (and redundant) policy relating to Alert-Info.
> > 
> > As an aside, I do agree with Mr. Audet that we should discourage 
> > mixing local ringback tones with received media.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > To: Mark Watson
> > > many of your points have been discussed either in the draft or in 
> > > the mailing list before. The MGC-MG decomposition problem is 
> > > discussed in the draft, and the indication of the 
> presence in-band 
> > > media was discussed in the previous version of the draft.
> > >
> > > My initial proposal was to include an SDP parameter that provided 
> > > information about the intention of the sender. That is, 
> the sender 
> > > intended to send early media... that was seen as too 
> complex (and I 
> > > agree with that, by the way).
> > >
> indicates that 
> > > the UAS does not want the UAC to generate local ringback (like
> > > the mechanism
> > > proposed in this thread), would be sensible, IMO.
> > >
> > > How do people feel about using the header field below in a 18x 
> > > response to indicate that the UAS would like the UAC not 
> to provide 
> > > local ringback (as proposed previously in this thread)?
> > >
> > > Alert-Info: <data:,>
> > >
> > > > then the general model is that the MG is controlled by the MGC. 
> > > > The MGC has only explicit app. layer indications to work from -
> > > it cannot
> > > > take actions on the basis of receipt of not of media packets 
> > > > because it does not see them.
> > > >
> > > > instruct it appropriately, but this takes time & I don't think 
> > > > it's standardised.
> > > >
> > > > which is not communicated to the UAC (at the SIP layer) 
> - namely 
> > > > the availability of in-band media. This can only result in the
> > > UAC taking
> > > > Perhaps we should not be telling the UAC to 'play local 
> ringing' 
> > > > or 'don't play local ringing', but if the UAS knows there is 
> > > > in-band information, it should tell the UAC in SIP.
> > > >
> > > > Regards...Mark
> > > >
> > > > > Thanks for your response.  I understand and agree with your 
> > > > > concerns about race conditions as well as the 
> discussion of how 
> > > > > to handle them.  But I do not want the UAS to blindly control 
> > > > > when the UAC should apply local ringing.  I want the 
> UAS to be 
> > > > > able to indicate when the UAC should NOT apply local 
> ringing.  
> > > > > There is a very important distinction here. According to your 
> > > > > draft, when a UAC receives a 180 it should be prepared to 
> > > > > generate local ringing, and it is a matter of local 
> policy what 
> > > > > the UAC should do when there is concurrent in-band media.  
> > > > > Gateway resources should be allocated to detect in-band media 
> > > > > and decide whether or not to generate ringing.  But 
> under some 
> > > > > circumstances the UAS knows that call progress information is 
> > > > > available in-band and the UAC does not need to bother to 
> > > > > allocate extra resources to monitor the media flow and 
> > > > > optionally inject ringing.  I believe it is important 
> for a UAS 
> > > > > to be able to indicate this situation to a UAC.  These are 
> > > > > processing ! resources that could be put to use elsewhere.  
> > > > > There are no race conditions in this situation - only the 
> > > > > recognition that local ringing and packet detection are 
> > > > > unnecessary.
> > > > >
> > > > > I stand by my original suggestion and continue to request a 
> > > > > modest addition to your draft based on this general 
> approach (my 
> > > > > previous email indicates one possible detailed solution).  
> > > > > Please let me know if you see any further issues.
> > > > >
> > > > > Regards,
> > > > > Richard Ejzak
> > > > > Lucent Technologies
> > > > >
> > > > >
> > > > >
> > > > > tell the UAC whether local ringback has to be 
> generated or not 
> > > > > is
> > > > race
> > > > > header field in a reponse, or a special status code, or a 
> > > > > special body, or whatever to signal it. You always have race 
> > > > > conditions.
> > > > >
> > > > > After a while, the callee picks up. The UAS sends 
> back a 200 OK 
> > > > > and starts sending media. The 200 OK, for some 
> reason, arrives 
> > > > > much later than the
> > > > > synchronized, you will always have race conditions 
> and you will 
> > > > > have to make guesses about what to do during those race 
> > > > > conditions anyway.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Gonzalo
> > > > >
> > > > >
> > > > >
> > > > > depending on the arrival of media packets to 
> determine whether 
> > > > > or not to generate local ringing.  I have previously (last 
> > > > > summer) suggested a solution to this (use 180 exclusively to 
> > > > > indicate that local ringing should override any 
> inband media and 
> > > > > 183 otherwise) that is unacceptable since it does not satisfy 
> > > > > the requirement that 180 be used to indicate alerting of the 
> > > > > called party.
> > > > > >
> > > > > following way? Since the real problem is that we 
> would like to 
> > > > > be able to discriminate between cases when 180 should cause 
> > > > > local ringing and when 180 should not (since inband media is 
> > > > > available), and it is the UAS that knows conclusively 
> which case 
> > > > > applies, let's agree on an encoding of the Alert-Info header 
> > > > > that indicates that local ringing should not be applied.  The 
> > > > > following line is a syntactically valid header:
> > > > > >
> > > > > > Alert-Info: <data:,>
> > > > > >
> > > > > which seems unambiguously and efficiently 
> interpretable within a 
> > > > > 180 response as "do not play local ringing even though the 
> > > > > called party is being alerted."  If the UAC does not 
> recognize 
> > > > > it or chooses not to interpret it for security 
> reasons, it can 
> > > > > be safely ignored.
> > > > > >
> > > > > mechanism) would make it unnecessary for the gateway model to 
> > > > > depend on local policy or incoming media packet 
> detection and is 
> > > > > completely consistent with all of the constraints you have 
> > > > > documented.
> > > > > >
> redundant 
> > > > > with SDP and prone to error.  It is also ambiguous in 
> the event 
> > > > > of any subsequent media change using UPDATE (Do I begin to 
> > > > > generate local ringing if the rtp stream source 
> address changes?  
> > > > > Or do I continue to listen to the address specified in the 
> > > > > Alert-Info and ignore any UPDATEs?  No to both.)
> > > > > >
> > > > > the "application server" models. I have also removed 
> the parts 
> > > > > we
> > > > did
> > > > > not agree on.
> > > > >
> > > > > [email-masked] for questions on current sip 
> > > This list 
> is for NEW development of the application of SIP Use

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 6 Mar 2003 15:11:20 -0000

Ok, so I have now read the draft (sorry 'bout that short delay there). It is
very good, btw.

The problem is related to 180 only, and specifically the scenario described
by Gonzalo below. The draft does indeed include a good treatment of the
problem for decomposed MG/MGC arhicitecture but the only solution suggested
seems to be mixing local ringback with inband media. I tend to agree with
Francois and Mr. Peterson, that this is not a good idea.

What is needed, to my mind, is an indication at the SIP layer that in-band
media is/will be provided. This indication is there implicitly in a 183
(there is no other reason why you would send a 183), but not in 180.

I don't care whether it's Alert-Info or something else. Mr Peterson seemed
to object to Alert-Info - do you have an alternative suggestion ?

This requirement has re-surfaced every six months for at least the past two
years & my bet is that it will keep resurfacing until we address it.

Regards...Mark

PS: Minor nit in the first para of 2.1.1 - two occurances of UAS in the last
line should be UAC, I think.

> Sent: 06 March 2003 13:46
> To: Peterson, Jon
> well, I can see which scenario he is after, but I agree that the
> solution would not bring much value.
> 
> that the user
> He is proposing a flag (i.e., null Altert-Info) for resolving that
> situation.
> 
> We have two situations:
> likely) not play
> local ringback, since it is already receiving (and playing) media.
> 
> A null Alert Info would be helpful in Situation 2), but only to avoid
> that the UAC plays local ringback during the instants (it is a race
> of the first
> media packets. A simpler solution would be to always wait for, say, a
> second, before generating local ringback after reception of a 180 (if
> during that second media is not received).
> 
> In fact, this is what my mobile (GSM) does today. I dial a number, and
> when the terminal knows that the other user is being paged, it emits a
> beep (it also displays a message on the screen). Ringback (in 
> this case
> remote ringback, but it really does not matter) starts a second or so
> later. Millions of users (me included) find this behaviour acceptable,
> so it would be acceptable as well for SIP-based systems.
> 
> condition of
> this type, I agree that we should not adopt it.
> 
> Gonzalo
> 
> 
> 
> "Peterson, Jon" wrote:
> > 
> really assuage the
> > stated problem. Mr. Marshall raised a 'null' Alert-Info 
> proposal in the
> > previous discussion, and it was rejected then, as it should 
> be now. Here's
> > the thread:
> > 
> > 
> > received'. I'm not sure how it would be any better to 
> recommend a similar
> > (and redundant) policy relating to Alert-Info.
> > 
> discourage mixing
> > local ringback tones with received media.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > > many of your points have been discussed either in the 
> draft or in the
> > > mailing list before. The MGC-MG decomposition problem is 
> discussed in
> > > the draft, and the indication of the presence in-band media was
> > > discussed in the previous version of the draft.
> > >
> > > information about the intention of the sender. That is, the sender
> > > indicates that the
> > > UAS does not want the UAC to generate local ringback (like
> > > the mechanism
> > > 18x response
> > > to indicate that the UAS would like the UAC not to provide local
> > > ringback (as proposed previously in this thread)?
> > >
> > > Alert-Info: <data:,>
> > >
> - namely the
> ringing' or
> > > > > concerns about race conditions as well as the discussion of
> > > > > how to handle them.  But I do not want the UAS to blindly
> > > > > control when the UAC should apply local ringing.  I want the
> > > > > UAS to be able to indicate when the UAC should NOT apply
> > > > > local ringing.  There is a very important distinction here.
> > > > > According to your draft, when a UAC receives a 180 it should
> > > > > be prepared to generate local ringing, and it is a matter of
> > > > > local policy what the UAC should do when there is concurrent
> > > > > in-band media.  Gateway resources should be allocated to
> > > > > modest addition to your draft based on this general approach
> > > > > (my previous email indicates one possible detailed solution).
> generated or not is
> > > > > special body,
> > > > > depending on the arrival of media packets to determine
> > > > > whether or not to generate local ringing.  I have previously
> > > > > (last summer) suggested a solution to this (use 180
> > > > > exclusively to indicate that local ringing should override
> > > > > any inband media and 183 otherwise) that is unacceptable
> > > > > since it does not satisfy the requirement that 180 be used to
> > > > > indicate alerting of the called party.
> > > > > >
> > > > > following way? Since the real problem is that we would like
> > > > > to be able to discriminate between cases when 180 should
> > > > > cause local ringing and when 180 should not (since inband
> > > > > media is available), and it is the UAS that knows
> > > > > conclusively which case applies, let's agree on an encoding
> > > > > of the Alert-Info header that indicates that local ringing
> > > > > should not be applied.  The following line is a syntactically
> > > > > valid header:
> > > > > >
> > > > > > Alert-Info: <data:,>
> > > > > >
> > > > > within a 180 response as "do not play local ringing even
> > > > > though the called party is being alerted."  If the UAC does
> > > > > not recognize it or chooses not to interpret it for security
> > > > > reasons, it can be safely ignored.
> > > > > >
> > > > > depend on local policy or incoming media packet detection and
> > > > > is completely consistent with all of the constraints you have
> > > > > documented.
> > > > > >
> > > > > as the source of the alert info (although this would require
> > > > > the definition of a new URI scheme type).  It might look like:
> > > > > >
> > > > > redundant with SDP and prone to error.  It is also ambiguous
> > > > > in the event of any subsequent media change using UPDATE (Do
> > > > > I begin to generate local ringing if the rtp stream source
> > > > > address changes?  Or do I continue to listen to the address
> > > > > specified in the Alert-Info and ignore any UPDATEs?  
> No to both.)
> > > > > >
> the parts we

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 6 Mar 2003 13:58:50 -0600

I must agree with Mark that this problem will not go away without an agreed-upon solution.  And while some system configurations may work with the mechanisms currently available, other configurations will have problems.  The earlier thread referenced by Jon discusses the near-term adequacy of the SIP-ISUP text while pointing out that a full early media solution is still needed.  It seemed that Jon was also suggesting that a gateway UAS could send 183 after it became aware of subscriber alerting to solve the problem (I agree it would), but I definitely heard objections to this.  It seems to me that Gonzalo's draft is the right place to address this problem.  We have now had proposals to include either 183 (instead of 180), SDP, Reason-Phrase or Alert-Info (and probably others) which have all raised objections.
 
I have another proposal which is a variation of one made last summer.  What about including a special token in the Reason-Phrase of the 180 (instead of the 183, as proposed last year)?  Instead of "SIP/2.0 180 Ringing" let it say "SIP/2.0 180 Ringing In-Band" or a similar message.  3261 allows any text for Reason-Phrase.  Let's establish the convention that a gateway UAS should use this encoding of the Reason-Phrase to indicate that in-band progress information is available, and that the UAC may use (but is not required to use) this information to make decisions related to processing of media.  This is a meaningful message that can be displayed to a human at a UAC user interface.  This convention does not in any way limit the use of the Reason-Phrase by other SIP entities.
 
Yet another less attractive solution is to define a new header.
 
Comments?  Alternative suggestions?
 
Regards,
Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Thursday, March 06, 2003 9:11 AM
To: 'Gonzalo Camarillo'; Peterson, Jon
Cc: 'Ejzak, Richard P (Richard)'; sipping
Subject: RE: [Sipping] New version of the early media draft

Ok, so I have now read the draft (sorry 'bout that short delay there). It is very good, btw. 

The problem is related to 180 only, and specifically the scenario described by Gonzalo below. The draft does indeed include a good treatment of the problem for decomposed MG/MGC arhicitecture but the only solution suggested seems to be mixing local ringback with inband media. I tend to agree with Francois and Mr. Peterson, that this is not a good idea.

What is needed, to my mind, is an indication at the SIP layer that in-band media is/will be provided. This indication is there implicitly in a 183 (there is no other reason why you would send a 183), but not in 180.

I don't care whether it's Alert-Info or something else. Mr Peterson seemed to object to Alert-Info - do you have an alternative suggestion ?

This requirement has re-surfaced every six months for at least the past two years & my bet is that it will keep resurfacing until we address it.

Regards...Mark 

PS: Minor nit in the first para of 2.1.1 - two occurances of UAS in the last line should be UAC, I think. 

> http://www1.ietf.org/mail-archive/working-groups/sipping/curre <http://www1.ietf.org/mail-archive/working-groups/sipping/curre>  
> nt/msg02545.ht 
> > ml 
> > 
> > > http://standards.ericsson.net/gonzalo/papers/draft-camarillo-s <http://standards.ericsson.net/gonzalo/papers/draft-camarillo-s>  
> > > ipping-early-media-01.txt 
> > > > 
> > > > >

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 7 Mar 2003 09:17:24 -0000

Jon,

You have missed one very important point which is that in-band media during
alerting is not necessarily 'just ringtone'. It is quite common for the call
to be in the 'Alerting' state (and for this to be know to a SIP to ISUP
gateway), but for the in-band media to contain some useful information other
than 'just ringtone'.

For example, in the UK at least, if the called party has Call Waiting, then
the call of course goes straight in to the Alerting state, but the caller
will here a message along the lines 'Please wait while we try to connect
your call - the person you are calling knows you are waiting'.

A second example would be when the call terminates on a queueing system, and
the message played gives the caller some idea of how long they will need to
wait.

I absolutely agree that if the in-band media was 'just ringtone' there would
be no point. In particular I don't see any need to support the PSTN
'feeture' in which you always hear the ringtone of the destination country
(IMO this is a bug, not a feature!).

So, let's recognise that there are cases where *both* out-of-band and
in-band status indications are present. My view is that out-of-band
indications should always be propogated if available - so for the scenario
in question we MUST use 180, not 183. Now we need to indicate that in-band
status is also available - is this really so hard ????

...Mark

> Sent: 07 March 2003 00:09
> To: 'Ejzak, Richard P (Richard)'; Peterson, Jon; 'Gonzalo Camarillo'
> Cc: Watson, Mark [MOP:EP10:EXCH]; sipping
> Everything below is familiar ground, and I don't want to 
> start rehearsing
> these same arguments again. SIP has made a number of design 
> decisions that
> predispose it towards out-of-band status information. Sending 
> in-band status
> information in SIP is harmful - period. In-band media should 
> be sent only
> when the gateway does not know the status of the call, and thus cannot
> communicate it out-of-band. Below, you basically argue that 
> in cases where
> the gateway does not know the status of the call, it has to send early
> media. I agree. I said that in cases in which the gateway 
> knows that the
> early media is just ringtone, it should send 180. Clearly, if 
> there's some
> in-band transition in call state from ringtone to some other 
> audible call
> progress information, and the gateway isn't made aware of it, then the
> gateway doesn't know the state of the call. Perhaps we might draw the
> conclusion from your example that out-of-band call status 
> indicators are
> inherently unreliable, then - and surmise that it is 
> impossible for the
> gateway to know the state of the call. Or perhaps the 
> likelihood of this
> condition arising is sufficiently remote, the consequences of 
> sending early
> media sufficiently troublesome, that we might decide the 
> in-band information
> in these cases is not 'essential' enough to worry over. But I 
> firmly believe
> we should leave this to the conscience of the individual gateway
> implementer. I don't think the early media draft needs to draw that
> conclusion.
> 
> Mr. Camarillo's draft already maintains a very delicate 
> balance of behavior
> to accommodate SIP's needs, and I haven't heard anything in 
> this yet that
> should alter it.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > Sent: Thursday, March 06, 2003 2:40 PM
> > To: 'Peterson, Jon'; 'Gonzalo Camarillo'
> > Cc: Mark Watson; sipping
> > I must disagree with your blanket recommendation that the 
> > gateway not sent in-band ringing media.  This may be possible 
> > in some cases - and nothing we have suggested would prevent a 
> > gateway from using out-of-band indications.  But ringing is 
> > not the only in-band call progress information you may 
> > receive while trying to establish a call from SIP to ISUP.  
> > The transition from alerting to other forms of in-band call 
> > progress information is not guaranteed to be clearly signaled 
> > by ISUP within an ACM or CPG (since every switch in the 
> > network can safely assume in-band call progress after a 
> > certain point in the call), and it is essential that this 
> > subsequent information (when it exists) be presented to the 
> > UAC/user.  And the notion of having the gateway intelligently 
> > filter what it thinks is ringing and detect a transition to 
> > other forms of call progress is not acceptable.
> > 
> > Regards,
> > Richard Ejzak
> > Lucent Technologies
> > 
> > 
> >

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 7 Mar 2003 13:59:23 -0000

Gonzalo,

I didn't say that media clipping was not a problem, or that I was concerned
only with systems which did not care about media clipping. I just said that
media clipping was not the problem I was addressing here.

The problem I am addressing here is how an MGC decides whether to instruct
it's MG to play local ringing or to play media.

Your argument seems to be something along the lines of:
1) Because of the media clipping problem, the MG will need to detect in-band
media, and 
2) this also provides a solution to the MGC/MG ringback problem, because
either
2a) the MG can override local ringback with the detected media, or
2b) the MG can report the detected media to the MGC, which can instruct the
MG to play it

I am saying that, **whether or not (1) is true**, (2) is not. We can argue
about whether or not (1) is true, are there other solutions to media
clipping etc., but that is not the issue.

Neither 2a not 2b provide an acceptable general solution to this problem =>
(2a) involves inappropriate autonomy for the MG and 2b is not supported in
the standards right now and IMO a little kludgy. Further, both 2a and 2b
seem to be inappropriate architecturally since they attach symantics to the
arrival of the RTP data.

Further, there is scope in the current specs for TDM gateways which send
backwards media right from the off, which may contain silence - do I need to
look inside the RTP packets to see if there is 'real' media there ?

So, I rather think it is *your* solution which is not general. Addition of a
functional indication of in-band media at the SIP layer would ensure we have
a solution to this problem in all cases.

Regards...Mark

> Sent: 07 March 2003 12:31
> Cc: Peterson, Jon; 'Ejzak, Richard P (Richard)'; sipping; Audet,
> Francois [SC100:4K02:EXCH]
> OK, now I think I understand you. You want to develop a flag 
> to be used
> by systems that do not care about media clipping (they are 
> probably in a
> controlled environment without race conditions) but care about not
> having to perform media detection (because they are distributed;
> MGC-MG).
> 
> One of the assumption when designing SIP was that systems cared about
> media clipping... I do not think we can develop general extensions at
> this point in time that cause media clipping in order to 
> resolve things
> like ringback generation.
> 
> You may want to create a document that defines a P-flag and 
> says: if you
> do not care about media clipping for some reason, use this 
> flag to have
> accurate information in the SIP layer about the presence of media.
> 
> I understand what you are after, but I do not think we have a 
> *general*
> mechanism that resolves it.
> 
> Gonzalo
> 
> 
> 
> Mark Watson wrote:
> > 
> > > Mark,
> > >
> > > If I understood your mail correctly, you acknowledge that 
> when race
> > > conditions are possible, a "there is media coming" does not solve
> > > anything.
> > 
> > No, I acknowledge it doesn't solve the race conditions.
> > 
> > > But you believe that in environments where you are sure that
> > > no race conditions will occur, such a flag would be useful.
> > >
> > 
> > No, I am saying that the solution that you have proposed is not
> > appropriate for a decomposed Media Gateway/Media Gateway Controller
> > case. I acknowledge that the race condition problem still exists in
> > that case (e.g. at answer), but I still think the media detection
> > solution is not appropriate. So, perhaps the race condition problem
> > remains unsolved in that case, but I am not so concerned about that
> > problem.
> > 
> > > However, we do not design SIP with that type of environments in
> > mind.
> > > Any SIP mechanism should work assuming that SIP-RTP race 
> conditions
> > > occur.
> > >
> > 
> > Of course not, but surely we do design SIP in a way which 
> can work on
> > a gateway designed according to other IETF standards for gateways
> > (specifically megaco) ?
> > 
> > Even if you do want to assume a monolithic SIP UA, then I 
> still think
> > it's valuable to pay attention to the layering in the 
> system. I still
> > believe it's more robust if the media stream state is known at the
> > signalling layer.
> > 
> > > Maybe you are after a P-flag to use in close environments 
> where SIP
> > > signalling always beat RTP packets?
> > >
> > 
> > Not exactly. The SIP message does not need to beat the RTP packet
> > anyway. There are well-established standards which imply acceptable
> > times within which cut-through should occur at answer, for example.
>

---

From: Michael Hammer <[email-masked]>
Date: Fri, 07 Mar 2003 11:51:07 -0500

Mark,

I understand the essence of your problem is not the signaling that RTP 
packets are flowing, but signaling the intent of the downstream switch to 
insert meaningful content into the RTP stream.

The 180 alone does not convey this signaling information.  Nor can this 
signaling information be inferred from the receipt of an RTP packet flow 
(absent the ability to detect all possible announcements/signals used 
around the world).

What you are saying is that this signaling information is presented at the 
IWF, but there is no signaling element to map it to.  Thus this feature 
must be terminated at the IWF.

Mike

At 10:02 AM 3/7/2003 +0000, Mark Watson wrote:

>Gonzalo,
>
>The 200 OK vs RTP packet race condition is a smaller problem than 
>correctly deciding whether to play in-band media or local ringing. It 
>doesn't necessarily justify media detection at the MG anyway (or rather. 
>the MG taking 'autonomous' action on the basis of media detecion, which is 
>the problematic part) .
>
>I don't think that cutting through the actual media just on the basis of 
>receipt of a media packet would be an acceptable solution in some (common) 
>business models anyway - they will want to wait for the 200 OK before 
>cutting through media. If that results in speech clipping then your RTT is 
>probably too long for acceptable speech quality anyway.
>
>Also, as a general layering principle, I think it is bad to attach 
>semantics to the presence/absence of RTP packets - the expected state of 
>the media stream should be completely known to the endpoints based on the 
>SIP/SDP negotiations. This surely makes the system more robust and assists 
>debugging because it allows be to detect an error case where I am 
>expecting to receive media but do not.
>
>I am confused by the resistance to solving this problem in the 
>straightforward way. The existance of in-band media seems a perfectly 
>reasonable thing to want to signal at the SIP layer. People seem quite 
>happy to give the 183 message this semantic, for the case where the call 
>state is unknown - why is it such a big deal to convey the *same 
>information* at the SIP layer for the case where the call state is known 
>to be alerting ?? All I want to do is atomically signal the equivalent of 
>180 *plus* 183.
>
>...Mark
>
> [<mailto:[email-masked]>mailto:[email-masked]] 
>
> > Sent: 07 March 2003 09:27
> > the text says that such a flag would not solve that issue, because you
> > have to implement media detection *anyway* for covering other
> > scenarios
> > (motivational paragraph at the bottom).
> >
> > > I still think this problem remains unsolved.
> >
> > The point is that such a flag would not solve it either.
> >
> > Gonzalo
> >
> > Mark Watson wrote:
> > >
> > > Gonzalo,
> > >
> > > Your text does not recognise the desire to avoid reading
> > semantics in
> > > to the arrival of RTP packets, to cope with the MGC/MG scenario.
> > >
> > > I still think this problem remains unsolved.
> > >
> > > ...Mark
> > >
> [<mailto:[email-masked]>mailto:[email-masked]] 
>
> > > > Sent: 07 March 2003 08:48
> > > > To: Peterson, Jon
> > > > Cc: 'Ejzak, Richard P (Richard)'; Watson, Mark
> > > > [MOP:EP10:EXCH]; sipping;
> > > > Audet, Francois [SC100:4K02:EXCH]
> > > > I agree with Jon that we should not encourage people to
> > send in-band
> > >
> > > > ringing tones, but I also agree with Mark that this issue has
> > > > re-surfaced a number of times already. The message we want to get
> > > > through is that adding a SIP flag for resolving that issue
> > > > offers little
> > > > or no value.
> > > >
> > > > I am willing, if people agree, to add some text saying
> > why it is not
> > > a
> > > > good idea to add a SIP-layer flag to 180 responses indicating
> > > > that media
> > > > is coming.
> > > >
> > > > What about a section along these lines:?
> > > >
> > > > 2.2.1 Problems with SIP-layer Indications in 180 Responses
> > > >
> > > > As stated above, it is not an easy task for a UAC that receives a
> > > 180
> > > > (Ringing) response to decide whether it should generate local
> > > ringback
> > > > or it will be receiving early media. At first sight, it may seem
> > > that
> > > > adding a "there is media coming" indication to 180 (Ringing)
> > > responses
> > > > would facilitate the task of UACs. Upon reception of a
> > 180 (Ringing)
> > >
> > > > response with such an indication, the UAC would not generate local
> > > > ringback. However, such an indication would offer little
> > or no gain.
> > >
> > > >
> > > > The only scenario where such an indication would be applicable is
> > > when
> > > > the UAS sends a 180 (Ringing) response and starts sending early
> > > media
> > > > right away. If the UAS intended to send early media at a
> > later time,
> > >
> > > > instead of right away, a sensible local policy for the
> > UAC could be
> > > to
> > > > generate local ringback in the meantime. Therefore, the
> > > > "there is media
> > > > coming" indication would be useless.
> > > >
> > > > Assuming, then, that the UAS sends the 180 (Ringing) response and
> > > the
> > > > first media packets in parallel towards the UAC, we have a race
> > > > condition. If the media packets arrive at the UAC before the 180
> > > > (Ringing) response, the "there is media coming"
> > indication will not
> > > > provide any further information to the UAC.
> > > >
> > > > The only situation where the UAC could benefit from that
> > indication
> > > is
> > > > when the 180 (Ringing) response arrives before the first
> > > > media packets.
> > > > The UAC could avoid generating local ringback for an instant
> > > > before the
> > > > first media packets arrive. However, the same result can be
> > > > achieved in
> > > > a much simpler way (without protocol extensions) by just
> > having UACs
> > >
> > > > always delay the generation of local ringback for a short
> > period of
> > > > time. The UAC can, for instance, generate a short beep upon
> > > > reception of
> > > > the 180 (Ringing) response (this is already done by some
> > > > circuit-switched mobile terminals) and one second later start
> > > > generating
> > > > local ringback if no media have been received during that period.
> > > >
> > > > \motivation{Note that adding such an indication does not keep
> > > > UACs from
> > > > implementing media arrival detection either, since they have to
> > > > implement it anyway to cover other scenarios, like the race
> > > condition
> > > > between the 200 OK for the INVITE and the first regular media
> > > > packets).}
> > > >
> > > >
> > > > Opinions?
> > > >
> > > > Gonzalo
> > > >
> >
> > --
> Finland 
> <http://www.hut.fi/~gonzalo>http://www.hut.fi/~gonzalo
> >

---

From: Michael Hammer <[email-masked]>
Date: Fri, 07 Mar 2003 12:21:40 -0500

Mark,

If the rule is to play media immediately upon receipt, then the need to 
signal that signaling content in the media is moot. The local ring-back 
would be over-ridden anyway.

What I am not so certain of is the opposite case when RTP is cut-through, 
but no in-band ringing is provided by the destination PSTN switch (is this 
normal; do we care?):

1) There is no ring-back (or maybe 1 ring), the user listens to dead air 
for some time, and eventually the person comes on line.  (This can happen 
in quick pickup cases.)

2) There is no ring-back (or maybe 1 ring), the user listens to dead air 
for some time (could be minutes) until an announcement or special tone 
comes, or the call is simply released.

Did I cover the proposed approach correctly?

Mike

At 01:59 PM 3/7/2003 +0000, Mark Watson wrote:

>Gonzalo,
>
>I didn't say that media clipping was not a problem, or that I was 
>concerned only with systems which did not care about media clipping. I 
>just said that media clipping was not the problem I was addressing here.
>
>1) Because of the media clipping problem, the MG will need to detect 
>in-band media, and
>2b) the MG can report the detected media to the MGC, which can instruct 
>the MG to play it
>
>Neither 2a not 2b provide an acceptable general solution to this problem 
>=> (2a) involves inappropriate autonomy for the MG and 2b is not supported 
>in the standards right now and IMO a little kludgy. Further, both 2a and 
>2b seem to be inappropriate architecturally since they attach symantics to 
>the arrival of the RTP data.
>
>backwards media right from the off, which may contain silence - do I need 
>to look inside the RTP packets to see if there is 'real' media there ?
>
>So, I rather think it is *your* solution which is not general. Addition of 
>a functional indication of in-band media at the SIP layer would ensure we 
>have a solution to this problem in all cases.
>
>Regards...Mark
>
>

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 7 Mar 2003 17:22:41 -0000

> insert meaningful content into the RTP stream.

Well, it's both, really. The 'intent to insert meaningful content' is the
clearest, but even if we knew that gateways didn't send 'meaningless'
content (i.e. that they *only* sent RTP with meaningful content), then I
still think that using the RTP packet itself as an indication is putting the
function at the wrong layer.

> IWF, but there is no signaling element to map it to. 

Yes.

> Thus 
> this feature 

...or a new signalling element defined to carry it. I vote for a new
signalling element because I believe the information is useful to the UAC,
especially if the UAC is a decomposed gateway.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Mar 2003 13:03:29 -0500

I'm not sure I missed that point, exactly. I said that if the gateway knows
that the early media is just ringtone, it should send a 180. You're just
citing another case below in which the early media is not ringtone. I can't
see how this contradicts what I said. If there's some other in-band status
information available, the gateway should be using 183.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, March 07, 2003 1:17 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon, 

...Mark 

> > > From: Gonzalo Camarillo [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 8 Mar 2003 14:58:15 -0500

Cases in which no interworking is encountered and ISUP fails to portray call
status are problematic, sure. Agreed that there are lazy PBXs that may not
use Q.931 correctly, which results in poor ISUP, and so on. But if ISUP lies
to you about call status, then that creates internal problems for the PSTN,
not just interworking with SIP. I'm sure you are aware that there are PSTN
cases in which ringing is not generated by the remote switch, in which
out-of-band signaling causes ringback to be generated elsewhere in the
network. These cases would seem to have problems when out-of-band ISUP
indicators are wrong.
 
I'm not sure that it's our job to design interworking cases around
non-standard usages of PSTN protocols, however. We could similarly say that
if a native SIP endpoint sent a 180 when the call is actually in a state
more indicative of 181, or something, that it would be problematic, but I
don't think we therefore need to say that SIP endpoints always need to
transmit in-band status info.
 
But this is all moot from my perspective - a new in-band indicator for SIP
won't make any of this any easier. You are correct, I am saying that a UAS
gateway should send 183 when it does not know the status of the call - that
is effectively the only in-band indicator that I think we need. But this
fact doesn't interact well with your lack of a 'guarantee' about whether or
not the out-of-band status is accurate, though. Presumably, you think that a
UAS gateway would be required to deliver in-band status info for every call,
because there is never any 'guarantee' that ISUP is correct. I don't think
we should recommend that a gateway always send in-band status information,
whether it would be sent with a 180 or 183. In-band status information, as
I've said before, is bad; how we indicate that there is in-band status info
is orthogonal to the real issue here.
 
Anyway, Gonzalo's draft is concerned with early media as a general
interworking phenomenon, I believe - it isn't just limited to ISUP. So I
agree that Gonzalo's draft is not the right place to recount the various
ISUP indicators and how a gateway UAS will treat them. You are correct that
RFC3398 is the right place for that specification. Currently, though, I
don't see a need to revise its existing text.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Ejzak, Richard P (Richard) [mailto:[email-masked]]
Sent: Friday, March 07, 2003 3:04 PM
To: 'Peterson, Jon'; 'Mark Watson'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon,
You are assuming a model in which the UAS gateway call control entity has
perfect knowledge of the content of the media stream.  This is frequently
not true, particularly in a decomposed MGC/MG architecture.  There are two
possible ways for it to gain this knowledge: 1) for the MG to monitor the
media stream and analyze its contents and report the results to the MGC (an
unacceptable solution); or 2) for the MGC to receive this information from
the next hop via the call control protocol on that hop (ISUP/BICC/SIP).  But
for case 2) to work, an MGC depends on the chain of switches all the way to
the terminating switch to accurately signal this information (equivalent to
183 if it's not ringing tone; 180 if it is) in the backward direction.  One
simple example of where this breaks down is when no COT is performed and
there is a link failure (i.e. there is no in-band information even while
alerting).  In effect, the in-band information tests the media path,
providing immediate information about the media path to the caller so the
call can be abandoned if appropriate.  THIS IS NOT POSSIBLE without having a
clear indication in the 180 from the UAS that there is supposed to be
in-band progress information.  The current text would have the UAC inject
local ringing in the absence of in-band media, while what we really want to
do is play silence since there is no media path beyond the UAS anyway!  Many
more examples are possible.  Alerting indication (180) does not necessarily
mean there is in-band ringing when in-band information is present.  There
may be announcements or various tones or nothing, depending on the state of
the network.  There is no guarantee that a UAS gateway will have sufficient
information to send a 183 if in-band call progress information changes
during alerting.
 
In general, I support Mark's analysis of the situation and continue to
request an in-band call progress indication for the 180 response.
 
If you are alternately saying that a UAS gateway that cannot guarantee that
any in-band call progress information it may be sending is in the form of a
ringing tone should send 183 rather than 180 after receiving "subscriber
free" or "alerting" indications, then I can also accept this solution.  But
then this new guideline must be clearly spelled out in either Gonzalo's
draft or RFC 3398, preferably the latter, since a UAS gateway will rarely
send 180 once in-band information is available.  I have seen some strong
resistance to this in prior emails on this reflector.  We can't have it both
ways.
 
Regards,
Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Friday, March 07, 2003 12:03 PM
To: 'Mark Watson'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, March 07, 2003 1:17 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon, 

...Mark

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 10 Mar 2003 09:14:54 -0000

Jon,
 
If I use 183 then I lose the functional (out of band) indication that the
call is now in the Alerting state. So then, for example, a more advanced SIP
client may not provide the correct visual indication to the use ('ringing'
icon, or whatever).
 
We are talking about cases where the call state IS known to be 'Alerting',
so I think we must surely use 180, not 183. But there are useful in-band
tones AS WELL. In general a gateway would not know whether the in-band
information was boring ringtone, or something more interesting.
 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 07 March 2003 18:03
To: Watson, Mark [MOP:EP10:EXCH]; 'Ejzak, Richard P (Richard)'; 'Gonzalo
Camarillo'
Cc: sipping

 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, March 07, 2003 1:17 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon, 

...Mark

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 10 Mar 2003 10:47:59 -0000

You've responded to my question with another question! I did not say it had
a purpose, I asked whether there was anything which specified a particular
behaviour.

As I understand things, it is quite common for the MG component of a PSTN
gateway to be rather dumb. It could be instructed to cut-through the
backwards media path immediately the INVITE->IAM is processed, in which case
it will just blindly pass through whatever is received from the PSTN side.

In the case that there is in fact no in-band ringing tone, it would be a
mistake for the UAC to play this media. The UAS (gateway) does in fact have
an indication of whether there is in-band media or not which is could
provide to the UAC with the proposed SIP extension. The UAC can then make a
more intelligent decision on playing the media or local ringback.

I don't think it would be ideal for PSTN gateways to work this way, but it
does not seem an unreasonable implementation given that in the majority of
cases where will be in-band ringing.

So, my question was whether it was *specified* that PSTN gateways will not
do this. If it is specified, then of course the media detection solution can
work in some environments, although I still do not think it is applicable in
all or the most robust solution.

...Mark

> Sent: 10 March 2003 09:38
> Cc: Audet, Francois [SC100:4K02:EXCH]; 'Peterson, Jon'; 
> 'Ejzak, Richard
> P (Richard)'; 'sipping'
> what is the purpose of a gateway telling you to generate 
> local ringback
> and sending you silence at the same time?
> 
> Gonzalo
> 
> Mark Watson wrote:
> > 
> > And how do I know whether the RTP packets contain actual 
> useful media,
> > or whether some PSTN gateway is blindly copying silence 
> from the G.711
> > TDM stream into RTP ? Is it specified somewhere that PSTN gateways
> > SHALL NOT do this ?
> > 
> > ...Mark
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 10 Mar 2003 10:47:39 -0600

Gonzalo,
You ask about the gains from including an indication of in-band call progress information with a 180:

Scenario 1) 183 completes media negotiation, followed by 180.  If there is an in-band media indication in the 180 then the MGC has no need to update the MG with any ring tone instructions or media policy instructions upon receipt of 180, and the MGC does not need to tell the gateway when the period of potential ring tone injection is over (with receipt of 200 OK).  We do not risk the danger of injecting potentially inappropriate local ringtone.  If there is no in-band media indication in the 180 because there is no in-band media, then the media policy instructions could be made more explicit to continue injecting tones even in the presence of some noise (e.g. RTP comfort noise packets, silence packets, or brief periods of sound) since in-band information is not expected.  Any valid shift from local ringing to in-band information should be almost immediately followed by removal of the ringtone and policy instructions.  If they are not removed soon after shifting to in-band me!
dia, the shift was probably done in error.  If the media policy instructions need to handle both cases where there may or may not be in-band media, then how can one tell if the media packets are legitimate call progress information (since in-band call progress may be anything, including silence)?  A hair trigger (one or a small number of RTP packets) seems highly prone to error.  An explicit indication of in-band call progress information, on the other hand, is quite robust.

Scenario 2) 180 completes media negotiation.  The advantages are the same as scenario 1) except that the ringtone and policy instructions can be left out of the initial MG interaction.

Scenario 3) 180 completes media negotiation, followed by 183.  If the 180 included an indication of in-band media, then both the initial ringtone and policy instructions and the subsequent update to remove them (upon receipt of 183) become unnecessary.  If the 180 indicated no in-band media, then there is still the advantage of being able to institute a more intelligent media policy, as described in scenario 1).

Regards,
Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Saturday, March 08, 2003 3:04 AM
To: Francois Audet
Cc: Mark Watson; 'Peterson, Jon'; 'Ejzak, Richard P (Richard)';
'sipping'

Folks,

I was arguing that any MG will have to implement media arrival detection
anyway, because of the 200 OK-RTP race condition. Therefore, you MG MUST
implement media detection. What do you solve with a SIP provisional
response that tells you that media will be coming? I do not see the
value there. Could somebody explain the gains we get from that approach?

And regarding Mark's comment about placing the functionaloty in the
wrong place, a controller tells (using the media policies developed by
the conferencing design team) the mixer of a conference which
participant's voice should sound louder, which one should be discarded,
etc... you can see this as a media policy issue as well. The MGC sends a
media policy description to the MG:

1) if media comes, play it.

2) until media comes, play ringback tone. 

Gonzalo

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 10 Mar 2003 15:44:09 -0500

Behind this all is probably an argument about what the 'alerting' state in
SIP really means, especially contrasted with 'queuing' and so on. Is call
waiting actually best expressed in the PSTN by ACM with 'subscriber free'?
Is it best expressed in SIP by 180 (or should it be 182)? Whether or not the
PSTN signals 'subscriber free' in ACM for call waiting, that doesn't mean
that the SIP 180 alerting state is co-extensive with arbitrary in-band
status information. The problem is that SIP does not define its states at
this level of granularity, so the evidence for either position would be
indirect at best. 183 expresses that the call is in some provisional state,
that it hasn't yet been rejected as far as SIP knows, and so on - at the
very least, it's sent when other 18x's aren't appropriate for some reason.
 
SIP gains significant benefits from not having to reserve a circuit and
transmit media in the backwards direction in order to communicate that a
telephone is ringing. Again, if ISUP is misleading about the condition that
prevails, I'm not sure that admits of any repair in SIPPING. SIP does
support response codes tailored for queuing situations, but if the PSTN
can't tell us out-of-band that queuing is taking place, we can't map to
them.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, March 10, 2003 1:15 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon,

 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 07 March 2003 18:03
To: Watson, Mark [MOP:EP10:EXCH]; 'Ejzak, Richard P (Richard)'; 'Gonzalo
Camarillo'
Cc: sipping

 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, March 07, 2003 1:17 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon, 

...Mark

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 11 Mar 2003 17:22:55 -0000

Well, yes, if you change the axioms you will get a different conclusion.
 
The Alerting state in ISUP is certainly well-defined. It certainly includes
the possibility of in-band media and does not make any assumptions about
what that media is (i.e. does not assume that it is 'ringtone'). It is not
'misleading' for ISUP to signal 'subscriber free' and to include in-band
media which is other than 'ringtone'.
 
Is the SIP state occasioned by 180 Ringing equivalent to 'Alerting' in ISUP
?? 
 
Now, if you like, you can (re)define the SIP 180 Ringing state so that it
differs from the ISUP Alerting state in respect of support for in-band
media. Let's say that 180 Ringing does not support in-band media - which
seems to be where Jon is going below. Now we have an interesting choice at
PSTN gateways in terms of deciding whether to send 180 or not. We could
determine somehow whether the in-band media was in fact 'ringtone' or not
and use this to decide - but perhaps that is not so realistic. Or we could
send 183 whenever we have in-band media (i.e. almost all the time). Ok, so
this will work, but I have discarded the indication that the subscriber is
in fact free. This is useful information at the UAC for several reasons:
(i) is assists in determining what to do with multiple provisional responses
received due to forking
(ii) I can use it to drive a visual or other indication of call state
 
What is so wrong about wanting to carry this useful information to the UAC
??
 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 10 March 2003 20:44
To: Watson, Mark [MOP:EP10:EXCH]
Cc: [email-masked]'
Subject: RE: [Sipping] New version of the early media draft

 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, March 10, 2003 1:15 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon,

 
...Mark

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 07 March 2003 18:03
To: Watson, Mark [MOP:EP10:EXCH]; 'Ejzak, Richard P (Richard)'; 'Gonzalo
Camarillo'
Cc: sipping

 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, March 07, 2003 1:17 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon, 

...Mark

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 12 Mar 2003 09:24:18 -0000

Gonzalo,

Regarding the SDP direction attribute, this is indeed the solution which was
mooted some time ago, but it is not documented clearly. I think if this is
the proposed resolution of this problem, it does need to be clearly
described & the Early Media draft would be an appropriate place.Then it can
be included in the SIP/ISUP interworking work which is ongoing in ITU-T and
3GPP.

If I understand correctly, you are saying that a UAS SHOULD put the media
'on hold' by setting a=inactive if there is no Early Media. If the media
stream is not 'on hold' then the UAC should assume there is media and play
it. 

This is ok with me, but it does seem to place a new requirement on all
existing UAS's.

I am confused about your position stated at the end of your mail, though. We
are on the sipping list, so the question of what protocol element might be
used if this requirement is agreed is out of scope here. So, are you saying
that you do not find the requirement unreasonable ? Can we agree on that
before jumping into solutions ?

...Mark

> Sent: 12 March 2003 07:11
> Cc: 'Peterson, Jon'; Watson, Mark [MOP:EP10:EXCH]; sipping
> Richard,
> just to be clear, I am not proposing to change the draft. I am just
> saying that using the SDP direction attribute seems to resolve Mark's
> concerns.
> 
> > My concern is to do media detection and tone insertion efficiently, 
> > correctly, and only when necessary.
> 
> I guess the crux of the issue is the part where you say "only when
> necessary"... it is clear that such an indication would save you
> performing media detection for 180 responses with the inband 
> media flag.
> 
> My position is, as I said in this thread before, that if people
> considered this as an important gain, I would not find it unreasonable
> to standardize an empty Alert-Info header field.
> 
> However, others have expressed concerns about that...
> 
> Gonzalo
> 
> > Thanks for your attempt to find a way forward.  But I never 
> objected to media detection across the board.  It is 
> necessary, as you point out, to avoid clipping in certain 
> scenarios.  There was a scenario very similar to the one you 
> propose in an earlier version of the manyfolks draft that was 
> removed after I raised an objection last year, because it 
> introduced a potential for media clipping.
> > 
> > My concern is to do media detection and tone insertion 
> efficiently, correctly, and only when necessary.  As I stated 
> earlier, there is no reason to change how things work for 
> native SIP UAs.  Your proposal would actually have the most 
> impact on native SIP UAs (typically without in-band media)!  
> But when a UAS PSTN gateway is in the mix with in-band call 
> progress media, we know there is no need for either media 
> detection or tone insertion, and, in fact, there's a good 
> chance they would muck things up.
> > 
> > Your proposal unfortunately appears to cause more harm than 
> good (by re-introducing potential for clipping and impacting 
> SIP UAs without in-band media).  We need some kind of 
> indication associated with the 180 (not SDP) that in-band 
> call progress information is available.
> > 
> > I am mightily confused as to why this is such a challenging 
> problem.  I have proposed at least two backwards compatible 
> methods for signaling this information.
> > 
> > Regards,
> > Richard Ejzak
> > Lucent Technologies
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 12 Mar 2003 15:54:52 -0800

It seems to me that Mark and Richard's requirement is not going away.

Why don't we just send a 180 with an SDP and a new header field
"No-Alert-Info"?

Alternatively we could change the syntax of Alert-Info to:

	Alert-Info = "Alert-Info" HCOLON ( alert-param *(COMMA alert-param)
) / "None"

So we'd have in 180 with SDP, an "Alert-Info: None" header field. "None"
would really
mean no alerting should be provided (only in-band early media only).

In my opinion both approaches would be consistent with 183 (which can not
have Alert-Info).
I don't have any preference one way or another.

-----Original Message-----
From: Watson, Mark [MOP:EP10:EXCH] 
Sent: Tuesday, March 11, 2003 09:23
To: 'Peterson, Jon'
Cc: [email-masked]'
Subject: RE: [Sipping] New version of the early media draft

...Mark
-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 10 March 2003 20:44
To: Watson, Mark [MOP:EP10:EXCH]
Cc: [email-masked]'
Subject: RE: [Sipping] New version of the early media draft

Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, March 10, 2003 1:15 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon,

...Mark
-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 07 March 2003 18:03
To: Watson, Mark [MOP:EP10:EXCH]; 'Ejzak, Richard P (Richard)'; 'Gonzalo
Camarillo'
Cc: sipping

Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, March 07, 2003 1:17 AM
To: 'Peterson, Jon'; 'Ejzak, Richard P (Richard)'; 'Gonzalo Camarillo'
Cc: sipping
Subject: RE: [Sipping] New version of the early media draft

Jon,

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Mar 2003 00:35:07 -0500

inline.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, March 12, 2003 1:24 AM
To: 'Gonzalo Camarillo'; Ejzak, Richard P (Richard)
Cc: 'Peterson, Jon'; sipping
Subject: RE: [Sipping] New version of the early media draft

Gonzalo, 

<JFP> The reason why it was mooted (if I recall) is that it seemed to change
the meaning of 'a=inactive'. The UAC has to be prepared to receive media
before 200 OK, in order to avoid clipping of post-answer media. Setting the
media stream inactive is supposed to tell the UAC that it doesn't need to
listen for media, or so the argument goes. I haven't heard that challenged
in this thread, anyway. </JFP>

<JFP> ... which seems to be redundant with sending the pre-answer media
itself, provided that the gateway UAS only sends media when the UAC needs to
render it (because the UAS is unable to communicate status out-of-band for
whatever reason). I'm still not clear why the UAC shouldn't play media, if
it's there. </JFP> 

...Mark

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Mar 2003 14:07:13 +0000

Jon,
 
You wrote:
 
<snip>
Let me see if I can put this is a slightly simpler light. Let's ignore what
SIP status code the gateway sends for a moment.
 
A gateway UAS needs to decide whether it's going to send pre-answer media
media or not. What I've heard you saying is that the indicators in ISUP
don't provide this information (presumably that the 'in-band status
indicator' in OBCI doesn't have to be present in order for the PSTN to send
in-band status, just sending 'subscriber free' in BCI is enough). All right,
let's grant that for a moment.
 
So how does the gateway decide whether or not it's going to send media? I've
heard that ISUP doesn't tell you this, and that in-band media detection at
the UAS gateway is unacceptable.
 
What's the point of proposing some indicator (regardless of where it
appears) that a gateway UAS can send to the UAC signifying pre-answer media
if the gateway has no deterministic way of figuring out whether or not it
should send media? 
</snip>
 
From a QSIG perspective (I believe ISUP is similar) the gateway DOES have a
way of figuring out whether it should send media. There is an explicit
indicator in QSIG that says that in-band media is present. Also there is an
explicit QSIG message that indicates that an alerting state has been
reached. The indication of in-band media can be sent with or without
indication of the alerting state. Therefore there are basically 3 things
that the gateway has the capability of signalling, if SIP allows it to:
 
1. Alerting - no media - 180 satisfies this
2. No state change (not alerting) - media present - 183 satisfies this
3. Alerting - media present - ????
 
The third possibility does not have a satisfactory solution. At present the
qsig2sip draft uses 180 for this and relies on the UAC detecting early media
and playing it in preference to local media. However, this is not very
satisfactory, for reasons that Mark Watson has given. An additional
indicator to include in 180 to say that in-band media is present would be
helpful.
 
John Elwell ( [email-masked] <mailto:[email-masked]> )

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Mar 2003 12:53:48 -0500

More can be found below.

Jon Peterson
NeuStar, Inc.

> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 6:07 AM
> To: 'Peterson, Jon'; 'Mark Watson'
> Cc: [email-masked]'
[snip]
> indication of the alerting state. 

Yes, those indicators exist in ISUP, and they are decoupled from the BCI,
which indicates 'subscriber free' when the user is being alerted. What I've
been hearing in this thread is that these in-band media indicators are not
used reliably. That is, that some ISUP endpoints 'assume' that a media path
has been established by the ACM, and send early media without indicating so
in ISUP. That would complicate things a bit.

> Therefore there are basically 3 things

Yes, well, obviously I think media detection is an adequate solution, and it
is necessary for reasons other than detecting early media - it is also used
to detect and render post-answer media before 200 OK, as Gonzalo has pointed
out. The MGC composition issues, thus far, have not appeared persuasive to
me.

But moreover you are reinforcing Mark's suggesting that the 'Alerting' state
means something specific in SIP, which it doesn't. Even if it did, there
wouldn't be a need to play in-band media during the 'Alerting' state if this
in-band media did not somehow qualify or supplement the information that the
state is 'alerting'. The in-band early media provides status information -
otherwise, there'd be no point in sending it or rendering it. That in-band
media characterizes the true state of the call, not the SIP status code.
That's why I think 183 is adequate for this.

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Mar 2003 18:17:23 -0000

I would agree with John and Mark from that from the ISDN side (be it ISUP, BICC, DSS1 or QSIG, we are talking about 3 cases. I tried to draft some definitions of that before John's mail came in and I ended up with the following:

"The PSTN/ISDN ringing state, arrived at by sending a ringing type message, can be used for more that the simple case of the call being delivered to the end user with ringing in-band. It is also used in the following cases:

i)    cases where there is a need to present information to the user (normally from the service provider) without charging commencing. This case does not carry any special indication in the PSTN signalling, as the backward media path is assumed to be in place once the ringing state is entered.

ii)    cases where the status of the destination is unknown, but there is a need to move out of one of the call set up states due to timer expiry problems. This situation frequently occurs when interworking with less capable signalling systems. I believe there are PBX signalling systems that do not contain an equivalent of a ringing signal at all, and certaining there are still a large amount of none ISUP signalling systems around int he public network (e.g. R2). Normally in this case, it would be expected that some indication of interworking is available at the PSTN side, and this case can be distinguished by that indication, although there have been examples of interworking with R2 in the past, where such an indication was not provided.

Both these cases are represented in the standards for PSTN signalling, and can therefore be assumed to be correct operation in the PSTN.

Combining the normal SIP cases and the PSTN interworking cases, there are three things we need to signal:

1)    The call has been delivered to the end user terminal and the user is being informed of the presence of the request. No media being delivered in-band. This can only be a SIP only case, unless the media path is being inspected to see if it really contains media. This would appear to be the case currently recommended for 180 (Ringing).

2)    The call may have been delivered to the end user, with the user being informed of the presence of the request (it has certainly been delivered somewhere), however the precise nature of the situation is indicated by in-band information. This is the normal SIP interworking case with the PSTN. In this case I would suggest that the UAC should at least consider overriding any local generated tone with the contents of the media packets.

3)    The status is not known, but may be indicated by in-band information. This is the SIP interworking case with the PSTN where one of the interworking progress indicators has been delivered from the remote end."

The issue under discussion is how we represent the last two cases. I support both Mark and John in saying that we do need to distinguish all three to the end user, no matter how we do it.

As regards the early-media draft, I would propose putting some of the general text above in the general section. We then have the discussion of the two models, and the solution of each of the three cases needs to be presented for both models.

Currently the discussion seems to have focussed only on the solutions for the gateway model.

regards

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> Sent: 13 March 2003 17:54
> To: 'Elwell, John'; 'Mark Watson'
> Cc: [email-masked]'
> > From a QSIG perspective (I believe ISUP is similar) the 
> gateway DOES have
> a
> > indicator in QSIG that says that in-band media is present. 
> Also there is
> an
> > The third possibility does not have a satisfactory 
> solution. At present
> the
> > qsig2sip draft uses 180 for this and relies on the UAC 
> detecting early
> media

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Mar 2003 14:09:37 -0500

Some notes below.

Jon Peterson
NeuStar, Inc.

> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 10:17 AM
> To: 'Peterson, Jon'; 'Elwell, John'; 'Mark Watson'
> Cc: [email-masked]'
[snip]
>
> 2)    The call may have been delivered to the end user, with 
> the user being informed of the presence of the request (it 
> has certainly been delivered somewhere), however the precise 
> nature of the situation is indicated by in-band information. 
> This is the normal SIP interworking case with the PSTN. In 
> this case I would suggest that the UAC should at least 
> consider overriding any local generated tone with the 
> contents of the media packets.
> 
> 3)    The status is not known, but may be indicated by 
> in-band information. This is the SIP interworking case with 
> the PSTN where one of the interworking progress indicators 
> has been delivered from the remote end."
> 
> The issue under discussion is how we represent the last two 
> cases. I support both Mark and John in saying that we do need 
> to distinguish all three to the end user, no matter how we do it.
> 

What's the need to distinguish between 2 and 3? Both are sending in-band
media to the UAC which it should use, right? In both cases, the UAC nees to
listen to the media to learn the "precise nature of the situation." What
should the UAC do differently because condition 2 prevails, as opposed to
condition 3?

If the UAC receives media, it should be playing it. I don't think it's a
matter, as you describe in 2, that a UAC should merely consider playing it.
Given that, 2 and 3 seem to be identical. Making the UAC responsible for
deciding whether or not to play the media seems like the wrong model to me.
The gateway, which actually inspects and understands PSTN signaling, should
decide whether or not delivering media to the UAC is necessary.

> As regards the early-media draft, I would propose putting 
> some of the general text above in the general section. We 
> then have the discussion of the two models, and the solution 
> of each of the three cases needs to be presented for both models.
>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Mar 2003 20:01:39 -0000

See below

regards

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> Sent: 13 March 2003 19:10
> To: 'Drage, Keith (Keith)'; 'Elwell, John'; 'Mark Watson'
> Cc: [email-masked]'
I believe the distinction is that in case 2) it is appropriate to write "ringing" or "call delivered" or "waiting answer" or such like on the display of the UAC, or whatever additional indications are given to the user over and above the in-band tones/announcements. In case 3 it is not.

Given the number of different non-standard ring tones out there, the user may actually be relying on this extra information to know that the tone he is listening to is actually the ring tone he thinks it is, and not so other variety of busy tone. In one case he can terminate the call immediately, and in the other case he should cannot.

I think the issue here is that the user is essentially dialling a PSTN user in both these cases, and therefore it is reasonable to present to the user at the UAC the indications that he would expect to get back from the PSTN. 

In terms of the solution, presenting 183 in both cases 2 and 3 without some additional indication is misleading. Furthermore the tone/announcement in this case could well assume that the signalling level distinction available in the ISUP has been made available to the end user.

There is also the case of providing appropriate level of signalling to support the SHOULD discussed below.

> decide whether or not delivering media to the UAC is necessary.
As far as the UAC is concerned, in general I agree that if the UAC receives media, it should be playing it. I consider it unsafe to write a MUST here, and would default to a SHOULD, as there may be specific user interface considerations that make it incorrect or inappropriate.

I think it is also an assumption that all gateways can actually look at the in-band media and reliably detect what has been indicated. Any specification for early media must deal with both the cases, i.e. where the media gateway controller is not doing media detection, and that where it is. 

By the way, I suspect that this would need to be somewhat more sophisticated that just looking at the media stream at when the indication arrives; the nature of in-band information can change over time, and thus the nature of any appropriate indication to be given. There is also the problem of distinguishing noice (generated from transmission of the PSTN path over 20 miles of barbed wire) versus real signal.

Note also that while ITU-T specifies characteristics of these tones, PSTN equipment has a lifetime that tends to exceed the lifetime of a harmonised ITU specification of these tones. In practice there are 57 different varieties of all these tones out there, and there are laws of nature that state that the first ones you find in the field are the odd ones.

<snipped>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Mar 2003 05:52:33 -0500

Below.

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, March 13, 2003 12:02 PM
[snip]
> > What
> I believe the distinction is that in case 2) it is 
> appropriate to write "ringing" or "call delivered" or 
> "waiting answer" or such like on the display of the UAC, or 
> whatever additional indications are given to the user over 
> and above the in-band tones/announcements. In case 3 it is not.
> 

Once a SIP endpoint has gotten a provisional response from a PSTN gateway,
then from SIP's perspective the call has been delivered - we're essentially
interworking with a network that (we must conclude from this thread) is
unable to express its status out-of-band. The value of a visual display that
says "alerting" when the in-band media is saying something different (like
"queuing") is really questionable.

So what's the difference between what you show the user and what you tell
them? Many users have both working eyes and ears, I agree, but that doesn't
mean they'll benefit from seeing a visual display when what they need to
understand the state of the call isto hear the in-band media. Some UACs will
not support the visual display, just as some would not ordinarily play
in-band pre-answer media.

> Given the number of different non-standard ring tones out 
> there, the user may actually be relying on this extra 
> information to know that the tone he is listening to is 
> actually the ring tone he thinks it is, and not so other 
> variety of busy tone. In one case he can terminate the call 
> immediately, and in the other case he should cannot.
> 

Well, that's the first slightly credible argument I've heard on this point,
but I still don't find it satisfactory. If the tone were actually a busy
tone, the user wouldn't be hearing it - they'd be looking at a 486 response
code. This just speaks to the degree to which the PSTN in-band user
signaling paradigm is ingrained in this conversation, though. We need to
avoid using in-band status information in SIP at all, to the degree that we
can.

> I think the issue here is that the user is essentially 
> dialling a PSTN user in both these cases, and therefore it is 
> reasonable to present to the user at the UAC the indications 
> that he would expect to get back from the PSTN. 
> 

A PSTN user gets back an indication that the remote side is being alerted,
other than the in-band media? I don't see that displayed on my phone.

> In terms of the solution, presenting 183 in both cases 2 and 
> 3 without some additional indication is misleading. 
> Furthermore the tone/announcement in this case could well 
> assume that the signalling level distinction available in the 
> ISUP has been made available to the end user.
> 

It's the PSTN that is misleading, I think, not how we choose to map the
status codes. This is just like ISUP interworking with legacy CAS networks.
We could say that sending ACM is 'misleading' is ISUP-CAS interworking
cases, because in truth there may be a busy signal on the line. It's not
ISUP's fault, though - that's the only way it can contend with the CAS
network.

> There is also the case of providing appropriate level of 
> signalling to support the SHOULD discussed below.
> 
> As far as the UAC is concerned, in general I agree that if 
> the UAC receives media, it should be playing it. I consider 
> it unsafe to write a MUST here, and would default to a 
> SHOULD, as there may be specific user interface 
> considerations that make it incorrect or inappropriate.
> 

User interface considerations or UAC gateway operator policies, a more
likely case. If media arrives at a non-gateway UAC, and the UAC doesn't play
it for some reason, the UAC should be telling its user "pre-answer media is
arriving and it's trying to tell you something, but I don't know what"

> I think it is also an assumption that all gateways can 
> actually look at the in-band media and reliably detect what 
> has been indicated. Any specification for early media must 
> deal with both the cases, i.e. where the media gateway 
> controller is not doing media detection, and that where it is. 
> 

I have in no way suggested that in-band media can be mined by applications
for status information - just that it needs to be passed to the user. By
media detection, here, I'm just talking about detecting the condition that
some RTP has arrived, not inspecting the media programmatically to determine
its contents.

When you send an INVITE, you need to be prepared to start receiving media
immediately. This is essentially a requirement for the sort of media
detection I'm describing.

> By the way, I suspect that this would need to be somewhat 
> more sophisticated that just looking at the media stream at 
> when the indication arrives; the nature of in-band 
> information can change over time, and thus the nature of any 
> appropriate indication to be given. There is also the problem 
> of distinguishing noice (generated from transmission of the 
> PSTN path over 20 miles of barbed wire) versus real signal.
> 

Agreed that gateways are not in a position to understand what the media is.
My contention is only that if there is media, it has to be played for the
user.

> Note also that while ITU-T specifies characteristics of these 
> tones, PSTN equipment has a lifetime that tends to exceed the 
> lifetime of a harmonised ITU specification of these tones. In 
> practice there are 57 different varieties of all these tones 
> out there, and there are laws of nature that state that the 
> first ones you find in the field are the odd ones.
> 
> 
> <snipped>
>

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 14 Mar 2003 11:57:06 -0000

Jon,

You claimed that Keith's case 2 and case 3 were identical, but I do not see
how this can be.

In both cases, in-band media is available.

In case 2, it is known that the called user is being informed of the
presence of the request (at least if they are physically present, they are),
in case 3 this is now known. I do not see how any definition of identical
can be applied to these two cases.

A different claim would be that *for the purposes of the UAC* these cases
are identical, because all the UAC does in both cases is play the media.

But I think you are making too many assumptions about what the UAC may or
may not be able to use this information for. As a general rule, I would err
on the side of providing this information to the UAC, if only to assist in
future scenarios that we haven't yet thought of.

In terms of specific examples:
1) Keith mentioned that some ringing tones around the world are not
dissimilar from busy tones elsewhere in the world. It is entirely possible
for the user on a SIP terminal to end up hearing remotely generated busy
tone and you give an example of CAS interworking yourself - this would be
case 3. The additional indication available in Case 2 may give the user
additional confidence that what they are hearing really is a ring-tone.

2) In a forking case, the UAC may have early media arriving from multiple
sources. There is very little the UAC itself can tell about the call state
of these multiple calls - the media needs to be presented to a human user
for interpretation. I think in this case any additional information that the
UAC can be provided with about call state will be helpful. The user may also
find these indications useful in deciding which of several forks to listen
to first.

I think that whenever we have an indication that the user is being alerted
we should pass this to the UAC, using a 180 message. 183 should only be used
if we have no information. Indeed, this is what is specified in the ISUP
interworking work.

The problem remains of distinguishing at the SIP layer between 180 with no
media and 180 with media.

...Mark

> Sent: 14 March 2003 10:53
> To: 'Drage, Keith (Keith)'; 'Elwell, John'; Watson, Mark 
> [MOP:EP10:EXCH]
> Cc: [email-masked]'
> > > should the UAC do differently because condition 2 
> prevails, as opposed
> to
> > > condition 3?
> > > 
> > > matter, as you describe in 2, that a UAC should merely 
> consider playing
> it.
> > > deciding whether or not to play the media seems like the 
> wrong model to
> me.
> > > The gateway, which actually inspects and understands PSTN 
> signaling,
> should

---

From: Michael Hammer <[email-masked]>
Date: Fri, 14 Mar 2003 15:08:08 -0500

Jon,

I think I heard someone before say that they wanted to display a visual 
icon to indicate alerting, while playing the in-band media, but not have 
that over-written with locally injected ringing.

So, it may not be a case of signal alerting OR play inband media, but doing 
both.

What is the objection to providing signaling to indicate alerting state 
along with an indicator that locally injected audio should be suppressed?

Mike

At 11:52 PM 3/12/2003 -0500, Peterson, Jon wrote:
>I'm not sure how great the value of communicating the alerting state is 
>for SIP in other cases, though, when in-band media contains the real 
>indication of the state of the call. It's not as if that state information 
>can replace the in-band status information, right?

---

From: Michael Hammer <[email-masked]>
Date: Fri, 14 Mar 2003 15:50:37 -0500

Jon,

Doesn't the possibility of deaf users preclude the use of 183 from being 
used, as has been suggested, since they won't hear the locally injected 
ringback or the inband media?

Mike

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Mar 2003 16:01:13 -0500

inline.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, March 14, 2003 3:57 AM
To: 'Peterson, Jon'; 'Drage, Keith (Keith)'; 'Elwell, John'
Cc: [email-masked]'
Subject: RE: [Sipping] New version of the early media draft

Jon, 

<JFP> This is what I meant, yes. I hoped that would have been clear from the
context of the remainder of the paragraph in which my assertion appeared.
</JFP>

<JFP> True, I'm much more interested in getting people to recognize that
this is a pseudoproblem than in speculating about ways we could exploit
these signaling mechanics down the road. </JFP> 

<JFP> If you're not looking at a 486, you're not going to be looking at a
display that says "busy" either, right? In the CAS case, the gateway is
unable to ascertain status. So Case 3 is a wash either way. In Case 2, when
you could have a visual indicator telling you the difference between busy
and ringing, it would be much better if you just got the out-of-band
signaling than if you got the tones - largely because of your reason 2,
forking.

<JFP> In forking cases, it is categorically better to receive out-of-band
status information than in-band status information - this is one of my
primary motivators for avoiding in-band pre-answer status info. I would
greatly prefer it if we were interworking with a signaling protocol that is
capable of expressing its status out-of-band - but since we're apparently
not, we're not left with any option but to send the media. From a forking
composition perspective, I don't see any appreciable difference between
listening to ringtone, listening to dead air, or listening to any other
pre-answer media condition. All are equally likely not to be the branch that
is about to be answered. 

Look at it this way - if your position is that when the user sees 'alerting'
on their display for a particular branch, they therefore know that they
don't need to listen to the media that's being sent, this really begs the
question of why we're sending the media at all. But it's not safe to fail to
listen to media from any branch of a fork that is giving back a provisional
status. It would be radically preferable if media were only sent from (ISUP
'subscriber free') branches when an answer arose; otherwise the UAC's access
links could be swamped with early media that will never lead to a call, and
it will be impossible for the user to listen to any of the branches. Sending
180 with media is anathema to forking if this media is not necessary - and I
mean that in the strong sense 'necessary', as opposed to 'nice' or
'potentially useful for something we think up next year'. </JFP>

<JFP> Yes, I agree, if the user is just being alerted, a 180 should be sent
- but not any media. If on the other hand some other condition prevails that
is only expressed in-band, we need to send that media. 'Alerting' doesn't
carry the full of sense of the state of the call; if it did, there would be
no need for in-band media. </JFP>

<JFP> I don't think you've successfully made the case that the UAC does not
need to do media detection anyway, to handle cases in which post-answer
media arrives before 200 OK. If for some reason that wasn't true, then
perhaps you could argue that media detection is too hard in decomposed
architectures for us to require it on the grounds of early media cases. But
given that there is a pre-existing requirement for all UAs to do this sort
of media detection, I don't think there's any need for SIP layer
disambiguation of this. 

But all this is indicative of separable though related issues:

1) Whether or not we recommend that gateway UASs send media when they
receive an ACM coded 'subscriber free' without an indication of in-band
status information;

2) Whether or not gateway UASs send 183 in all cases where pre-answer media
is to be sent; and

3) Whether or not the UAC needs to detect media regardless of the
provisional status of the call.

As you might guess, I would prefer the answers 1) don't send media, 2) send
183, 3) always detect. 

</JFP>.

...Mark 

> > From: Drage, Keith (Keith) [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Mar 2003 16:22:58 -0500

Just as a summary, the argument has been that the motivations below are
orthogonal to the presence of some indicator in SIP that tells the UAC to
suppress locally-generated ringing. If the gateway UAS sends pre-answer
media, the UAC should play it (with the caveat the UAS SHOULD NOT send media
if it can portray the status of the call out-of-band). There is no need for
any indicator here; the UAS gateway can express its preference for the use
of media by sending RTP or not. The ensuing contentions focused on whether
or not the UAC could be expected to detect the presence of RTP - I've argued
that it can. In short, the argument is that this indicator adds nothing to
SIP that we don't have already.

Mr. Camarillo also suggested that a UAC could delay generating local
ringback by a second or so after receiving a 180 to wait for UAS media to
arrive. I have a hard time seeing why this doesn't do the trick.

Jon Peterson
NeuStar, Inc.

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Friday, March 14, 2003 12:08 PM
> To: Peterson, Jon
> Cc: 'Mark Watson'; [email-masked]'

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 14 Mar 2003 16:50:49 -0500

They are proverbially out of luck in the CAS interworking case, no? Again,
it's not our fault that ISUP doesn't present its status accurately
out-of-band.

Anyway, this is speaking to a pair of separable issues. Whether or not we
send pre-answer media with a 180 is separable from whether or not we need
some SIP-layer indication that we are doing so. Personally, I think we're in
a bad position to deal with cases where ISUP provides valuable in-band
information but doesn't tell us so in the encoding of an ACM, and I don't
think it is reasonable for us to always send pre-answer media on receipt of
ACM. But this is a separate issue. 

If we send 180, and subsequently send media, we could very well be deceiving
a deaf user (or a user whose UA simply doesn't render pre-answer media) into
thinking that 'alerting' tells the whole story. But if 'alerting' told the
whole story, there'd be no need to send any pre-answer media to accompany
it. This is the paradox I keep hearing - people want to see an indicator
that says "alerting" and play early media, but they simultaneously
acknowledge that the reason they want the early media is because it
qualifies the alerting state in some fashion.  How valuable is the
"alerting" state at the UAC, then?

I would be more sympathetic to this view if the 'alerting' state had some
specific semantics at the UAC pointed out in RFC3261 that differentiated
'180 received' from '183 received' or other provisional states - but it
doesn't. There's nothing magical about receiving a 180 response. It's been
suggested that this is valuable for forking composition, but in my
estimation, if there's in-band media associated with a provisional branch of
a fork, you need to evaluate that media, not the status code (again,
otherwise, why send the media at all?). Some sort of 180 indicator that
suppresses local ringback doesn't help you either way with any of these
problems.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, March 14, 2003 12:51 PM
> To: Peterson, Jon
> Cc: 'Drage, Keith (Keith)'; 'Elwell, John'; 'Mark Watson';
> [email-masked]'

---

From: Michael Hammer <[email-masked]>
Date: Fri, 14 Mar 2003 17:20:31 -0500

Jon,

Just noting the implications.

You equate the receipt of RTP of any kind with the presence of meaningful 
audio to listen to.  (Caveat that as being any RTP except silence 
suppression RTP.)

Your current approach places the burden on the GW to determine if there is 
meaningful audio and to suppress RTP until something meaningful is 
detected.  The GW could also use the "in-band media" indication (if it is 
present in the OBCI) to make the decision to send RTP.

Else, if the GW simply cuts-through and the end-switch doesn't provide 
tones or announcements, the Camarillo suggestion would lead to no ringing 
injected and the user listening to dead air, but, perhaps a visual 
indication.  At least he gets the same experience as the deaf person. :)

Mike

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sat, 29 Mar 2003 01:03:35 -0000

For information, I think pretty well all the proponents of needing to distinguish three different cases of information provision do not really care how the coding distinguishes those three cases. 

The main person who keeps returning the discussion to particular encodings is Jon Peterson, who consistently argues that there are not three cases.

And yes we do need to agree codings at the end, but one step at a time.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> From: Al Varney [mailto:[email-masked]]
> Sent: 28 March 2003 03:05
> To: Peterson, Jon; [email-masked]
> I haven't seen any "results" from the Early-Media Ad-Hoc (if 
> it was held), 
> so I'll toss out something I would have stated had I been there....
> 
> At 04:50 PM 3/14/03 -0500, Peterson, Jon wrote:
>     Absolutely true.  Even more so for MF or DP trunks off a SIP 
> gateway.  You can't fix the past, but you do have to worry 
> about embedded base.
> 
>     OK -- so folks want "alerting" and early media (as in ISUP), 
> particularly for cases when interworking with the old PSTN.  
> Then why add a 
> SIP-early-media indicator to 180?  Instead, why not add an "alerting" 
> indicator to 183 -- which maps rather well to ISUP ACM 
> practice (ACM always 
> implies in-band media in the backward direction, and it 
> sometimes indicates 
> 'user free'/alerting).  It also maps to/from ISDN in an 
> obvious manner.
> 
>     This leaves 180 untarnished as an explicit "alerting and 
> no intended 
> early media" indicator, and local ringback could always be 
> generated.  Any 
> pre-200 media could be assumed to have gotten ahead of SIP 
> messaging, and 
> it could be cut through to the caller either immediately or 
> after a short 
> delay.
> 
>     Adding a new indicator to 183 for "user being alerted" is 
> backward 
> compatible, since RTP media would be there even if the new 
> indicator was 
> ignored.  And for cases where the indicator WAS recognized, a 
> display or 
> forking treatment similar to that for 180 could be used.  
> Some UA could 
> even generate local ringback if it really, really wanted to do so.
> 
>     The major advantage would be better compatibility with SIP-ISUP 
> gateways for interworking, and the preservation of 180 for 
> cases where 
> SIP-aware signaling was used end-to-end.  Or where gateways 
> that could 
> distinguish true alerting cases (a gateway with 
> directly-connected lines, 
> for example, always knows the true alerting state of a 
> terminal).  Over 
> time, SIP-to-SIP calls would all tend to use 180, and the old 
> PSTN behavior 
> would be contained within 183 handling (where it already has 
> to exist).
> 
>     (While adding indicators to 183, would it also be useful 
> to have a "SIP 
> not used all-the-way" indicator that indicates interworking 
> to non-SIP 
> protocols?   Or would a UA always behave the same for 
> gateways sending 183 
> and called-UAs sending 183?)
> 
>     View this as a comment thrown out into a late-night 
> Ad-Hoc session.
> 
> Al Varney
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 31 Mar 2003 15:13:00 -0500

Well, I would argue that we haven't blurred the line in our approach - we're
just repeating what RFC3261 tells you to do. Based on the "you must be
prepared to receive media" after INVITE text and the "MAY generate local
ringback" after 180 text, it would seem that the alerting state entails that
you MAY generate local ringback unless you receive media. The blurring, if
any, occurred there. I don't really consider it blurring, though, because
sending an INVITE at all essentially signals at the application layer "I can
be sent media now". No response mechanic seems to be required to supplement
that application-layer indication. 

And actually, I'm not sure that the distinction between 'meaningful' RTP and
silence is actually a requirement. Earlier in this thread, in fact, somebody
expressed that when silence is sent over RTP, silence is what the UAC should
render (i.e. that playing local ringback over silence could in some cases be
the wrong behavior). I would second Gonzalo's call for use cases related to
these scenarios. Since (as many in this thread have argued) it is impossible
for a gateway UAS to know whether or not there is valuable information
in-band, it isn't clear when it would be appropriate for the UAS gateway to
say that the RTP it is sending is 'meaningful', anyway.

Jon Peterson
NeuStar, Inc.

> Sent: Monday, March 31, 2003 7:45 AM
> To: Bob Penfield
> Cc: [email-masked]
> Bob and Jon,
> The only problem with this approach is that you have blurred the line 
> between signaling and bearer.  If 180 means alerting, then 
> the UAC should 
> provide alerting until the 200 OK or some other signaling 
> removes the UAC 
> from that state.  But, you have the bearer stream removing 
> the UAC from the 
> alerting state based on the receipt of RTP.
> 
> If you follow that approach, it should be clarified that not 
> just any RTP, 
> but RTP with some meaningful media would be of value.  But, 
> this puts the 
> burden on the UAC to determine whether highly ambiguous media means 
> something or is just noise or silence.
> 
> A 180 meaning alerting with a suppression indication to 
> supersede local 
> alerting with inband alerting, or a 183 with an explicit 
> indication of "do 
> local alerting" would be a clear SIGNALING mechanism.
> 
> The only responses I recall getting to the following scenario is "GWs 
> shouldn't do that" and "in MOST cases the destination EO will supply 
> ringing inband anyway":
> 
> A GW responds with 180 and backward cut-through of RTP 
> playing dead air.
> The UAC plays the dead air because it got there before the 
> 180 (and to 
> avoid clipping).
> This could go on for several seconds or however long it takes 
> the UAS to 
> pick up.
> 
> But, if this were to occur, I guess that is OK for the SIP 
> UAC user.  This 
> seems to be a minor case, so don't worry about it.
> 
> Mike
> 
> 
> At 10:42 AM 3/29/2003 -0500, Bob Penfield wrote:
> 
> >----- Original Message -----
> >From: "Peterson, Jon" <[email-masked]>
> ><snip>
> > >
> > > Another problem is the idea that SIP has some special 
> 'alerting' state
> > > comparable to that of ISUP, and that if 180 is not received, this
> >'alerting'
> > > state will not be reached. I'm not sure what UAC behavior 
> the advocates of
> > > this position imagine will result from 180 that will not 
> result from 183.
> >If
> > > anyone can substantiate this for me, preferably with some 
> citation from
> > > RFC3261, that would go a long way towards putting this 
> issue to rest.
> > >
> >
> >Even the RFC 3261 definition of 180 uses the term "alert".
> >180 is not the same as 183 and UAs (e.g. SIP Phones) do treat them
> >differently in order to provide the best user experience.
> >
> >RFC 3261 defines 180 as:
> >
> >     The UA receiving the INVITE is trying to alert the user.
> >     This response MAY be used to initiate local ringback.
> >
> >where 183 is defined as:
> >
> >    The 183 (Session Progress) response is used to convey information
> >    about the progress of the call that is not otherwise classified.
> >
> >I'm not saying that 180 means exactly the same thing as 
> alerting in ISUP,
> >but when the UAC receives a 180, it can reasonably believe 
> that the call has
> >progressed to the point that it can render "Ringing" to the 
> user whether
> >that is by displaying something on a screen (with or without 
> inband media),
> >flash a light, or playing local ringback in the absence of 
> inband media. No
> >such assumption can be made when a 183 response is received.
> >
> >Regardless of the type of UAS or interworking protocol, if a UAS can
> >determine that the call has reached a state where it (or an 
> endpoint at the
> >other side of the non-SIP network) is "trying to alert the 
> user", it should
> >send 180. The response codes 180, 181, and 182 do have 
> specific meaning in
> >SIP and whenever a reasonable mapping from states in a 
> interworking protocol
> >can be made, they should be.
> >
> >BTW, I do support your position that no additional indication of the
> >presence or absence of early media is required in SIP 
> signaling. If UAC
> >receives media, it should play it.
> >
> >cheers,
> >(-:bob
> >
> >
> >

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 31 Mar 2003 17:54:48 -0800

> From: Bob Penfield [mailto:[email-masked]] 
> Sent: Saturday, March 29, 2003 07:43
> To: [email-masked]
> BTW, I do support your position that no additional indication 
> of the presence or absence of early media is required in SIP 
> signaling. If UAC receives media, it should play it.

This is actually the biggest problem I personnally have with the assumptions
on early
media. 

I do not think that this rule of "play media when you receive it" is
implementable
generally, but only in a few very selected cases.

There are a number of scenarios that I think are problematic:

1 - 180 with SDP

If a 180 is sent with an SDP (for the purpose of telling the far end what
codec is picked), the called UA the shouldn't be sending silence in
RTP because, according to the current rules, the calling UA would stop the
locally generated ringing to play the silence packet. (Doing some heavy duty
DSP parsing to detect if the media is silence or not seems hardly efficient,
nor reliable).

A side effect of this is that if there is a NAT/Firewall involved, it is
quite
possible that the binding will expire and the address in the SDP will be
invalid
or the media will be blocked upon answer. 

If an indication was present to indicate if the in-band media was meant to
be
replacing the locally generated tone, we wouldn't have this problem (i.e.,
one
could send packets in-band to keep the binding alive).

2 - Sequential calling

In a sequential calling scenario such as call call forwarding no answer
(section 2.8
of the SIP services examples Internet Draft). Suppose the following:

   Alice            Proxy         User B1             User B2
          |                |              |                   |
          |    INVITE F1   |              |                   |
          |--------------->|   INVITE F2  |                   |
          |(100 Trying) F3 |------------->|                   |
          |<---------------|183 ProgressF4|                   |  SDP is
included with 183
          | 183 Progress F5|<-------------|                   |
          |<---------------|              |                   |
          |   Both way RTP Established    |                   |
In-band   |<=============================>|                   |
ringing   |                 Request Timeout                   |
          |                |              |                   |
          |                |   CANCEL F6  |                   |
          |                |------------->|                   |
          |                |   200 OK F7  |                   |
          |                |<-------------|                   |
          |                |     487 F8   |                   |
          |                |<-------------|                   |
          |                |     ACK F9   |                   |
          |                |------------->|                   |
          |                |              |    INVITE F10     |
          |                |--------------------------------->|
          |                |              | 180 Ringing F11   |
          | 180 Ringing F12|<---------------------------------|
          |<---------------|              |                   |

The problem with this scenario is that presumably, upon receipt of 180,
the UA needs to figure out somehow that it should be playing the locally 
generated alerting. This would imply that upon receipt of the 180, the
calling
UA would start a timer and wait until it expires to play the locally
generate
tone. Since ringing is composed of tone-silence-tone, the timer will have to
be
relatively long. While the UA can detect that the 180 is a different dialog
than
the 183, it can not know for sure that the first dialog had been cancelled
because it could be forking: it has to rely on the media.

While this is technically feasible, it imposes a big unecessary burden on
the client, especially if it is a thin client. On a "decomposed"
architecture
(like a stimulus MGCP phone), it makes for pretty nasty signalling, if
possible 
at all.

PS: I'm not saying that the in-band media is necessarily useful in this
scenario. I'm
just pointing out the difficulties of the "play media when received" mantra.

3 - Forking

As expected, this is the worst.

   Alice            Proxy         User B1             User B2
          |                |              |                   |
          |    INVITE F1   |              |                   |
          |--------------->|   INVITE F2  |                   |
          |(100 Trying) F3 |------------->|                   |
          |<---------------|183 ProgressF4|                   |  SDP is
included with 183
          | 183 Progress F5|<-------------|                   |
          |<---------------|              |                   |
          |   Both way RTP Established    |                   |
In-band   |<=============================>|                   |
ringing   |                |              |                   |
          |                |              |    INVITE F10     |
          |                |--------------------------------->|
          |                |              | 180 Ringing F11   |
Locally   | 180 Ringing F12|<---------------------------------|
generated |<---------------|              |      200 OK F13   |
ringing   |                |<---------------------------------|

There are of course multiple permutations, such as 2 183s, 2 180s, 1 183
followed
by a 180, or 1 180 followed by a 183. And then there might be more than 2
UAs being 
forked-to, so the problem can be really bad.

There is no way to associate a specific RTP stream with a specific dialog.
The current
draft hints that one UA could randomly play one stream and mute the others
(which will be
very troublesome if the other UA doesn't support UPDATE). This is not
satisfactory and
would result in garbage being played to the user. For this reason, I believe
that the only 
reasonable approach in this scenario is to let the 180 override the 183s (if
there is
a 180) and ignore all media. This will of course result that there might be
some level of
clipping on answer (I have yet to see a network where this is a problem). If
there is no
180, one could play one of the random stream (although I don't think it is
particulary 
useful), or play some default "progress" tone that would indicate to the
user that the
call is forked.

One of the reason I think the 180 indication is more useful than the
183-with-in-band-
media is that if the in-band from the 183 is saying "This number has been
disconnected,
please hangup" and then a 200 OK comes back (for the 180) wich connects the
call, the user 
will be very disoriented (realistically, he will probably have hung-up
anyways). The other
way around (playing the local ringback) will at least keep the user on-line
in case somebody
does answer. The point is that since we can't associate a particular media
stream with
the SIP signalling, we can't just "play the media" when there is multiple
dialogs.

Many people seem to think that "this is forking, it is trouble, don't use
it, bla bla bla".
Unfortunately, it is extremely useful. Also, it happens all the time today
when parallel 
calling is done (different names exists for it, including "multiple
appearances", or 
"parallel hunt groups"). If SIP can not properly ring multiple agents in a
pool in parallel, 
it won't be terribly useful.

The only alternative is to wait for the 200 OK to connect media. Despite the
claims of
this introducing clipping on answer, I haven't seen this to be a problem on
existing VoIP 
systems (i.e., the time it takes the human to answer is longer than the
interval during 
which there could be clipping).  

One added difficulty is that from the calling UA's perspective, we can't
distinguish easily 
between case 2 and 3.

---------

My conclusion is that when there are multiple dialogs, we can not honor
media at the 
calling UA and have to rely on the SIP provisional responses exclusively.
This goes against
the "play media as soon as you receive it" principle.

Also, since parallel calling (i.e., forking) is extremely common in call
centers and
within enterprises, it greatly limits the applicability of early media, or
indeed ringing
2 phones in a private residence. My personal opinion is that it is really
limited to TDM 
gateway interworking, and only when there is no forking involved or multiple
dialog 
involved.

Again, I don't believe that the "in-band alerting" indication necessarily
solves this (although
it does help in a few cases). I'm just pointing out that the play in-band
RTP even if 180 is 
received is not generally a good idea. The reason I am sending this email in
the context
of this discussion on the in-band ringing indication is that this idea that
playing in-band
media automatically helps keeps on re-surfacing.

François Audet