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

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 Dec 2000 12:30:04 +0200

Hello,

The ACK is used to stop 200 OK retransmissions. Thus, if it takes some
time for your UAC to get the SDP to be sent in the ACK, the 200 OK will
be retransmitted a number of times although we have already received it.

I do not think it is a good idea to overload a method with two different
functions: stop 200 OK retransmissions and send the SDP.

We have to take into consideration that in 3PCC scenarios the controller
will have to issue another request in order to obtain the SDP that had
to be sent in the ACK. Since this takes time I do not find appropriate
to mess with the retransmission timers for 200 responses.

Best regards,

Gonzalo

Brett Tate wrote:
> 
> 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

-- 
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

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

---

From: Gethin Liddell <[email-masked]>
Date: Fri, 1 Dec 2000 11:00:18 +0000

> be retransmitted a number of times although we have already received it.

Keep in mind though that the late ACK scenario is only going to be used
in certain circumstances.  During normal call setup, the standard
INVITE SDP, ACK no SDP will be used.  When someone does something a bit
special, such as 3PCC, then people are more inclined to accept little
anomolies, such as no audio for the first second.

> functions: stop 200 OK retransmissions and send the SDP.

why? it does not really add any major coding effort to a SIP UA.

> to mess with the retransmission timers for 200 responses.

sorry, don't understand what you're getting at here. we are not messing
with any retranmssion timers.

I actually think that the best solution for 3PCC is an amalgamation of
the late ACK and re-invite proposals:

 A                Controller            B                                                                              
 |  INV  held SDP    |                  |                          
 |<------------------|                  |                          
 |                   |                  |                          
 |  200 SDP A1       |                  |                          
 |-----------------> |                  |
 |                   |                  |
 |       ACK         |                  |
 |<------------------|                  |
 |                   |                  |
 |                   |  INV NO SDP      |
 |                   |----------------->|  (1)
 |                   |                  |
 |                   |  200 SDP B       |
 |                   |<-----------------|
 |      INV SDP B    |                  |
 |<------------------|                  |
 |                   |                  |
 |  200 SDP A2       |                  |                          
 |-----------------> |                  |
 |                   |                  |
 |                   |  ACK  SDP A2     |
 |  ACK              |----------------->|
 |<------------------|                  |
 |                   |                  |
 |                   |       RTP        |
 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
 |                   |                  |
 |                   |                  |
 |                   |                  |
 |                   |                  |
 |                   |                  |
 |                   |                  |
 |                   |                  |
 |                   |                  |

my only query is who do we late ack at (1), agent A or agent B.

Only question is what will agent A do with a re-invite that has no SDP?

http://www.ubiquity.net

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 01 Dec 2000 13:25:35 +0100

> not explicitly mentioned in rfc2543.

I don't remember ever having heard of such usage and it doesn't sound
like a good idea. IMHO it's illogical and inconsistent with how SDP is
used with SIP today: if you want to modify media in any way send updated
SDP.

Anders

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 01 Dec 2000 14:40:06 +0200

Hello,

> anomolies, such as no audio for the first second.

I am not talking about service behavior (the user waiting for a couple
of seconds). I am talking about a UAC retransmitting a 200 OK because an
ACK has not been received. The UAC thinks that the 200 OK responses that
it is sending are getting lost in the network but what it is really
happening is that the UAC that should return an ACK is doing something
in order to gather a proper SDP to piggyback it in the ACK. 

If we send the ACK as soon as the 200 OK arrives the UAS will stop
retransmitting. Then, the UAC can take as long as it wants to gather the
SDP and then re-INVITE.

I would accept to send the SDP in the ACK if the UAC, upon reception of
the 200 OK, it is ready to send the ACK with the SDP. In that case I do
not have a problem with ACKs carrying SDPs.

> why? it does not really add any major coding effort to a SIP UA.

It is not about coding effort. It is about "streching" a retransmission
timer because the SDP is not ready to be sent.

> with any retranmssion timers.

See my comments above.

> the late ACK and re-invite proposals:

In this moment the UAS will begin retransmitting the 200 OK until the
ACK arrives

>  |      INV SDP B    |                  |

At this point the UAS will stop retransmitting the 200 OK... In the
previous message exchange (INVITE SDP B and 200 SDP A2) takes long, the
UAS will have to retransmit the 200 OK a number of times.

Let's keep in mind that retransmissions are used to ensure reliable
delivery of SIP messages. In this scenario the 200 OK was already
delivered but the UAS had to keep on retransmitting... I do not like
that...

Regards,

Gonzalo

---

From: Gethin Liddell <[email-masked]>
Date: Fri, 1 Dec 2000 12:51:21 +0000

My appologies Gonzalo, i missed the point you were making.

IMO, your point is valid and an issue for the original 3PCC draft. 

However, with the "re-invite & late ack" proposal, the 200 response of
the re-invite should come fairly quickly as there is no need to wait
for a user to answer a phone.  

Would this not be enough to avoid the re-transmission problem you
pointed out?

http://www.ubiquity.net

---

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

> used with SIP today: if you want to modify media in any way send updated

http://lists.bell-labs.com/pipermail/sip/2000q2/001125.html

is a thread where this was discussed.

This was also discussed in the advanced media 
scenarios at the last bakeoff.

Let me reiterate why people agreed in previous 
discussions.  

It works similar to the first INVITE without SDP.  
The sender is requesting to establish some type 
of session.  The receiver would pass back 
sessions descriptions which the receiver wishes 
to allow to be established.  The sender would 
pass back the agreed upon session description.

After being put on hold, an INVITE without SDP
works similar to when the session has not been 
established.  If the receiver is NOT the one that 
requested the hold, the receiver should pass 
back the SDP to allow the call to be pulled off 
hold (along with any desire for session changes).
If the receiver wishes not to be pulled off 
of hold, the receiver passes back hold media 
and is basically now responsible for pulling the 
original sender off of hold.

Henning: 

Please add to rfc2543 that an INVITE without 
can be used to request a session to pull off of 
hold.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 1 Dec 2000 09:45:24 -0500

> the late ACK and re-invite proposals:

It would be best to send it first to the party that the 3pcc
is controlling since it should definitely support it, and it
is the one trying to pull the other party off of hold.  In the
above scenario, I am assuming that B put party A on
hold (the picture isn't complete).  Thus the INVITE
without SDP should be sent to B first.

> Only question is what will agent A do with a re-invite that has no SDP?

Assuming no 3pcc, any INVITE without SDP should
be a request to establish a session.  If party A put B
on hold.  An INVITE without SDP from B is a request
basically indicating to please pull me off of hold.
However since A started the hold, it is of course fine
for A to pass back a hold SDP again.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Dec 2000 09:45:48 -0500

> used with SIP today: if you want to modify media in any way send updated

This was discussed and declared a bug, not a feature, a while ago.
Implying specific meaning to 'no SDP' is the road to special-case
bellhead madness. In particular, since the functionality is already
available without this approach.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Dec 2000 09:49:47 -0500

> can be used to request a session to pull off of

No. Terrible idea.

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 01 Dec 2000 16:06:37 +0100

> is a thread where this was discussed.

Ah, I see. It's the ACK with SDP that takes the call off hold, not the
INVITE without. That makes much more sense although I'm still sceptical
of the whole notion of modifying media in ACKs as it denies the receiver
the option of rejecting the changes...

Anders

--
Anders Kristensen

---

From: Gethin Liddell <[email-masked]>
Date: Fri, 1 Dec 2000 14:57:51 +0000

On Fri, 01 Dec 2000, Brett Tate wrote:
> >  |  INV  held SDP    |                  | time t = 0
> >  |<------------------|                  |
> >  |                   |                  |
> >  |  200 SDP A1       |                  |
> >  |-----------------> |                  |
> >  |                   |                  |
> >  |       ACK         |                  |
> >  |<------------------|                  |
> >  |                   |                  |
> >  |                   |  INV NO SDP      |

the picture is actually the call flow that will occur at the initiation
of a 3PCC session.  so `b' has not put `a' on hold, the contoller has
put `a' on hold whilst it tries to contact b'.  once it has contacted
`b', it is able to quickly bring `a' into the RTP session because there
is no user intervention.

if we were to initiate the late ACK scenario to 'a' at (1) then as
Gonzalo pointed out, `a' may be waiting around a long time for an ACK
to appear because we would have to wait for the user to answer the
phone.

http://www.ubiquity.net

---

From: Gethin Liddell <[email-masked]>
Date: Fri, 1 Dec 2000 15:11:07 +0000

> the option of rejecting the changes...

but if the media in the ACK is a subset of the media in the response
(as you suggested) then there is no problem. no?

http://www.ubiquity.net

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 01 Dec 2000 17:14:29 +0100

> (as you suggested) then there is no problem. no?

No, I guess usually there wouldn't be a problem. Although, what if the
UAC sent a b= modifier in the ACK SDP which increases the bandwidth of a
sendonly stream to something the UAS can't handle?

This isn't really different from doing the same thing in a 200 to
INVITE, I know, and only goes to show that the model of updating media
settings in SIP is a little, shall we say, eccentric at times. 
Decoupling the reliability mechanism that ACKs really are from INVITEs
seem like a jolly good step in the right direction to me. [I like that
word "jolly" :)]

Anders

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 1 Dec 2000 13:17:10 -0500

Henning: Thanks for the response.

The following is text from what I thought was the 
decision June 23.  The thread was 
"[SIP] Hold & then re-INVITE without media".
http://lists.bell-labs.com/pipermail/sip/2000q2/001125.html

+++++++++++++++++++++++++++++
"Brett Tate wrote:
> 
> I think you already answered my question, but maybe this
> will provide some clarity.
> 
> For the following question, assume A originally
> sent the INVITE containing an SDP
> with connection address 0.0.0.0 to B; B replied with 200;
> A replied with an ACK.  Can an INVITE without SDP
> indicate to B that A is no longer "holding B" and will
> provide the complete SDP in the ACK?
> 
> A --------------- Invite (no SDP) ----------------------------> B
>   <-- 200 (SDP with connection address not 0.0.0.0) ---
>     --- Ack (SDP with connection address not 0.0.0.0) -->

This should work. This behavior (no SDP in INVITE, but SDP in ACK) is
allowed, actually. Its main use is for the first INVITE, for interop
with H.323v1 amongst other things. However, if you can do something in a
first INVITE, it is allowed in a re-INVITE, so there you go.

-Jonathan R."
++++++++++++++++++++++++++ 

During the Advanced Media Testing at the last 
bakeoff, the topic was again raised because 
some products supported it, and others did not.  
With Robert Sparks organizing the Advanced 
Media Testing, it was reiterated by Robert Sparks 
and myself and dissussed with those present that 
a re-INVITE without SDP indicates a request to 
communicate just as an INVITE without SDP 
would mean prior to a call being established or held.  

It was documented again August 16, "[SIP] Bakeoff 
#5 Advanced Scenarios: Media Changes 
summary for one group"
http://lists.bell-labs.com/pipermail/sip/2000q3/002168.html
The following is a snippit.
++++++++++++++++++++++++++++
"It was decided that session hold and retrieval did 
not need to be tested.  However the importance of an
INVITE without SDP to pull a held party off of hold 
was reiterated for its use by third party call controllers." 
++++++++++++++++++++++++++++

For reference, the following text is from 
September 4, rfc2543bis-02 section 4.2.1:
+++++++++++++++++++++++
"The INVITE method indicates that the user or 
service is being invited to participate in a session.  
The message body MAY contain a description of 
the session to which the callee is being invited.  
For two-party calls, the caller indicates the type 
of media it is able to receive and possibly the 
media it is willing to send as well as their 
parameters such as network destination.  A 
success response MUST indicate in its message 
body which media the callee wishes to receive 
and MAY indicate the media the callee is going 
to send.

The caller MAY choose to omit the request 
body (i.e., not send a session description) or 
send a session description that does not list 
any media type.  This indicates that the caller 
does not know its desired media characteristics 
until the call has been accepted.  In this case, the 
UAS SHOULD still return a session description 
in its informational (1xx) or success (2xx) 
response, containing those media streams and 
codecs it supports."
++++++++++++++++++++++++

The above text implies an INVITE without 
SDP indicates a request for any session 
description that the receiver wishes to allow,
and the sender will provide SDP in the ACK.  
This should translate into having the same 
meaning in a re-INVITE case.  If the receiver 
is not the one that put the call on hold, the 
receiver then should not really want to keep 
the call on hold.  Thus it would pass back SDP 
to allow the call to go non-hold (along with any 
other media changes it might want to allow).  
If for some strange reason the receiver wants 
to keep the call on hold, a hold SDP can be 
returned in 200 response.  And thus it would 
now be responsible to pull the call off of hold.

Henning:  

What does a re-INVITE without SDP mean?  
Why would a re-INVITE without SDP have 
a different meaning from an INVITE without 
SDP?  Just wondering, when was this 
discussed and agreed upon since I thought 
the news group and working group agreed 
upon the opposite?

Thanks for a response.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 1 Dec 2000 15:38:09 -0500

----- Original Message -----
From: Gethin Liddell <[email-masked]>
To: Brett Tate <[email-masked]>
Cc: Sip Mail List <[email-masked]>
Sent: Friday, December 01, 2000 9:57 AM
Subject: Re: [SIP] 3PCC and the re-invite response

> `b', it is able to quickly bring `a' into the RTP session because there

Thanks for the clarification.  I thought you were
trying to use the 3pcc to pull a subscriber off hold.

I will start by suggesting the use of REFER to get
"A" into the picture (forgive me if the transfer spec
no longer allows for this).  Otherwise I'd transfer "A"
back to controller at step 4, and use the INVITE's
SDP when bringing "B" into the call.  This also allows
"A" to hear/see the progressing/failure concerning "B".

Otherwise you can do things as you have captured
in the flow.

---

From: Vladislav Zubarev <[email-masked]>
Date: Thu, 30 Nov 2000 15:01:56 -0800

Looks like sticking to this re-INVITE approach is gonna be more complicated
and probably messier rather than supporting INVITE no SDP, ACK with SDP,
at least for SIP/H.323 gateways.

--
Vladislav Zubarev        mailto:[email-masked]
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org

---

From: Anders Kristensen <[email-masked]>
Date: Sat, 02 Dec 2000 14:27:48 +0100

> into the mentioned SDP change loop.

Technically speaking, I don't see how this solves anything. The UAS can
change SDP in its 200 response to a re-INVITE regardless of whether the
re-INVITE contained SDP or not. Thus having the 3pcc controller shift
SDP from the re-INVITE to the ACK changes nothing. The potential for
looping still exist.

I think the solution has to be to limit what SDP changes can be made in
200 responses and ACKs.

Anders

---

From: "Brett Tate" <[email-masked]>
Date: Sat, 2 Dec 2000 18:40:17 -0500

> SDP from the re-INVITE to the ACK changes nothing. The potential for

Please read more within the thread; Gethin provided 
a flow using INVITE without SDP that works.  I'd prefer 
getting A's SDP by using a no-call REFER or 
hold-then-transfer to "B" through controller as means for 
call setup to allow "A" to hear/see ringing/failure when 
INVITE "B". 

> I think the solution has to be to limit what SDP changes can be made in

I agree that limiting what SDP changes can occur 
through the course of the session would simplify 
matters.  However it would also greatly reduce 
the capabilities/services that are already being 
provided by some controllers and other smart 
SIP entities.

SDP in PRACKs and SDP changes during session 
timer extending 200 responses, produce some 
interesting challenges for 3pcc, but they can be 
resolved by extra messaging, coding, and 
potentially more detailed specification.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 04 Dec 2000 10:01:56 +0200

Hello,

I do not like to send the SDP in the ACK because the 200 OK gets
retransmitted a number of times. However, as folk have pointed out,
sometimes it does not take that long for the controller to receive the
new SDP to be sent in the ACK.

Thus, we could copy the delayed acknowledgments from TCP.

The UAC can delay the ACK up to a certain amount of time (in TCP it is
usually 200 ms). If when this timer expires the UAC cannot send the ACK
with SDP it will send an ACK without SDP and re-INVITE when it is ready
to send the new SDP.

I think this would be an acceptable way of combining delayed ACKs with
the re-INVITE method.

However, in my opinion, applications would use the re-INVITE method most
of the times.

Regards,

Gonzalo

---

From: "Gethin Liddell" <[email-masked]>
Date: Mon, 4 Dec 2000 22:25:31 -0000

Hi Gonzalo,
> with SDP it will send an ACK without SDP and re-INVITE when it is ready

Hmmm, in the proposed 3pcc combination of late ack and re-invite, the late
ack is going to the new called party (agent b).  Therefore, if the late ack
and the original invite did not contain any SDP then agent b would have been
invited to a session that had no SDP at all.  IMO this is not a very nice
thing to do to the agent.

I think that if you are actually worried about the delay b4 the ack arrives,
then it should not be a problem because agent a will respond with a 200
pretty quickly. if it doesn't, then agent b should behave as it would for
any call that it does not receive an ACK for and time out after some period
of time.

As the 2 user-agents do not know they are in a call then we should utilize
their default time outs and leave it up to them rather than try to add it in
to the controller.

> However, in my opinion, applications would use the re-INVITE method most

but the re-invite method is broken.  that is why we have had this
discussion, we are not trying to change it just for the sake of it.