Much appreciated, thanks !
I have added some more info.
pCSCF --------- VoLTE-phone
INVITE ->
With SDP offer
<- 180 Ringing
<- 200OK with SDP answer
ACK ->
re-INVITE ->
without SDP
<- 200OK with SDP Offer
ACK ->
With SDP answer
SDP in initial INVITE
SDP PDU
v=0
o=- 805658488335263 1704590316 IN IP6 2A02:1400:10:1C::4
s=-
c=IN IP6 2a02:1400:10:1::4
t=0 0
m=audio 5394 RTP/AVP 108 102 8 100 96 0 116 111
b=AS:141
a=rtpmap:108 AMR/8000
a=fmtp:108 mode-set=7; mode-change-period=2; mode-change-capability=2;
mode-change-neighbor=1; max-red=0
a=rtpmap:102 AMR/8000
a=fmtp:102 mode-set=7; max-red=0
a=rtpmap:8 PCMA/8000
a=rtpmap:100 AMR/8000
a=fmtp:100 mode-change-period=2; mode-change-capability=2;
mode-change-neighbor=1; max-red=0
a=rtpmap:96 AMR/8000
a=fmtp:96 max-red=0
a=rtpmap:0 PCMU/8000
a=rtpmap:116 telephone-event/8000
a=ptime:20
a=maxptime:20
a=rtpmap:111 telephone-event/16000
SDP in 200OK from VoLTE-phone with SDP as answer on initial INVITE
o=sip:+46708xxx...@ims.mnc008.mcc240.3gppnetwork.org 1611316978 0 IN
IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
s=-
c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
t=0 0
a=sendrecv
m=audio 49120 RTP/AVP 108 116
b=AS:37
b=RS:462
b=RR:1387
a=rtpmap:108 AMR/8000
a=fmtp:108 mode-set=7; max-red=0; mode-change-capability=2;
mode-change-period=2; mode-change-neighbor=1
a=rtpmap:116 telephone-event/8000
a=fmtp:116 0-15
a=ptime:20
a=maxptime:20
a=sendrecv
SDP in 200OK from VoLTE-phone with SDP offer as answer on INVITE without SDP
SDP PDU
v=0
o=sip:+46708xxxx...@ims.mnc008.mcc240.3gppnetwork.org 1611316978 1 IN
IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
s=-
c=IN IP6 2a02:1400:df:245d:435:1205:68e0:1ac3
t=0 0
a=sendrecv
m=audio 49120 RTP/AVP 109 104 110 102 108 105 100
b=AS:50
b=RS:625
b=RR:1875
a=rtpmap:109 EVS/16000
a=fmtp:109 br=13.2-24.4; bw=nb-wb; max-red=0; cmr=-1; ch-aw-recv=-1
a=rtpmap:104 AMR-WB/16000
a=fmtp:104 max-red=220; mode-change-capability=2
a=rtpmap:110 AMR-WB/16000
a=fmtp:110 octet-align=1; max-red=220; mode-change-capability=2
a=rtpmap:102 AMR/8000
a=fmtp:102 max-red=220; mode-change-capability=2
a=rtpmap:108 AMR/8000
a=fmtp:108 octet-align=1; max-red=220; mode-change-capability=2
a=rtpmap:105 telephone-event/16000
a=fmtp:105 0-15
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:20
a=maxptime:20
a=sendrecv
ACK with SDP as answer on offer from VoLTE-phone
SDP PDU
v=0
o=- 805658488335263 1704590317 IN IP6 2A02:1400:10:1C::4
s=-
c=IN IP6 2a02:1400:10:1::4
t=0 0
m=audio 5394 RTP/AVP 104 105
b=AS:54
a=rtpmap:104 AMR-WB/16000
a=fmtp:104 mode-set=0,1,2; mode-change-period=2;
mode-change-capability=2; mode-change-neighbor=1; max-red=0
a=rtpmap:105 telephone-event/16000
a=ptime:20
a=maxptime:40
BR/pj
-----Original Message-----
From: Paul Kyzivat <pkyzi...@alum.mit.edu>
Sent: den 22 januari 2021 16:31
To: Sundbaum Per-Johan (Telenor Sverige AB) <per-johan.sundb...@telenor.se>;
sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] reuse of payload type
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
Sensitivity: Internal
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
