Thanks, makes sense!
On Thu, Sep 17, 2015 at 10:02 PM, Brett Tate wrote:
> Hi,
>
> The UAC is violating the "MUST ignore". It is an SDP which MUST be ignored.
> Thus it is irrelevant what the UAS sends unless interacting with devices
> that ignore the "MUST ignore". However for interoperability
Hi,
The UAC is violating the "MUST ignore". It is an SDP which MUST be ignored.
Thus it is irrelevant what the UAS sends unless interacting with devices
that ignore the "MUST ignore". However for interoperability reasons, the
UAS can change their behavior. If I remember correctly, RFC 6337 migh
Hi
Correct I forgot to mention that the initial INVITE contains SDP and
it's a single dialog.
RFC3261 section 13.2.1
If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that i
Hi,
I assume that the INVITE contained an SDP and your example truly reflects
a single dialog (i.e. 18x/2xx To tags are the same).
According to RFC 3261 section 13.2.1, the SDP modification must be
ignored. Thus it shouldn't cause the call to be released. With that
said, some devices have confi
Hi list
I'm seeing the following behavior from an Aastra 400 PBX.
Flow below is ITSP to PBX
INVITE>
<100Trying
<183 w/SDP
PRACK>
<200OK (PRACK)
<180 w/SDP
>PRACK
<200OK (PRACK)
<200OK (INVITE)w/SDP
ACK>
BYE>
<200OK (BYE)
Each time the PBX sends an SDP, the version number is incremented even
tho
