On 1/22/21 7:55 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
[snip]
As you can see the offer in initial INVITE have payload type 100: a=rtpmap:100
AMR/8000
The offer in 200OK also have payload-type 100, but now it is: a=rtpmap:100
telephone-event/8000
I believe that this is causing failure when B-side (VoLTE-phone) is sending
TelephoneEvent(DTMF) to A-side (UAC)
Do you think A-side should adapt or maybe reject the offer in 200OK or do
something else ?
RFC3264 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. For example, if A generates an offer
with G.711 assigned to dynamic payload type number 46, payload type
number 46 MUST refer to G.711 from that point forward in any offers
or answers for that media stream within the session. "
I compared the two SDPs and find that there aren't *any* codec+fmtp sets
that match. So this is messed up. But you haven't provided enough
information to fully decipher what is going on. We need to see the
answer to the first invite. The restrictions of rfc3264 section 8.3.2
pertain to the PT values used by a particular endpoint. (It is
permissible to use different PTs on the two ends.) But in this case
there isn't anything that could be in that first answer that could
render this second answer valid.
Regarding whether the A-side should adapt or reject: this is an
implementation decision. The specs don't specify behavior for
non-conforming usage. Or course there is also the problem that you can't
reject an answer. All you can do is try sending another offer, or else
terminate the call.
It isn't entirely clear what you could try in order to carry on while
accepting this 2nd answer. You could start sending using one or more of
the codecs in the answer, but it is unclear what you would expect to
receive.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
