Subject: [Sip] Re: [Sipping] SDP offer/answer -- Port 9

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 17 Aug 2007 09:00:41 +0300

I think MMUSIC working group is a better place to discuss this.

On Thursday 16 August 2007 18:59:39 ext Iliff, Tina wrote:
> Hi!  I have encountered an application in the "real world"  which
> provides port 9 in the SDP answer in the 200OK.  The SDP m line
> indicates RTP/AVP.  I recognize that port 9 is acceptable if the SDP m
> line indicates BFCP.  My question is:   Is port 9 acceptable for
> RTP/AVP.  In other words, should the original offerer send an ACK and
> then immediate BYE indicating that it rejected the answer?  Or....should
> the offerer send an ACK, then send media to port 8?

Port 9 is legal for any connection-oriented media transport. You are right 
however that it should not be used with RTP/AVP (=> UDP => not 
connection-oriented). Unless the SDP author wants the data really be sent to 
port 9.

> FYI.  What I am actually seeing is that the answerer indicates port 9 in
> the answer but sends a re-INVITE immediately after the ACK; however, the
> originator/offerer does not accept the re-INVITE due to it is already in
> the process of tearing down the call.
>
> Has anyone else seen this specific behavior or similar behavior?
>
> P.S.  RFC2327 noted a range of 1024-65535 for RTP ports; however,
> RFC4566 does not indicate a specific range.

I think it's not the job of the SDP receiver to check the port numbers. If the 
sender wants to use port 9, why not afterall? Maybe it wants you to send to 
its discard service (makes sense if it's a send-only chatter bot).

However, I would assume that in the case you describe, it would not actually 
work properly if you sent data to port 9 anyway.

-- 
Rémi Denis-Courmont

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jagan Mohan" <[email-masked]>
Date: Fri, 17 Aug 2007 19:26:00 +0530

> connection-oriented). Unless the SDP author wants the data really be sent

As per section 5.14 of RFC 4566, port 9 is perfectly fine but "a=rtcp:"
line MUST be there in SDP.

> > RFC4566 does not indicate a specific range.

I would also like to know why the range of 1024-65535 was removed in RFC
4566.

Regards,
Jagan

---

From: "Iliff, Tina" <[email-masked]>
Date: Thu, 16 Aug 2007 15:59:39 +0000

Regards,

Tina Iliff

---

From: [email-masked]
Date: Sun, 26 Aug 2007 20:55:37 -0400

From: "Iliff, Tina" <[email-masked]>

   RTP/AVP.  [...]

Since RFC 4566 is the latest standard and does not restrict the port
number to a particular range, you should not restrict the port number.
In addition, unless there is a specific functional reason, an
application should never place a restriction on a port number supplied
by the other end, regardless of the standard.

More interesting is RFC 3550, in which the use of even/odd port number
pairs is described for the corresponding RTP and RTCP streams:

   11. RTP over Network and Transport Protocols

   RTP relies on the underlying protocol(s) to provide demultiplexing of
   RTP data and RTCP control streams.  For UDP and similar protocols,
   RTP SHOULD use an even destination port number and the corresponding
   RTCP stream SHOULD use the next higher (odd) destination port number.
   For applications that take a single port number as a parameter and
   derive the RTP and RTCP port pair from that number, if an odd number
   is supplied then the application SHOULD replace that number with the
   next lower (even) number to use as the base of the port pair.

So by default, specifying port 9 means that RTP is on port 8 and RTCP
is on port 9.  But SDP also allows the RTCP port to be specified
separately.  RFC 4566:

   5.14.  Media Descriptions ("m=")

      If non-contiguous ports are used or if they don't follow the
      parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:"
      attribute MUST be used.

And continuing with RFC 3550:

   For applications in which the RTP and RTCP destination port numbers
   are specified via explicit, separate parameters (using a signaling
   protocol or other means), the application MAY disregard the
   restrictions that the port numbers be even/odd and consecutive
   although the use of an even/odd port pair is still encouraged.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Aug 2007 12:06:52 -0400

I didn't notice anyone mention the particular significance of port 9. It 
is the "discard" port. I'm guessing the choice of this port isn't an 
accident. Rounding down to port 8, while correct if no a=rtcp is 
present, may not achieve the intended effect.

I'm curious *why* port 9 is being used in the answer.

	Paul