Subject: [sipcore] Comments on draft-ieft-sipcore-reinvite-01

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 02 Mar 2010 11:08:30 -0600

Editorial comments:

Section 1:

"There has been some confusion among implentors regarding how a UAS"

... should be 'implementors'.

Section 3.7:

SDP4 is improperly formatted.

Content comments:

Section 3.3:

"A change to the session state is considered to have been executed if
  an offer/answer without preconditions [RFC4032] for the stream has
  completed successfully or the UAs have exchanged media using the new
  parameters.  Connection establishment messages (e.g., TCP SYN),
  connectivity checks (e.g., when using ICE [I-D.ietf-mmusic-ice]), and
  any other messages used in the process of meeting the preconditions
  for a stream are not considered media."

This is the issue I spoke briefly with Gonzalo about in Hiroshima, that
we've seen in the field.

The scenario is that a UAC sends an INVITE with only an audio stream;
the UAS accepts it with 200 OK and the ACK is sent by the UAC. Later,
one party (does not matter which) sends a re-INVITE requesting that that
single stream be changed from audio to image/t38, using the *same port
number* to receive the media. Because the port number did not change,
and there is likely already audio media in RTP packets in-flight towards
that endpoint, as soon as any of those RTP packets are received by that
endpoint, it will consider that change to have been executed by the
party that received the re-INVITE, even before receiving any SIP
response to the re-INVITE itself. If the party receiving the re-INVITE
does not want to switch to T.38, it can send a 488 Not Acceptable Here,
but from the point of view of the party that sent the re-INVITE, this is
too late... the change has been executed. This will occur any time the
re-INVITE changes an existing media stream in a way that cannot easily
be detected via packet inspection and does *not* change port numbers.

Given that, I see only two possibilities to improve the interoperability
situation:

1) We include a normative statement in this document that specifies that
a re-INVITE that changes the content-type of a media stream SHOULD NOT
use the same port number as was previously used for that media stream,
so that the offerer can explicitly determine whether the answerer is
executing the change

or

2) We include a set of statements in this document telling implementors
that if they receive a re-INVITE that changes the content type of an
existing media stream and does not change port numbers, that they will
not be effectively able to send a rejection of that re-INVITE if the
previous stream state was such that media was already flowing, and that
they should either use UPDATE within the re-INVITE transaction (as
documented in this draft) to attempt to revert to the pre-re-INVITE
state, or they should accept the re-INVITE and then issue one of their
own to revert to the pre-re-INVITE state.

While section 3.4 attempts to address this situation, my concern is that
the unless the UAS takes the lack of port number change into account, it
may send an error response to the re-INVITE under the (valid) assumption
that none of the requested changes have been executed... but the UAC
thinks that they have been executed. Does everyone else on the list
think that section 3.4's language adequately addresses this situation?

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2010 12:27:44 -0500

Kevin,

I don't understand your scenario. IIUC,

- A & B negotiate a voice stream
- A is receiving voice media
- A sends reinvite to B with offer of t.38
- A continues to receive voice media in accord with
   session in effect prior to the reinvite
- B rejects the reinvite with 488
- A and B continue to use voice media

I don't see where there was a problem there. The alternate scenario is

- A & B negotiate a voice stream
- A is receiving voice media
- A sends reinvite to B with offer of t.38
- A continues to receive voice media in accord with
   session in effect prior to the reinvite
- B sends 2xx accepting the change
- B sends t.38 media
- A receives t.38 media and infers change was accepted
- A receives the 2xx
- session continues with t.38.

What is significant above is that A must be prepared to receive *either* 
voice or t.38 on that port for some period of time. If it can't tolerate 
that, then it had better use a different port.

What am I missing?

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 02 Mar 2010 11:36:32 -0600

> that, then it had better use a different port.

That is in fact the issue, and the problem we see in the field is that
because there is no such thing as a protocol number at the UDP level,
and T.38 doesn't use RTP for transport, there is no reliable way to
discriminate an incoming packet to determine whether it is RTP carrying
G.711 PCMU audio or UDPTL carrying a T.38 IFP. At best you can attempt
to completely decode it as both forms, and then try to decide what you
think it is, but it could very easily be the case that the first 'n'
bytes of a UDPTL frame when interpreted as an RTP header contain a valid
payload number for the existing audio session in the right location, and
then there's really no way the endpoint can know for sure.

This really falls into the 'best practices' area I suppose, and we'll
certainly consider including a recommendation of this type in the SIP
Forum work we are doing, but it seems that given the RFC3261 language
about a change being 'executed' as soon as the offerer receives media
using the 'new parameters', implementors should be cautioned (if not
strongly warned) about sending a re-INVITE that would not allow them to
determine whether the new parameters are being used or not. If the UAC
and UAS can't explicitly indicate to each other that the new parameters
are in use because of this problem, then implicit behavior will result,
and the endpoints will get out of sync. This can be completely avoided
with very little effort on the part of the implementor, though, which
was my goal in raising this issue.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Mar 2010 12:58:48 -0500

OK. I agree this falls into the category of a "logical necessity" that 
could be well handled by a BCP.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Mar 2010 22:29:56 +0100

Hi,

If you use different ports, and you use ICE, I guess that means that you need to perform new ICE procedures for that port before you can start using it.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 2. maaliskuuta 2010 19:59
To: Kevin P. Fleming
Cc: [email-masked]
Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01

OK. I agree this falls into the category of a "logical necessity" that could be well handled by a BCP.

	Thanks,
	Paul

Kevin P. Fleming wrote:
>> What is significant above is that A must be prepared to receive 
>> *either* voice or t.38 on that port for some period of time. If it 
>> can't tolerate that, then it had better use a different port.
>>
>> What am I missing?
> 
> bytes of a UDPTL frame when interpreted as an RTP header contain a 
> valid payload number for the existing audio session in the right 
> location, and then there's really no way the endpoint can know for sure.
> 
> strongly warned) about sending a re-INVITE that would not allow them 
> to determine whether the new parameters are being used or not. If the 
> UAC and UAS can't explicitly indicate to each other that the new 
> parameters are in use because of this problem, then implicit behavior 
> will result, and the endpoints will get out of sync. This can be 
> completely avoided with very little effort on the part of the 
> implementor, though, which was my goal in raising this issue.
> 
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 03 Mar 2010 06:25:02 -0600

> If you use different ports, and you use ICE, I guess that means that you need to perform new ICE procedures for that port before you can start using it.

That would be true, yes. On the SIP Forum mailing list when I brought
this up there were comments about 'using the same port will keep the NAT
mapping open if there is one', but that's only true if both endpoints
use the same port for the replaced media stream.

I suppose that the real cause of this issue is UDPTL itself, and the
fact that it's not possible to easily discriminate between UDPTL and
RTP. If the T.38 media stream was in audio/t38 mode (and thus using RTP
for transport), as long as the payload number chosen was not one of the
possible options for the previous media stream, discrimination of the
incoming packets would be trivial.

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 03 Mar 2010 09:25:52 -0600

> If you use different ports, and you use ICE, I guess that means that you need to perform new ICE procedures for that port before you can start using it.

While hashing over this I came up with another scenario where the 'media
exchanged using new parameters' trigger is not sufficient to actually
know that an offerer's changes have been executed, so I'd like to
propose an alternative way of describing this problem that may also make
it more appropriate for inclusion in this draft.

As a degenerate case of the 'port number did not change' scenario,
imagine that an endpoint is currently exchanging audio media using the
iLBC codec over RTP, which requires usage of a dynamic payload number
since iLBC does not have an assigned payload number. Later, it wants to
switch to Speex, which also does not have an assigned payload number, so
it sends a re-INVITE with an offer that uses the same port number *and*
payload number, but provides an rtpmap from that payload number to Speex
 instead of iLBC. Again in this scenario the offerer cannot safely use
'media exchanged using the new parameters' as a trigger for 'changes
have been executed' because in-flight RTP packets will have that payload
number already. I understand this is a contrived scenario, but it does
not seem that far outside the bounds of what implementors tend to do :-)

So, I'd like to propose this sort of language instead:

An offerer in a re-INVITE transaction is allowed by RFC3261 to treat its
offered changes as 'executed' based on *either* receiving a non-error
response to its offer *or* determining that media has been exchanged
using the new session parameters. However, if the offer's session
parameters do not differ sufficiently from the previous session state to
allow this determination to be made conclusively, the offerer should not
use media exchange as the threshold for execution of the changes, and
should instead use only the reception of a non-error response as the
trigger. This affords the answerer the opportunity to provide an error
response to the offer if desired without the two endpoints getting out
of sync in their understanding of the session state.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Mar 2010 12:41:52 -0500

Kevin,

Once a payload number has been bound to a codec in a session, it isn't 
supposed to be used for anything else in that session. (I'll have to 
hunt to find the text that says that, but its somewhere.)

However it turns out that this is another one of those things that can 
be broken by 3pcc. So a robust implementation should be prepared to cope 
with this if it happens - to the extent that there is sufficient 
information to cope. E.g. if a payload number that was once mentioned 
has not been in use for awhile, a robust implementation ought to be 
capable of supporting its subsequent use for a different codec.

Anyway, when this is just UA-UA, a conforming implementation will not 
get into the situation you describe.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 03 Mar 2010 14:54:05 -0600

> hunt to find the text that says that, but its somewhere.)

OK, that makes complete sense.

> get into the situation you describe.

That does help then. Thanks for the information.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Mar 2010 09:49:37 +0200

Hi Kevin,

> ... should be 'implementors'.

Fixed.

> SDP4 is improperly formatted.

Fixed.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Mar 2010 10:01:40 +0200

Hi,

yes, what Paul indicates is documented in Section 8.3.2 of RFC 3264:

http://tools.ietf.org/html/rfc3264#section-8.3.2

"However, in the case of RTP, the mapping from a particular dynamic
payload type number to a particular codec within that media stream MUST
NOT change for the duration of a session."

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 04 Mar 2010 10:29:26 +0200

Hi Kevin,

Section 8.3.3 of RFC 3264 describes when it makes sense to reuse an m
line when changing the media type:

http://tools.ietf.org/html/rfc3264#section-8.3.3

  "It
   is RECOMMENDED that the media type be changed (as opposed to adding a
   new stream), when the same logical data is being conveyed, but just
   in a different media format."

In any case, what you describe are scenarios where the UA will not
notice it has received media using the new parameters until it actually
decodes the media in order to play it out. That is fine. When the UA
finally notices the new parameters, it will consider the changes to have
been executed.

Note that the text in the draft talks about new media "having been"
exchanged. It does not talk about UAs "assuming" new media has been
exchanged. If the UA does not know for sure new media has been
exchanged, it does not do anything.

In order to address your comment and make this process clearer, I will
add the following paragraph after the third paragraph of Section 3.3

  Normally, a UA receiving media can easily detect when the new
  parameters for the media stream are used (e.g,. media is received on a
  new port). However, in some scenarios the UA will have to process
  incoming media packets in order to detect whether they use the old or
  the new parameters.

Thanks for your comments,

Gonzalo

Kevin P. Fleming wrote:
> Christer Holmberg wrote:
> 
>> If you use different ports, and you use ICE, I guess that means
>> that you need to perform new ICE procedures for that port before
>> you can start using it.
> 
> While hashing over this I came up with another scenario where the
> 'media exchanged using new parameters' trigger is not sufficient to
> actually know that an offerer's changes have been executed, so I'd
> like to propose an alternative way of describing this problem that
> may also make it more appropriate for inclusion in this draft.
> 
> imagine that an endpoint is currently exchanging audio media using
> the iLBC codec over RTP, which requires usage of a dynamic payload
> number since iLBC does not have an assigned payload number. Later, it
> wants to switch to Speex, which also does not have an assigned
> payload number, so it sends a re-INVITE with an offer that uses the
> same port number *and* payload number, but provides an rtpmap from
> that payload number to Speex instead of iLBC. Again in this scenario
> the offerer cannot safely use 'media exchanged using the new
> parameters' as a trigger for 'changes have been executed' because
> in-flight RTP packets will have that payload number already. I
> understand this is a contrived scenario, but it does not seem that
> far outside the bounds of what implementors tend to do :-)
> 
> An offerer in a re-INVITE transaction is allowed by RFC3261 to treat
> its offered changes as 'executed' based on *either* receiving a
> non-error response to its offer *or* determining that media has been
> exchanged using the new session parameters. However, if the offer's
> session parameters do not differ sufficiently from the previous
> session state to allow this determination to be made conclusively,
> the offerer should not use media exchange as the threshold for
> execution of the changes, and should instead use only the reception
> of a non-error response as the trigger. This affords the answerer the
> opportunity to provide an error response to the offer if desired
> without the two endpoints getting out of sync in their understanding
> of the session state.
>