Subject: [sipcore] Re-INVITE handling draft

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 26 Oct 2009 16:07:29 +0200

Folks,

I have just submitted a new version of the re-INVITE handling draft:

http://www.ietf.org/id/draft-camarillo-sipcore-reinvite-01.txt

This revision reflects the conclusions reached during the extensive 
discussions we had on this topic. Comments on the whole draft are very 
welcome. Additionally, there is an issue marked as TODO, which is 
related to RFC 3264. You may want to comment on that as well.

Note that our charter has the following milestone:

   Invite Transaction Handling Correction

This draft directly addresses that milestone.

Cheers,

Gonzalo

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 30 Oct 2009 11:10:42 -0500

> related to RFC 3264. You may want to comment on that as well.

Quoting from the draft:
   either.  A UA considers the new parameters to be in use when it sends
   media using them, or when media that uses the new parameters is
   received, which should be interpreted as follows.  From Section 8.3.1
   of RFC 3264 [RFC3264]:

      "Received, in this case, means that the media is passed to a media
      sink.  This means that if there is a playout buffer, the agent
      would continue to listen on the old port until the media on the
      new port reached the top of the playout buffer.  At that time, it
      MAY cease listening for media on the old port."

   TODO: RFC3264 assumes media streams that carry media continuously.
   So, it considers that an UA should continue listening to the old port
   (i.e., using the old parameters) until it sends media or receives
   media on the new port.

An area of complication we have been dealing with when supporting T.38
FAX is that some endpoints will setup the session with a single 'audio'
media stream, and then when they desire to switch to T.38, they'll send
a re-INVITE dropping that audio stream and adding an image/t38 stream,
using the *same port* that the audio stream was using. In addition, a
particular implementation assumes that at the moment it receives a
non-error final response to the re-INVITE, that it should no longer
receive any audio media to that port, but instead will receive only
UDPTL media.

This is effectively impossible to achieve, given that signaling and
media are frequently not controlled by the same application (or even on
the same machine), and that there could very well be audio media packets
in transit to the receiver at the same time that the final response is
sent to the receiver.

Would it be appropriate to add recommendations/clarifications to this
draft strongly suggesting that this sort of behavior is not a wise
implementation choice? I've heard comments from a couple of people that
reusing the port "improves NAT traversal abilities", but in reality I
don't see how that is possible unless *both* ends make the media stream
change without changing port numbers.

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