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

From: "Mark Watson" <[email-masked]>
Date: Wed, 5 Mar 2003 15:00:03 -0000

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

> -----Original Message-----
> 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
> 
> 
> 
> -----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,
> 
> 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
> > 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:[email-masked]]
> > Sent: Monday, February 10, 2003 5: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-m
edia-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

-- 
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: Gonzalo Camarillo <[email-masked]>
Date: Wed, 05 Mar 2003 20:21:44 +0200

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:
> 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.
> 
> 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
> 
> http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-media-01.txt
> 
> >