ponse
without prompting the user)."
On Tue, 24 Sep 2019, 03:17 Kashif Husain, wrote:
> You can check for SDP version of re-Invite, if its same as previous one
> then its usually intended for session refresh.
>
> Thanks,
> -kashif
>
> On Tue, 24 Sep 2019, 02:30 Sundbau
You can check for SDP version of re-Invite, if its same as previous one
then its usually intended for session refresh.
Thanks,
-kashif
On Tue, 24 Sep 2019, 02:30 Sundbaum Per-Johan (Telenor Sverige AB), <
per-johan.sundb...@telenor.se> wrote:
> Hi !
> Can anybody help me find relevant RFC/other
Hello all,
We have a scenario where my endpoint receives multiple crypto in the offer
it selects two of them responds with them in the answer:
Offer:
a=crypto:1 AES_CM_256_HMAC_SHA1_32
inline:raAXCEI2rA+J7VjZo2Z906Lwa+KHSUAW407zRJYwNOSVW5o2HtrdTyI9kq7mnA==|2^31
a=crypto:2 AES_CM_256_HMAC_SHA1_80
I have seen the similar issue with a Polycom video phones. By the time
Polycom fixed it, we were just ignoring the duplicate payload number to
have a+v call.
Thanks,
-kashif
*"All you need is ignorance and confidence and success is sure."*
-Mark Twain
On Tue, Sep 18, 2012 at 10:39 AM, Gaurav K
d, as RFC 3311 says:
> "Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that
> a re-INVITE be used instead."
>
> Regards,
> Mia
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:
> sip-implementors-boun..
Hello SIP implementors,
I have a far-end entity which sends UPDATE in Allow header but when I send
UPDATE for session refresh I get 405 Method Not Allowed.
Is this a valid behavior? Is it allowed to send 405 in this scenario? If
yes then I would like know the reason behind it.
Thank you very muc
