I'd say the proper way to look at this problem is the common-sense
one. A B2BUA should strive to make sure that the UA on each side has
most recently seen Allow* headers that reflect the capabilities that
the UA can access. But a UA can't depend on that, and so while it is
reasonable for it to pl
Sent: Wednesday, March 21, 2012 12:06 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] 405 response for UPDATE
>
> Ahh, you found an old email of mine. :-)
>
> There are many of these things in sip where support for *something* is
> declared somewhere. For the most
@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] 405 response for UPDATE
Ahh, you found an old email of mine. :-)
There are many of these things in sip where support for *something* is
declared somewhere. For the most part there is no guarantee how long
this support is promised to remain, or in what scopes
case, then the Allow header is useless.
>>
>> It just does not make sense.
>>
>>
>> cheers,
>> (-:bob
>>
>>
>>
>>
>> -Original Message-
>> From: Brett Tate [mailto:br...@broadsoft.com]
>> Sent: Wednesday, March 21, 20
There was a discussion a while back to establish exactly the scope of
validity of the infomration carried in the Allow-* headers. We
finally decided that no clear definition could be made.
In any case, the UA has to be prepared for the failure of any request.
In the case of an UPDATE, clearly it
@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] 405 response for UPDATE
Hi,
I suppose your far-end entity supports UPDATE for early dialogs, but not after
the dialog is confirmed, as RFC 3311 says:
"Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a
re-INVITE be
.@lists.cs.columbia.edu] On Behalf Of Kashif Husain
> Sent: Wednesday, March 21, 2012 1:33 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] 405 response for UPDATE
>
> Hello SIP implementors,
>
> I have a far-end entity which sends UPDATE in Allo
plementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Kashif
Husain
Sent: Wednesday, March 21, 2012 1:33 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] 405 response for UPDATE
Hello SIP implementors,
I have a far-
Hi Bob,
Reply inline.
> -Original Message-
> From: Bob Penfield [mailto:bpenfi...@acmepacket.com]
> Sent: Wednesday, March 21, 2012 9:26 AM
> To: Brett Tate; Kashif Husain; sip-implementors@lists.cs.columbia.edu
> Subject: RE: [Sip-implementors] 405 response for UPDATE
&g
cluded an Allow header, how is the UA supposed to know that it is
> > not OK now? If that is the case, then the Allow header is useless.
> >
> > It just does not make sense.
> >
> >
> > cheers,
> > (-:bob
> >
> >
> >
> >
> > -Original
> To: Bob Penfield; Kashif Husain; sip-implementors@lists.cs.columbia.edu
> Subject: RE: [Sip-implementors] 405 response for UPDATE
>
> If UPDATE was integral to the INVITE usage, it would have been defined
> within RFC 3261.
>
> > -Original Message-
> > From:
just does not make sense.
cheers,
(-:bob
-Original Message-
From: Brett Tate [mailto:br...@broadsoft.com]
Sent: Wednesday, March 21, 2012 8:52 AM
To: Bob Penfield; Kashif Husain; sip-implementors@lists.cs.columbia.edu
Subject: RE: [Sip-implementors] 405 response for UPDATE
If UPDATE was
du
> Subject: RE: [Sip-implementors] 405 response for UPDATE
>
> Then does that mean the RFC 5057 is incorrect when it says:
>
>(3) 405 Method Not Allowed:
>
>501 Not Implemented:
>
> Either of these responses would be aberrant in our example
>
> No, it is not valid behavior. The Allow header should contain only
> methods that are "allowed" and supported by the UA. It is particularly
> problematic when you consider that RFC 5057 indicates that a 405
> response destroys the INVITE usage.
As the following RFC 5057 snippet indicates, only t
Brett Tate
Sent: Wednesday, March 21, 2012 8:46 AM
To: Kashif Husain; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] 405 response for UPDATE
> Is this a valid behavior?
> Is it allowed to send 405 in this scenario?
Yes; the behavior is valid. Just because UPDA
> Is this a valid behavior?
> Is it allowed to send 405 in this scenario?
Yes; the behavior is valid. Just because UPDATE was allowed, it doesn't mean
that it must continue to be allowed.
However, the behavior that you are describing is more prevent with B2BUAs
reconnecting dialogs that do an
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Kashif
Husain
Sent: Wednesday, March 21, 2012 8:33 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] 405 response for UPDATE
Hello SIP implementors,
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
18 matches
Mail list logo
