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
"Sundb
"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 a
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 ne
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 th
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 t
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 o
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: sip-implementors@lists.cs.columbia
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 fine
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
a=fm
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 ?
" RFC
11 matches
Mail list logo