On 8/8/16 4:32 PM, Manolis Katsidoniotis wrote:
Thanks for the fast answer!
I've been unable to find an SDP version reference though...
For instance this looks very vague ...
Therefore, session parameters in
the offer/answer exchange SHOULD be as close to those in the
pre-re-INVITE state as possible.
As far as I know the session version only goes forward.
In new offer,,,
session version should be 3,,, or not?
I agree that the version should be 3 in this case. But I can't think of
a spec that clearly specifies this. I do recall it being discussed
before, but not where.
Thanks,
Paul
thanks
Manolis
On Mon, Aug 8, 2016 at 1:00 PM Volkan Hatem <[email protected]> wrote:
Rfc6141 might help.
On 08 Aug 2016, at 20:45, Manolis Katsidoniotis <[email protected]>
wrote:
Hello
Haven't been able to find a reference to this scenario.
(convert to Courier or "fixed width font" to see properly)
UEA UEB
| -------------> |
| INV SDP offer |
| version 1 |
| |
| <------------- |
| 200 OK SDP answer |
| |
| |
| -------------> |
| INV new SDP offer |
| version 2 |
| |
| <------------- |
| 606 Not Acceptable |
| |
| |
| -------------> |
| INV new SDP offer |
| version no? |
| |
| |
What should be the version of the new offer?
My impression is 3 (version should always increase) but in a related call
flow
I have received an answer that says
"fallback to previous state also means previous version number
so in new offer previous version is increased by 1
so new version should also be 2 ....
Anybody has any rfc references at hand?
Thanks
Manolis
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
