Oleksandr,
On 1/17/19 3:47 AM, Oleksandr Fadieiev wrote:
Hello dear team.
Could you please help determine if RFC 3264 violated in the following
scenario?
Unfortunately, I wasn’t able to find appropriate email thread to answer my
question.
And I'm sorry for lengthy explanation.
Scenario.
1)
PartyA creates a dialog to SIP Server (further – “SIPS”; it is B2BUA;
application server; it does not generate SDP by itself, only re-sends the
offers between the parties)
2)
SIPS creates a dialog to PartyB
3)
Offer from PartyA:
“v=0
o=Sonus_UAC 11094 21605 IN IP4 10.113.254.130
s=SIP Media Capabilities
c=IN IP4 10.113.254.130
t=0 0
m=audio 27282 RTP/AVP 8 18 2 102
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=sendrecv
a=ptime:20”
Please note that *102* is mapped to telephone-event
4)
Offer from PartyB:
“v=0
o=- 272923319 1 IN IP4 10.113.248.23
s=phone-call
c=IN IP4 10.113.248.23
t=0 0
m=audio 14530 RTP/AVP 8 102
a=rtpmap:8 pcma/8000
a=ptime:20
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=sendrecv”
5)
Session is started, no issues
6)
SIPS now ends the dialog to PartyB and creates new one to PartyC
7)
Dialog between PartyA and SIPS remains
8)
PartyC in INVITEd with no SDP and responds with its offer:
“v=0
o=- 272961713 1 IN IP4 10.113.248.24
s=phone-call
c=IN IP4 10.113.248.24
t=0 0
m=audio 11688 RTP/AVP 8 101
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv”
Please note, now *101* is mapped to telephone-event
9)
This offer is used in the re-INVITE towards Party A
Can you please tell if “old” mapping of 102-to-telephone-event should be
present in this re-INVITE?
---
My opinion is that mapping may be absent and no RFC violation happens.
I agree with you.
While my opponent says that because of the following quote:
“8.3.2 Changing the 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”
From my point of view, “mapping” is not violated in terms that 102 was NOT
mapped to some different codec like g711; this mapping was simply omitted.
Yes. While a particular PT can't be mapped to a different codec, a coded
*may* be mapped to a different PT.
And it is allowed to add, remove media formats as well as map multiple
numbers to the same codec.
Agree.
---
Could you please tell if, in the given scenario, the mapping of
102-to-telephone-event should (MUST?) be present in the subsequent
re-negotiations with PartyA?
Can you please also tell the meaning of “mapping from a particular dynamic
payload type
number to a particular codec” from RFC?
Does it mean that once number-to-codec mapping appears it must not be
changed as a mapping fact?
Or does it mean that it also has to be present in all further offers?
See above - I agree with your interpretation.
BUT!!! SIPS is living dangerously in step (8) above. By sending an
offerless invite to a new party that has no knowledge of the existing PT
mappings in the session with PartyA it is running a huge risk that
PartyC *will* use PTs in an inconsistent way.
To avoid this it has a couple of options:
1) include an offer in the invite to partyC, consistent with the PT
mappings in the session with PartyA. (Note that this isn't a total
solution. If some PT mappings were established earlier in the session
with PartyA but are not currently in use at the time of the call to
PartyC then there is no way to communicate those.)
2) if SIPS receives an offer or answer that conflicts with established
mappings on the other side, then send an INVITE/Replaces to the other
side rather than a re-INVITE.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
