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

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 11 Mar 2003 09:36:04 -0600

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

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

Folks,

let me try to summarize our discussions so far and propose a way
forward.

Richard and Mark are asking for an indicator to be placed in 180
(Ringing) responses that indicates whether or not there will be early
media. The idea (and the gain we would get) is that this indicator would
allow us to avoid implementing media detection (especially important in
decomposed gateways).

However, not implementing media detection have some problems when the
call is answered: a UAC is generating local ringback, and the callee
picks up. The first RTP packets arrive to the UAC before the 200 OK for
the INVITE. The UAC can either discard the media until it gets the 200
OK or mix it with the local ringback it was generating until the 200 OK
stops it (the local ringback).

I had claimed that, because of the issue above, you want to implement
media detection anyway. However, Mark has claimed that he knows of some
scenarios where the media gateway will not let any media in until the
200 OK is received. And for those scenarios, a "there is media coming"
indication would be useful for the UAC.

(This is the summary of our discussions so far... below comes my
proposal to move forward)

But we have already such an indication. We do not need to develop any
new parameter. In fact, such an indication was proposed in the first
version of the draft. However, we removed it because of the media
clipping problem. The indication is the direction attribute of SDP.

When you send a 180 (Ringing), you send an answer setting the audio
stream to inactive. When the UAS sends the 200 OK, it sends an UPDATE in
parallel with the 200 OK setting the audio stream to sendrecv again.

The delay is the same as the one achieved with a flag (or an empty
Alert-Info), since the messages are sent in parallel. The number of
bytes is probably higher, but I would not worry about it. And we have
the advantage of not having to implement any new parameter that would
not be understood by old UAs.

Does this meet your requirements?

Below you have a call flow with an announcement followed by local
ringback (180 + inactive stream) and followed by the answer of the call.

          |                                           
|                         |---------------(1) INVITE   
-------------->|                         |                  
a=sendrecv               |               
          |<------(2) 183 Session
Progress-------------|                         |          
a=sendonly                       |                        
|-----------------(3) PRACK----------------->|                        
|                                            |                        
|<-----------(4) 200 OK (PRACK)--------------|                        
|  *                                         |                         |
****************************************** |                        
|*     User B will be with you shortly     * |                         |
****************************************** |                         | 
*                                         |                        
|<------------(5) 180 Ringing----------------|                        
|                                            |                        
|<--------------(6) UPDATE    ---------------|                        
|                   a=inactive               |                        
|                                            |                        
|-------------(7) PRACK--------------------->|                        
|-------------(8) 200 OK (UPDATE)----------->|                        
|                 a=inactive                 |                        
|<-----------(9) 200 OK (PRACK)--------------|                        
|                                            |                        
|                                            |                        
|                                            |                        
|<----------(10) 200 OK (INVITE)-------------|                        
|                                            |                        
|<-------------(11) UPDATE    ---------------|                        
|                   a=sendrecv               |                        
|                                            |                        
|-----------------(12) ACK------------------>|                        
|                                            |                        
|------------(13) 200 OK (UPDATE)----------->|                        
|                 a=sendrecv                 |                        
|  *                                      *  |                         |
****************************************** |                        
|*        Bi-directional conversation       *|                         |
****************************************** |                         | 
*                                      *  |                        
|                                            |               

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, 12 Mar 2003 09:10:30 +0200

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