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

From: "Francois Audet" <[email-masked]>
Date: Thu, 5 Dec 2002 13:52:29 -0800

> I think Mr. Camarillo is talking about something else in the 
> passage below, a case in which there is some disjointed media 
> (media unrelated to the call, like an announcement or service 
> message) that is played before the actual media for the call 
> is cut-through. While your scenario is also valid, I think we 
> need to consider these two scenarios separately. He's talking 
> about a case where some disjointed media (not the callee 
> answering the phone) is sent before any audio media from the 
> actual callee - your case is where media from the callee 
> arrives before the 200 OK.

Right, this is a good suggestion (to document separately the disjointed
media versus the not-disjointed media). Gonzallo's Figure 1 ane 2 are
more looking into the disjointed media case, while the ones that Bill and I
wrote were for the non-disjointed case.

I would think that the disjointed media case could look like this
(which is as per RFC 3311). I'm assuming SDP B is for the announcement
is SDP B' is for the answerer.

          A                                            B                  
                                                                          
          |                                            |                  
          |---------------(1) INVITE    -------------->|                  
          |                   SDP A, a=sendrecv        |                  
          |<------(2) 183 Session Progress-------------|                  
          |           SDP B, a=sendrecv                |                  
          |-----------------(3) PRACK----------------->|                  
          |                                            |                  
          |<-----------(4) 200 OK (PRACK)--------------|                  
          |  *                                         |                  
          | ****************************************** |                  
          |*     User B will be with you shortly     * |                  
          | ****************************************** |                  
          |  *                                         |                  
          |<------------(5) 180 Ringing----------------|  
          |  *                                         |                  
          | ****************************************** |                  
          |*     OPTIONAL INBAND RINGBACK            * |                  
          | ****************************************** |                  
          |  *                                         |

          |-----------------(6) PRACK----------------->|                  
          |                                            |                  
          |<-----------(7) 200 OK (PRACK)--------------|                  
          |                                            |                  
          |<--------------(8) UPDATE    ---------------|                  
          |                   SDP B', a=sendrecv       |                  
          |                                            |

          |------------(10) 200 OK (UPDATE)----------->|    
          |                   SDP A, a=sendrecv        |              
          |                                            |
          |<-----------(11) 200 OK (INVITE)------------|                  
          |                                            |

          |-----------------(9) ACK------------------->|                  
          |                                            |
          |  *                                      *  |                  
          | ****************************************** |                  
          |*        Bi-directional conversation       *|                  
          | ****************************************** |                  
          |  *                                      *  |                  
          |                                            |                  

Note that in this flow, there might be in-band ringing provided after the
message
or not. This is independent of the sending of 180. A can play locally
generated
tones if there is no in-band ringback received (or not if it doesn't need it
because for 
example it is a terminal with a GUI). It doesn't influence the call flow
which is 
independent from the presence of media.

The main difference with Gonzallo's proposal is that it doesn't attempt to
explicitely tell the
other end of turning off-and-on the media flow based on a=inactive/sendonly
tags.

Does this make any sense?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Dec 2002 17:36:11 -0500

OK, lets assume your call flow, and that A wants to generate local 
ringback after a 180 if there is nothing to play from the negotiated 
media stream.

Lets further assume that B, after sending the 180, doesn't want to 
generate ringback, and in fact doesn't want to send anything until it 
sends the 200.

Based on your callflow, there is no offer/answer exchange initiated at 
(5), so the media stream is still open. Presumably B must send RTCP 
packets, but won't be sending any RTP packets. How is A to decide 
whether the absence of RTP packets is merely an indication of 
intentional silence after earlier speach, which should suppress locally 
generated ringback, or an indication that there is no longer an intent 
to send, where enabling the ringback is appropriate?

(This is different than the case of media that simply precedes a 200, 
where the first appearance of RTCP packets is concurrent with the early 
speech.)

	Paul

Francois Audet wrote:
>           |  *                                         
> |                                
>           |                                            
> |                      
>           |                                            
> |                         
> Note that in this flow, there might be in-band ringing provided after 
> the message
> tones if there is no in-band ringback received (or not if it doesn't 
> need it because for
> The main difference with Gonzallo's proposal is that it doesn't attempt 
> to explicitely tell the
> other end of turning off-and-on the media flow based on 
> a=inactive/sendonly tags.
> 

_______________________________________________
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