Subject: RE: [SIP] 3PCC and the re-invite response

From: Igor Slepchin <[email-masked]>
Date: Fri, 1 Dec 2000 15:31:15 -0500

I don't see how re-INVITE with no SDP helps to solve the SDP exchange loop
problem (or nearly any other problem). The UA is equally likely (or, rather,
unlikely) to randomly change media ports in 200OK response to the re-INVITE
with or without the media. In fact, re-INVITE with no media only exacerbates
the problem since the 3pcc now cannot send the ACK until the media is
renegotiated with the other party.

INVITEs with no media were introduced as a hack to provide interoperability
with H.323v1 so instead of hacking the hack I'd rather require that UA not
change media ports on a whim (i.e., never change the port on an "m=" line
unless you also change the codec or IP address). I think it's a reasonable
requirement and suspect that no sane existing UA would do this anyway.

So the general question is what are the situations when ACK with SDP is
required? If none are found, I'd suggest that the spec be more specific
about the fact this mechanism should only be used for h.323v1
interoperability and nothing else (given the fact that it's too late to just
strike it out).

---
Igor Slepchin

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Thursday, November 30, 2000 1:41 PM
> To: Jonathan Rosenberg; 'Gethin Liddell'; Sip Mail List
> Subject: Re: [SIP] 3PCC and the re-invite response
> 
> 
> BroadSoft uses the re-INVITE without SDP and ACK
> with SDP to avoid the possibility of both sides getting
> into the mentioned SDP change loop.
> 
> This is why BroadSoft would like to keep the use of
> ACK with SDP at least with regard to re-INVITEs.
> 
> This is also why it would be nice for rfc2543 to mention
> that an INVITE without SDP can be used as a request
> to pull the receiver off of hold.  This has been discussed
> at the backoff and on the news group, but is currently
> not explicitly mentioned in rfc2543.
> 
> ----- Original Message -----
> From: Jonathan Rosenberg <[email-masked]>
> To: 'Gethin Liddell' <[email-masked]>; Sip Mail List
> <[email-masked]>
> Sent: Thursday, November 30, 2000 11:23 AM
> Subject: RE: [SIP] 3PCC and the re-invite response
> 
> 
> > This is a recognized problem. Note the following section in 
> the document:
> >
> >    In addition, note that in Figure 1, the controller sends 
> a re-INVITE
> >    to A with the SDP from B. The response to this re-INVITE 
> is a 200 OK
> >    that contains "SDP A". If the SDP returned in the 
> re-INVITE response
> >    were not the same, the controller would need to initiate 
> a re-INVITE
> >    to B with that new SDP. This means that a UA which returns a
> >
> >
> >
> > Rosenberg/Peterson/Schulzrinne/Camarillo                    
>  [Page 12]
> >
> > Internet Draft                    3pcc                 
> November 22, 2000
> >
> >
> >    different SDP (for example, by changing the ports) in 
> the response to
> >    every re-INVITE will trigger an infinite re-INVITE loop from the
> >    controller to each controller entity. As such, it is STRONGLY
> >    RECOMMENDED that if a re-INVITE does not require a UAS 
> to modify the
> >    formulation of the SDP description for a specific stream in the
> >    response, the SDP description of that stream in the 
> response MUST be
> >    the same. In other words, if a UA was in a session with a single
> >    stream, using codec A, and it received a re-INVITE 
> modifying the port
> >    to send to, the re-INVITE response MUST be the same as 
> it was to the
> >    initial request. However, if the re-INVITE forces the 
> UAS to change
> >    codecs, it is acceptable in that case to use a different 
> port in the
> >    SDP in the response.
> >
> >
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> >
> > > -----Original Message-----
> > > From: Gethin Liddell [mailto:[email-masked]]
> > > Sent: Thursday, November 30, 2000 7:19 AM
> > > To: Sip Mail List
> > > Subject: [SIP] 3PCC and the re-invite response
> > >
> > >
> > >
> > > people,
> > >
> > > i'm slightly concerened (maybe un-justifably) about the re-invite
> > > working of the 3PCC draft.
> > >
> > > my concern is that it is possible (is it not?) for the user agent
> > > receiving the re-invite to change its SDP settings in its 
> response as
> > > follows:
> > >
> > >  A                Controller            B
> > >  |  INV held SDP     |                  |
> > >  |<------------------|                  |
> > >  |                   |                  |
> > >  |  200 SDP A1       |                  |
> > >  |-----------------> |  INV SDP A1      |
> > >  |  ACK              |----------------->|
> > >  |<----------------- |                  |
> > >  |                   |  200 SDP B1      |
> > >  |                   |<-----------------|
> > >  |                   |                  |
> > >  |                   |  ACK             |
> > >  |  INV SDP B1       |----------------->|
> > >  |<------------------|                  |
> > >  |  200 OK SDP A2    |                  |
> > >  |------------------>|                  |
> > >  |  ACK              |                  |
> > >  |<------------------|                  |
> > >  |                                      |
> > >  |               BROKEN RTP             |
> > >  |                                      |
> > >  |                                      |
> > >  |                                      |
> > >
> > > NOTE: A has returned different SDP in its two different 200
> > > OK messages.
> > >
> > > Why might it do this?  It might not but it is possible is it not.
> > >
> > > perhaps we should mandate that an agent can only change 
> its SDP for a
> > > session in an INVITE not in a response (after the initial
> > > INVITE/RESPONSE exchange of course)
> > >
> > > what do we think?
> > >
> > > --
> > > Gethin Liddell
> > > Ubiquity Software Corporation
> > >
> > > http://www.ubiquity.net
> > > mailto:[email-masked]
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > [email-masked]
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> >
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> >
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 1 Dec 2000 16:18:19 -0500

> renegotiated with the other party.

My post was to solve the SDP exchange loop
problem of using 3pcc to pull the subscribers
off of hold.

The following solves the SDP exchange loop
problem during call setup.

I will start by suggesting the use of REFER to get
"A" into the picture during call setup (forgive me
if the transfer spec no longer allows for this).
Otherwise I'd transfer "A" back to the controller
after a held session between "A" and controller are
established.  This allows A's INVITE SDP to be
used to INVITE "B".  This allows "A" to hear/see
the progressing/failure concerning "B".  This also
solves the SDP exchange loop problem during
call setup.

Otherwise, the flow in the following post works.
http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html