Hi,
If INVITE request contains a SDP with protocol version as 1 shown
below. Is that req is valid??
[REQ]
*v=1 *
o=2647 2647 2647 IN IP4 107.108.81.156
s= some value
t=some value
.
.
But i have gone through some RFC's they are stating this
v=0
The "v=" field gives the version of the
I guess this is a little confusing, and the language may not be as
precise as it could be.
When you send the initial dialog establishing request you need to create
some state for the "pending" dialog. Its sort of a "half-dialog" since
you are waiting for a response to complete it.
When you rec
On 3/21/12 3:36 PM, Bob Penfield wrote:
> I see your point, but even in the scenario you describe, there is a re-INVITE
> that would convey to the UA updated capabilities. It is OK for this stuff to
> change during the dialog, but the UAs have to rely on those changes being
> communicated in sig
I see your point, but even in the scenario you describe, there is a re-INVITE
that would convey to the UA updated capabilities. It is OK for this stuff to
change during the dialog, but the UAs have to rely on those changes being
communicated in signaling. Otherwise, there is no point at looking
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 they hold.
We could *try* to tighten these up, but doing so
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
In that case the change can be communicated in the signaling be having UPDATE
absent from the Allow header in the 200-OK and/or ACK. My point is that if the
most recent signaling message (INVITE and/or 18x) included UPDATE in the allow
header, then the other end ought to be able to send UPDATE w
Mia,
The UPDATE is sent for session refresh. It can be done using re-INVITE but
RFC 4028 recommends using UPDATE.
"A re-INVITE generated to refresh the session is a normal re-INVITE,
and an UPDATE generated to refresh a session is a normal UPDATE. If
a UAC knows that its peer supports the 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 used instead."
Regards,
Mia
-Original Message-
From: sip-implementors-b
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
>
> I guess that d
>From these threads, we can infer that Allow header may carry different
content at different times of the dialog. But the base rule to be followed
could be as follows.
UA1 -> UA2
INVITE sip:b...@biloxi.com SIP/2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDA
Also, as per 3261 the Allow header present in provisional is valid untill
the dialog is in early state.
Header fields present in a provisional
response are applicable as long as the dialog is in the early state
(for example, an Allow header field in a provisional response
contains the
I guess that depends on your interpretation of integral to the usage. If the UA
is using UPDATE which includes SDP to modify the session parameters, it is
important for that session. What is the UA supposed to do? It was told that it
could use UPDATE, so it did. Is it supposed to try UPDATE and
As here 18x will create an 'early dialog', which would be clone of previous
one. So, the CSeq here should be '2'.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction (excepting ACK and CANCEL of
If UPDATE was integral to the INVITE usage, it would have been defined within
RFC 3261.
> -Original Message-
> From: Bob Penfield [mailto:bpenfi...@acmepacket.com]
> Sent: Wednesday, March 21, 2012 8:50 AM
> To: Brett Tate; Kashif Husain; sip-implementors@lists.cs.columbia.edu
> Subject:
> 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
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
scenario since support for the NOTIFY method is required by the
usage. In this case, the UA knows t
> 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
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.
cheers,
(-:bob
-Original Message-
From: sip-i
On Wed, Mar 21, 2012 at 2:58 PM, Vinay V wrote:
> Hi All,
>
>I wanted clarification regarding the following section in
> RFC 3261.
>
>
> 13.2.2.4 2xx Responses
>
>
>
> Multiple 2xx responses may arrive at the UAC for a single INVITE
>
> request due to a forking proxy. Each re
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
On Wed, Mar 21, 2012 at 7:51 AM, Vineet Menon wrote:
> Thanks everyone...
> I was thinking of a network load balancer..with DNS query...
> response code 3xx seems to be a nicer optionbut as they say..sending a
> 3xx also needs resources.everything comes to a standstill after
> a particular
Hi All,
I wanted clarification regarding the following section in
RFC 3261.
13.2.2.4 2xx Responses
Multiple 2xx responses may arrive at the UAC for a single INVITE
request due to a forking proxy. Each response is distinguished by
the tag parameter in the To heade
Thanks everyone...
I was thinking of a network load balancer..with DNS query...
response code 3xx seems to be a nicer optionbut as they say..sending a
3xx also needs resources.everything comes to a standstill after
a particular point...
What I want to say is that by issuing 503 or 3xx respo
24 matches
Mail list logo
