Hi Philipp,
>> So the "m="line has to contain one payload value of the offer?!
It has to contain a codec (format) listed in the offer, not a payload
type number.
The codec specifies the format of the RTP sent. Both sides need to be
able to code/decode the format (e.g. PCMA) so both offer and answer must
indicate the same codec. The payload type number is used in the payload
type field of sent RTP packets to indicate to the receiving side which
format this RTP packet's payload is in.
Best regards,
Richard Phernambucq
On 29-10-2018 12:10, Philipp Schöning wrote:
Thanks Richard for your extensive comments, this helps a lot.
You wrote:
Furthermore, it is acceptable that offerer and answerer end up using
different payload type number for the same codec. In that case the
number indicates the payload type field the offerer/answerer expects to
receive (see RFC 3264 5.1 and 6.1). That means after the Re-Invite the
session is actually still valid: both sides send PCMA RTP; the server
fills the payload type field with value 118 and the client with value 8.
But in RFC 3264, 6.1 it is stated:
For streams marked as sendrecv in the answer,
the "m=" line MUST contain at least one codec the answerer is willing
to both send and receive, from amongst those listed in the offer.
So the "m="line has to contain one payload value of the offer?!
Best Regards
Philipp Schöning
Am Mo., 29. Okt. 2018 um 11:34 Uhr schrieb Richard Phernambucq <
r.phernamb...@cuperus.nl>:
Hi Philipp,
Is this actually possible that different payload type numbers have the
same attributes?
Yes, see the second quote from RFC 3264.
You have a point when you say this is not a change of codecs, but a
change of attributes for the same codec. This is allowed as stated in
RFC 3264 8.3.4 (Changing attributes). But you're not making it easy for
the answerer, especially since the new attributes have already been
negotiated for another payload type number during the original Invite.
To prevent interoperability issues you'd probably use payload type
number 118 in the Re-Invite, instead of changing the attributes for
payload type number 8.
Furthermore, it is acceptable that offerer and answerer end up using
different payload type number for the same codec. In that case the
number indicates the payload type field the offerer/answerer expects to
receive (see RFC 3264 5.1 and 6.1). That means after the Re-Invite the
session is actually still valid: both sides send PCMA RTP; the server
fills the payload type field with value 118 and the client with value 8.
Actually, according to RFC 3264, it isn't even necessary for the server
to send the Re-Invite. The codec in the Re-Invite offer/answer has
already been negotiated during the original Invite offer/anwer and the
offerer (server) is allowed switch between codecs during a session. This
is stated in chapter 5.1:
If multiple formats are listed, it
means that the offerer is capable of making use of any of those
formats during the session. In other words, the answerer MAY change
formats in the middle of the session, making use of any of the
formats listed, without sending a new offer.
Best regards,
Richard Phernambucq
On 29-10-2018 10:14, Philipp Schöning wrote:
Hi Richard,
thanks for your answer.
I totally agree to you when you interprete this as a change of payload
type
number from 118 to 8.
But I think it is also a legitimate view, that this Re-Invite does not
represent a change of payload type number, but a change of the attributes
of payload 8.
So in this case, parameters of codec 118 did not change, but only the
parameter of 8 changed.
Is this actually possible that different payload type numbers have the
same
attributes?
Best Regards
Philipp Schöning
Am Mo., 29. Okt. 2018 um 08:06 Uhr schrieb Richard Phernambucq <
r.phernamb...@cuperus.nl>:
Hi Philipp,
According to RFC 3264 the server sending the Re-Invite is wrong. See
chapter 8.3.2 (Changing of Set of Media Formats):
(...) 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.
So changing the payload type number from 8 to 118 during the session is
not allowed. It would have been allowed though if payload type number
118 wasn't already in use (see same chapter):
(...) it is acceptable for multiple payload type numbers to be mapped to
the same
codec, so that an updated offer could also use payload type number
72
Best regards,
Richard Phernambucq
On 27-10-2018 14:52, Philipp Schöning wrote:
Hi all,
we saw a SIP implementation violating the SDP offer/answer procedure
when
answering a Re-Invite.
Here is the signalling:
Server Client
+----------------INVITE--------------------->
m=audio 18410 RTP/AVP 8 100 118
b=AS:87
b=RS:1087
b=RR:3262
a=rtpmap:8 PCMA/8000
a=fmtp:8 vad=no
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:118 PCMA/8000
a=gpmd:118 vbd=yes
a=sendrecv
<----------------200 OK---------------------+
m=audio 9158 RTP/AVP 8 118 100
a=rtpmap:8 PCMA/8000
a=fmtp:8 vad=no
a=rtpmap:118 PCMA/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
+-----------------Re-Invite----------------->
m=audio 18410 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=gpmd:8 vbd=yes
a=silenceSupp:off - - - -
<----------------200 OK---------------------+
m=audio 9158 RTP/AVP 118
a=rtpmap:118 PCMA/8000
a=sendrecv
In the last 200OK Client is sending a Payload type (118) which was not
offered in the Re-Invite. The Re-Invite is generated when the SIP
Server
is
detecting a fax transmission and applies ITU V.152 (Voice Band Data),
this
is also how gpmd Attribute is introduced.
The SIP Client vendor commented this on the case:
*"after call is answered (media session is established), provider
renegotiates codec set and changes PCMA codec description bound to
payload
8 with the description which was bound to payload 118 in initial
negotiation of media session.*
*It causes conflict, because new description of PCMA codec is already
bound
to payload 118 in initial offer/answer.*
*Voip provider can configure own side of trunk and avoid usage of
non-standard extensions in payload description (remove unnecessary
duplication of codecs). Also, provider need to preserve payload
definitions
when renegotiate media session."*
So is the vendor right by saying that payload description have to be
preserved during a session? It did not find this in the SDP
offer/answer
RFCs.
We never saw any other vendor having issues with this signalling.
Best Regards
Philipp Schöning
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
