Greetings,
I posted this on the Microsip user list and they suggested I post here.
I have identified a discrepancy in the (Media Description, name and address (m):) portion of the 200OK response to an invite.
This happens on an incoming call to the MicroSIP client.
The SDP from MicroSIP is using an odd port number in its response.
This is not following the RFC and is keeping my test equipment from being able to identify RTP streams as they expect to see RTP on even numbered ports.
Is this intended?
See below for an example:
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 3856185328 3856185328 IN IP4 10.2.112.22
Session Name (s): -
Connection Information (c): IN IP4 10.2.112.22
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 65437 RTP/AVP 0 101
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): ptime:20
Referencing RFC 3550 for clarification
RFC 3550 RTP July 2003
- RTP over Network and Transport Protocols
This section describes issues specific to carrying RTP packets within
particular network and transport protocols. The following rules
apply unless superseded by protocol-specific definitions outside this
specification.
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. 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. The
RTP and RTCP port numbers MUST NOT be the same since RTP relies on
the port numbers to demultiplex the RTP data and RTCP control
streams.
Jerry Chinn
Telecom VoIP Specialist
NAVIS More Performance. More Profit.
tel 541-330-3562
www.TheNavisWay.comhttp://www.thenavisway.com/
Facebookhttps://www.facebook.com/theNAVISway/ | Twitterhttps://twitter.com/NAVISway | LinkedInhttps://www.linkedin.com/company/navisway | Bloghttps://www.thenavisway.com/blog
Greetings,
I posted this on the Microsip user list and they suggested I post here.
I have identified a discrepancy in the (Media Description, name and address (m):) portion of the 200OK response to an invite.
This happens on an incoming call to the MicroSIP client.
The SDP from MicroSIP is using an odd port number in its response.
This is not following the RFC and is keeping my test equipment from being able to identify RTP streams as they expect to see RTP on even numbered ports.
Is this intended?
See below for an example:
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 3856185328 3856185328 IN IP4 10.2.112.22
Session Name (s): -
Connection Information (c): IN IP4 10.2.112.22
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 65437 RTP/AVP 0 101
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): ptime:20
Referencing RFC 3550 for clarification
RFC 3550 RTP July 2003
11. RTP over Network and Transport Protocols
This section describes issues specific to carrying RTP packets within
particular network and transport protocols. The following rules
apply unless superseded by protocol-specific definitions outside this
specification.
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. 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. The
RTP and RTCP port numbers MUST NOT be the same since RTP relies on
the port numbers to demultiplex the RTP data and RTCP control
streams.
Jerry Chinn
Telecom VoIP Specialist
NAVIS More Performance. More Profit.
tel 541-330-3562
www.TheNavisWay.com<http://www.thenavisway.com/>
Facebook<https://www.facebook.com/theNAVISway/> | Twitter<https://twitter.com/NAVISway> | LinkedIn<https://www.linkedin.com/company/navisway> | Blog<https://www.thenavisway.com/blog>