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, as
[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 the
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
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 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
changes it must
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 may change, and if
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
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 the one
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
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
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.
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
12 matches
Mail list logo
