That seems also like very good sense, Thanks !
BR/pj
Sensitivity: Internal
-Original Message-
From: Dale R. Worley
Sent: den 23 januari 2020 04:21
To: Sundbaum Per-Johan (Telenor Sverige AB)
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP version
"Sundbaum Per-Johan (Telenor Sverige AB)"
writes:
> What do you think about incrementing the version in SDP o-line, but
> not changing anything else in SDP, should such a behavior be accepted
> or should it be rejected ?
There are two similar but distinctly different questions that you might
be
And may I add that I agree on your "never trust" point of view !
Great, Thanks !
:-)
Den 22 jan. 2020 18:59 skrev Paul Kyzivat :
You can find the definitive statement you are looking for in Section 8
of RFC3264:
... When issuing an offer that modifies the session,
the "o=" line of the
Great, Thanks !
:-)
Den 22 jan. 2020 18:59 skrev Paul Kyzivat :
You can find the definitive statement you are looking for in Section 8
of RFC3264:
... When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except
You can find the definitive statement you are looking for in Section 8
of RFC3264:
... When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from
Hi !
I'm in IMS operations and sometimes I get stuck in the crossfire between
different vendors !
The two SDP's are identical except the version-number, I have checked.
For the moment it seems that most of our nodes are accepting that version is
incremented without session has changed in any
Hi !
I don't think that there are any requirements to do that, but never the less
there are implementations that are doing it, accidentally I guess.
Thanks !
BR/pj
From: Rohit Jain
Sent: den 22 januari 2020 12:36
To: Sundbaum Per-Johan (Telenor Sverige AB)
Cc:
Sorry, but I'm too lazy to compare those two messages byte by byte to
see if they are identical other than the version number.
I don't understand the point of your question. Are you looking for an
excuse to increment the version number without checking if the SDP has
changed?
There is a
Sorry for the no good picture !
SDP in 200OK for initial INVITE from PBX
SDP PDU
v=0
o=- 195986 1 IN IP4 10.81.253.92
s=RFC3264OfferAnswerExchange
c=IN IP4 10.81.253.92
b=CT:1000
t=0 0
m=audio 23812 RTP/AVP 8 110
c=IN IP4 10.81.253.92
a=rtpmap:8 PCMA/8000
a=rtpmap:110 telephone-event/8000
Hi,
SIP entities (client/server) checks SDP version to determine whether there
is any change in SDP from previously received SDP. If the version is
changed then they go on to parse the entire SDP to determine the change.
Based on that SIP entity can initiate media processing(more relevant in
case
Hi !
What do you think about incrementing the version in SDP o-line, but not
changing anything else in SDP,
should such a behavior be accepted or should it be rejected ?
RFC 4028 states that such behavior at least should be avoided, but is that true
also for UA without support for timer ?
"
11 matches
Mail list logo
