Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re -invite response]

From: "Keith Robinson" <[email-masked]>
Date: Wed, 6 Dec 2000 15:10:11 +0000

The extrapolation of the argument leads to the behaviour defined in section B.4
and B.6 of
rfc2543bis-02  whereby the caller sends an SDP with no media lines and null
connection addresses
 (0.0.0.0) if it doesn't yet have sufficient information to supply a 'full'
description. As previously mentioned,
no media lines is acceptable as per rfc2327 and the connection address of
0.0.0.0 should have no
special meaning to the receiver of the SDP message .

I prefer this model because it leads to cleaner implementations where new media
control
protocols can be adopted without having to unknit existing media control
functions from
session control  functions.

Obviously, the adoption of this model may lead to a period of special case
handling for
backwards compatibility but , IMO, the gain of future proofing implementations
outweighs
this penalty.

It seems that the text in rfc2543bis-02 sect. 4.2.1 allowing a caller to send
either no SDP
or an SDP contaning no m lines to mean the same thing has caused the confusion;
perhaps
the paragraph in B.4 (which does not suggest sending no SDP)  should be put here
instead.

Regards,

K. Robinson

"Henning G. Schulzrinne" <[email-masked]> on 06/12/2000 13:58:16

                                                              

 To:      Keith Robinson/MAIN/MC1@MCMAIN                      
                                                              
 cc:      Sean Olson <[email-masked]>, Rick Workman  
          <[email-masked]>, Jonathan Rosenberg   
          <[email-masked]>, Brett Tate               
          <[email-masked]>, Sip Mail List                
          <[email-masked]>                           

 Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC   
          and the re-invite  response]                        

The "no SDP - no change" model has the advantage that it works for ACK
(where there usually is no SDP) and various 1xx responses, in addition
to INVITE and re-INVITE. Even in this model, sending an INVITE or
200-INVITE without SDP is probably a bad idea since it prevents
stateless recovery from earlier failures.

The "no SDP - no media" model is probably closer to what people are
implementing right now, but only holds for INVITE and re-INVITE.
--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Keith Robinson" <[email-masked]>
Date: Wed, 6 Dec 2000 16:38:13 +0000

> An idempotent operation is one in which *identical* requests
> can be applied successively with no subsequent effects.
>
> If you send an initial INVITE with SDP, then a re-INVITE with
> no SDP, these are not idempotent.  This was my point.
>

>>But I don't consider these identical requests - one has SDP and the other
>>doesn't.

Moreover, an INVITE and any subsequent re-INVITES can never be considered
identical as at least the CSEQ value will be different in each.

So, it seems that the argument relates to the idempotence in relation to the
control of the media and the semantics of receiving no SDP in an INVITE. If
we choose the model of no SDP - no change then an INVITE with SDP followed
by a re-INVITE with no SDP, in the context of the media, leads to idempotent
behaviour; if we choose no SDP - no media then an INVITE with no SDP followed by
a re-INVITE with no SDP, in the context of media, leads to idempotent behaviour.
whichever model we choose we can define idempotent behaviour for it, so the
debate is which model to choose. As previously stated, IMO the no SDP - no
change model will lead to cleaner implementations.

"Rick Workman" <[email-masked]> on 06/12/2000 15:38:43

                                                              

 To:      Sean Olson <[email-masked]>                
                                                              
 cc:      Sip Mail List <[email-masked]>(bcc: Keith  
          Robinson/MAIN/MC1)                                  

Sean Olson wrote:

> An idempotent operation is one in which *identical* requests
> can be applied successively with no subsequent effects.
>
> If you send an initial INVITE with SDP, then a re-INVITE with
> no SDP, these are not idempotent.  This was my point.
>

But I don't consider these identical requests - one has SDP and the other
doesn't.

>
> Of course, sending an INVITE with no SDP, followed by
> another INVITE with no SDP is consistent.
>
> /sean
>
> Rick Workman wrote:
>
> > Not sure I understand your point. An idempotent operation can be applied
> > more than once with no subsequent effect after the first application.. The
> > semantics I'm supporting is no SDP means no change to the media state.
> >
> > For the first INVITE, there's no media prior to the transaction, so there's
> > no change. A re-INVITE with no SDP and prior media results in no change -
> > prior media doesn't go away. Feels consistent to me.
> >
> > Rick
> >
> > Sean Olson wrote:
> >
> > > How can a request which differs in something as vital as the session
> > > description (SDP)
> > > be considered idempotent? If you don't want to indicate a change, then
> > > don't change
> > > the request. Whatever semantics you associate with no SDP should be
> > > consistently
> > > applied across INVITEs and re-INVITEs. Or perhaps I don't understand
> > > your
> > > comments(?)
> > >
> > > /sean
> > > --
> > > Sean Olson <[email-masked]>
> > >
> > > Rick Workman wrote:
> > >
> > > > As per a previous discussion on this list, I favour the sematics that
> > > > says no SDP means "no change". I may be misunderstanding something,
> > > > but it's hard to imagine a more idempotent operation than one which
> > > > does nothing. There seem to be three proposals I've seen so far which
> > > > attach some meaning to no SDP content:
> >