rsw2111 writes:
> 4028 is clear that the supported header in the initial INVITE indicates
> whether or not refreshers are supported by the UAC. In this case, there is
> no Supported header in the initial INVITE, so it can be assumed that the
> A-side does not support refreshers. That being the cas
Hi Brett,
Thanks a lot for your help.
On Thu, Feb 12, 2015 at 2:55 AM, Brett Tate wrote:
> > Can you pleae advise if we can send the re-invite with
> > new codec.
>
> You can offer it; however the UAS might reject it.
>
> RFC 3264 section 8 discusses session modification.
>
> RFC 6337 section 5
On 2/11/15 4:17 PM, rsw2111 wrote:
4028 is clear that the supported header in the initial INVITE indicates
whether or not refreshers are supported by the UAC. In this case, there is
no Supported header in the initial INVITE, so it can be assumed that the
A-side does not support refreshers. That
Hi,
Thanks for the response.
We have asked the supplier to explain the 480, but I'm asking more as a
question of sip rfc compliance with regards to the reinvite
i'm not sure what you mean by this:
"Concerning RFC 4028, the session expiration stuff is negotiated again with
every re-INVITE and UPD
> i'm not sure what you mean by this:
> "Concerning RFC 4028, the session expiration stuff
> is negotiated again with every re-INVITE and UPDATE"
It means that the session expiration activation, deactivation, et cetera can
basically change with every successful re-INVITE or UPDATE.
> 4028 is clea
> Can you pleae advise if we can send the re-invite with
> new codec.
You can offer it; however the UAS might reject it.
RFC 3264 section 8 discusses session modification.
RFC 6337 section 5.1 also indicates the following.
"A UA should send an offer that indicates what it, and its user, are
int
