Hi,
>>> complete treatment, see
>>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt
>> where you write in 4.2.5. Subsequent Offers and Answers:
>>
>> o In the o-line, only the version number may change, and if it
>> changes it must increment by one from t
Beware that there is a some confusion in this thread. In particular,
the SDP that we've been discussing is from Manjunath Warad's message
of Mon, 06 Aug 2007 11:19:24 +0530, in which he states:
I have strong doubt on the SDP that is exchanged in 200 of
Re-INVITE. Answerer has added other
Valentin Nechayev wrote:
>> Stefan Sayer <[EMAIL PROTECTED]> wrote:
>
>>> complete treatment, see
>>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt
>> where you write in 4.2.5. Subsequent Offers and Answers:
>
>> o In the o-line, only the version number
> Stefan Sayer <[EMAIL PROTECTED]> wrote:
>> complete treatment, see
>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-02.txt
> where you write in 4.2.5. Subsequent Offers and Answers:
> o In the o-line, only the version number may change, and if it
> cha
From what I can see of the example below there is only one problem -
the version number in the 2nd answer should have been incremented.
As written, the offerer could proceed on the assumption that the answer
has not changed. In this case that would do no harm. In some other cases
it might.
Stefan,
Sorry I misunderstood your level of research.
The version number should be incremented if the sdp is different from
the prior one sent in the same direction, whether this is in the offer
or the answer. It *should* remain unchanged if the rest of the sdp is
unchanged. (But I think there
[EMAIL PROTECTED] wrote:
> In regard to how the answer may be different from the offer, the rules
> are in section 6.1 of RFC 3264. In many cases, the answerer may add
> media formats. E.g.,
>
>For streams marked as sendrecv in the answer, the "m=" line MUST
>contain at least one codec t
Paul Kyzivat wrote:
> Dale has covered this. For the original poster, Stefan: there is a lot
> of written information on this subject that you don't seem to be
> familiar with. The most obvious are RFCs 3261 and 3264. For a more
I wonder how I made the impression to not be familiar with 3264, a
Dale has covered this. For the original poster, Stefan: there is a lot
of written information on this subject that you don't seem to be
familiar with. The most obvious are RFCs 3261 and 3264. For a more
complete treatment, see
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswe
From: Stefan Sayer <[EMAIL PROTECTED]>
The offerer may change the stream, but the answerer?
Uh, yes. I answered a different question than was asked.
In regard to how the answer may be different from the offer, the rules
are in section 6.1 of RFC 3264. In many cases, the answerer may add
Hello,
[EMAIL PROTECTED] wrote:
>From: Manjunath Warad <[EMAIL PROTECTED]>
>
>I have strong doubt on the SDP that is exchanged in 200 of
>Re-INVITE. Answerer has added other media formats that he supports and I
>don't think offerer would support those and hence offerer could be
>
From: Manjunath Warad <[EMAIL PROTECTED]>
I have strong doubt on the SDP that is exchanged in 200 of
Re-INVITE. Answerer has added other media formats that he supports and I
don't think offerer would support those and hence offerer could be releasing
the call by sending ACK and BYE.
D]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Saturday, August 04, 2007 1:51 PM
To: Sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] RE-INVITE Problem [packet capture inside]
Here's the hole call flow:
INVITE->TRYING->Ringing->OK->ACK
RE-INV
Here's the hole call flow:
INVITE->TRYING->Ringing->OK->ACK
RE-INVITE->OK->ACK..generated BYE->ACK
[FIRST INVITE]
Session Initiation Protocol
Request-Line: INVITE sip:[EMAIL PROTECTED] SIP/2.0
Method: INVITE
[Resent Packet: False]
Message Header
Record-Route:
Can you also attach the original INVITE call flow along with re-INVITE?
That can help to compare the SDP versions, CSeq etc.
Also, if everything turns out to be OK, then there may be some policy (private)
based on which it might be rejecting!
Somesh
[EMAIL PROTECTED] wrote: Hi,
I'm havin a pr
15 matches
Mail list logo
