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

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Dec 2000 19:34:28 +0200

Hello,

The issue of implementations changing local RTP ports upone reception of
a re-INVITE has great importance. It has influence is some of the drafts
that are currently out there (such as 3pcc).

A SIP implementation would not have to change the local RTP port when a
re-INVITE changing the remote RTP port arrives. However, it seems that
some frameworks (such as Java) change it. A SIP UA using this media
framework does not have control over this change.

I would like to fully understand the problem. I have a question:

How can these implementations re-INVITE?
I change my local RTP port and re-INVITE. I will receive a 200 OK with
an updated remote RTP port. Since I cannot change the the remote RTP
port without changing my local RTP port, I will have to send an updated
SDP in the ACK... is this correct?

Thanks,

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

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

---

From: "Robert Sparks" <[email-masked]>
Date: Thu, 14 Dec 2000 12:32:12 -0600

> an updated remote RTP port.

> Since I cannot change the the remote RTP
> port without changing my local RTP port,

I'm not aware of any applications that have run into that particular
problem.

> I will have to send an updated

The problem that early users of JMF ran into was being able to change
codecs (this was one of the major motiviations for reINVITE yes?) in
the object that was receiving/rendering media and keep the same local port.
I have heard that this has been addressed in more recent versions of
the JMF. Someone speak up if this is not true or if they still have
this kind of problem in another environment.

Even if this has been addressed, I'm uncomfortable with the idea that
an implementation should be forced to keep the same local port across
reinvites. Do I have to do this if I'm fundamentally changing media
types? What if I'm adding/removing media lines? This was why we have
a full-state reINVITE and not a HOLD method yes?

RjS

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 14 Dec 2000 16:13:08 -0500

Agreed.  The "alternate codec" may be physically somewhere else.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Robert Sparks
> Sent: Thursday, December 14, 2000 1:32 PM
> To: Gonzalo Camarillo; sip
> Subject: [SIP] RE: Changin local RTP port without a good reason

[snip]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 15 Dec 2000 05:02:34 +0200

Hello,

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

We have to have certain limits on when the local configuration cannot
change in the 200 OK for a re-INVITE. Then, 3pcc will work without
problems.

If an application can, whenever there is a change in the remote side,
change its local configuration, it would be impossible to establish even
a simple session.

If my local configuration is too dependant on the other party's
configuration the negotiation ends up in an infinite loop.

A re-INVITEs B. Since A has changed its configuration, B does so and
returns an updated SDP in the 200 OK. 

A sent the re-INVITE taking into consideration B's previous SDP. Since B
has now changed, A wants to change again. B will return again a new SDP,
and this loop can go on for ever.

Thus, I understand that under certain circumstances an application can
decide to change its local configuration upon reception of an INVITE,
but this is not a general situation. I do not find sensible to change my
local port just because the remote port has changed.

This is acutally what it is written in the 3pcc draft. It is recommended
that an application does not change its local configuration without a
"good" reason. We could define what a good reason is...

Best regards,

Gonzalo

---

From: Pekka Pessi <[email-masked]>
Date: 18 Dec 2000 10:29:42 +0200

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

>configuration the negotiation ends up in an infinite loop.

        There is always a request and a corresponsing response.  Depending
        on previous response is not sensible, in my opinion.

                                        Pekka