Subject: RE: [SIP] RE: Changin local RTP port without a good reason

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Dec 2000 01:30:38 -0500

> -----Original Message-----
> From: Pekka Pessi [mailto:[email-masked]]
> Sent: Monday, December 18, 2000 3:30 AM
> To: [email-masked]
> Cc: Gonzalo Camarillo
> Subject: Re: [SIP] RE: Changin local RTP port without a good reason
> 
> 
> In message <[email-masked]> "ext Gonzalo 
> Camarillo" <[email-masked]> writes:
> >Of course that sometimes you have to change your local 
> configuration if
> >the remote configuration changes... but there has to be a good reason
> >(like a change of codecs).
> 
> 	When you issue a re-INVITE with a new local port number, you are
>         proposing a new RTP session.  The remote end can not 
> distinguish
>         between packets in the old session and new session, unless it
>         changes its RTP port, too.

Much as I would like to be able to enforce this "don't change ports without
good reason", I think there are cases where implementations will want to do
this on each re-invite. As such, I think the mechanism in the current 3pcc
draft won't work either. 

An alternative flow has already been proposed which does not suffer from the
timeout problem, and which does not have this race condition:

> >  A                Controller            B
> >  |  INV  SDP held    |                  | time t = 0
> >  |<------------------|                  |
> >  |                   |                  |
> >  |  200 SDP A1       |                  |
> >  |-----------------> |                  |
> >  |                   |                  |
> >  |       ACK         |                  |
> >  |<------------------|                  |
> >  |                   |                  |
> >  |                   |  INV no SDP      |
> >  |                   |----------------->|  (1)
> >  |                   |                  |
> >  |                   |  200 SDP B       |
> >  |                   |<-----------------|
> >  |      INV SDP B    |                  |
> >  |<------------------|                  |
> >  |                   |                  |
> >  |  200 SDP A2       |                  |
> >  |-----------------> |                  |
> >  |                   |                  |
> >  |                   |  ACK  SDP A2     |
> >  |  ACK              |----------------->|
> >  |<------------------|                  |
> >  |                   |                  |
> >  |                   |       RTP        |
> >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> >  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
> >  |                   |                  |

I'd like to start with this one as the basis for continuing
discussion/concerns.

-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

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

---

From: "Hisham Khartabil" <[email-masked]>
Date: Tue, 19 Dec 2000 10:44:12 +0200

What was the conclusion about the issue of SDP in ACK.  If the decision was
to disallow it, then the flow below is breaking that rule already.

Regards,
Hisham

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
> Sent: Tuesday, 19 December 2000 8:31 AM
> To: 'Pekka Pessi'; [email-masked]
> Cc: Gonzalo Camarillo
> Subject: RE: [SIP] RE: Changin local RTP port without a good reason
>
>
>
>
>
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 20 Dec 2000 16:11:39 +0200

Hi,

Actually there is nothing new with this flow. This is the delayed ACK
solution that was already proposed. Since the INV/200 OK will most
likely take little time, it will work. However, when INV-200 OK takes
longer we have the same problem.

In most of the situations, using the delayed ACK, the flow you just
described works. However, if the SDP is not ready and the ACK has to be
sent to stop the retransmission timer, we will still have to make up an
SDP... we might want to work on this scenario.

Best regards,

Gonzalo

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

---

From: "Steve Donovan" <[email-masked]>
Date: Wed, 20 Dec 2000 09:17:12 -0600

> Sent: Tuesday, December 19, 2000 12:31 AM

What is the end-user experience with this call?  What does the
user at A do when he gets a call that is on hold and hears silence?
Isn't there a high probability that he will hang up while the
controller is waiting for B to answer?

In order for this to work, isn't it necessary for the controller to
play some sort of media telling the user to hold on while the call
is being setup?  Either that or A needs to understand that it is
a 3PCC call and know to either not notify the user or tell the user
to wait.

---
Steven R. Donovan
Architect                           dynamicsoft
mailto:[email-masked]     5100 Tennyson Parkway
sip:[email-masked]    Plano, Texas 75025
tel:+1-972-473-5469                 http://www.dynamicsoft.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 20 Dec 2000 19:23:46 +0200

Hi,

> a 3PCC call and know to either not notify the user or tell the user

One very common scenario in 3pcc in that where A is a machine and B is a
human. The controller is an Application Server that coordinates several
APCs in order to provide a service to the end user B. Thus, A will not
hang because it is a machine.

However, when A and B are both humans we have the problem you have just
described. Actually it does not make any difference for the controller
send the 1st INVITE on hold or with a real SDP in order to sent a
pre-recorded announcement.

Let's focus on solving the 3pcc problem. Playing announcement is already
taken care of by vanilla SIP. Besides, I do not think interactions
between announcements and 3pcc are complicated. I find more challenging
QoS provision interactions.

Best regards,

Gonzalo