Re: [Sip-implementors] SDP version
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 asking. The general principle is "Be conservative in what you produce and liberal in what you accept." If the question is, "Should a device increment the version in an SDP o-line but not change anything else?", as you note RFC 4028 says that a device should not do that. If the question is, "If a device receives SDP with an incremented version in the o-line that is otherwise identical to the preceding SDP, should it reject it?", the device should not reject it. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
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 asking. The general principle is "Be conservative in what you produce and liberal in what you accept." If the question is, "Should a device increment the version in an SDP o-line but not change anything else?", as you note RFC 4028 says that a device should not do that. If the question is, "If a device receives SDP with an incremented version in the o-line that is otherwise identical to the preceding SDP, should it reject it?", the device should not reject it. Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version
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 new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. ... Now you have a MUST you can point to. (Nevertheless, in any code that I write I would never trust this!) Good luck, Paul On 1/22/20 11:09 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: > 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 other way, but > we have a vendor that are claiming that it's a violation of RFC 4028 - > Session Timer and also claims that that violation is causing problems, so far > a bit unclear why and what, could be some kind of misunderstanding, but I > have also colleagues that are arguing that RFC 4028 is only valid for UA > with support for timer. > > I think your view on the matter makes very good sense ! > > Thanks ! > > BR/pj > > > Sensitivity: Internal > Sensitivity: Internal > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > On Behalf Of Paul Kyzivat > Sent: den 22 januari 2020 16:25 > To: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] SDP version > > 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 line here between what is required behavior, what is good > practice, what is considerate, ... > > It really is a savings for the recipient of the SDP if he can avoid parsing > it. And generally it should be easier for the sender to "know" > that the SDP is unchanged and so indicate that when sending it. It is a bit > harder for the recipient to determine that. OTOH, as an implementor I'm not > very trusting and so am inclined to not trust that it is unchanged without > checking. Even so there are ways to take advantage of that indication without > trusting it. (If the version # is the same as prior then do a string > comparison of the two SDPs to verify. If the version #s are different, then > simply start parsing the SDP without bothering with the comparison.) > > And we shouldn't second guess what optimizations a peer may or may not want > to do. > > I guess the worst case is a situation where you would normally generate the > SDP from scratch for every message and so not have an easy way to tell if it > has changed. Then it becomes a question of whether you do the extra work to > determine changed or not, or force extra work on the recipient. I think you > should do it. > > The session timer connection is, IMO, a red herring. That draft is poorly > written, in that it seems to imply that an invite for session timer is > mutually exclusive with one for offer/answer. The two processes share > messages and can coexist or not. > >Thanks, >Paul > > On 1/22/20 6:50 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: >> 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=fmtp:110 0-15 >> a=sendrecv >> a=ptime:20 >> >> >> SDP in re-INVITE from PBX >> SDP PDU >> v=0 >> o=- 195986 2 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=fmtp:110 0-15 >> a=sendrecv >> a=ptime:20 >> >> 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.edu >> Subject: Re: [Sip-implementors] SDP version >> >> 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 >> of servers) or just relay the messag
Re: [Sip-implementors] SDP version
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 that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. ... Now you have a MUST you can point to. (Nevertheless, in any code that I write I would never trust this!) Good luck, Paul On 1/22/20 11:09 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: > 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 other way, but > we have a vendor that are claiming that it's a violation of RFC 4028 - > Session Timer and also claims that that violation is causing problems, so far > a bit unclear why and what, could be some kind of misunderstanding, but I > have also colleagues that are arguing that RFC 4028 is only valid for UA > with support for timer. > > I think your view on the matter makes very good sense ! > > Thanks ! > > BR/pj > > > Sensitivity: Internal > > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu > On Behalf Of Paul Kyzivat > Sent: den 22 januari 2020 16:25 > To: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] SDP version > > 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 line here between what is required behavior, what is good > practice, what is considerate, ... > > It really is a savings for the recipient of the SDP if he can avoid parsing > it. And generally it should be easier for the sender to "know" > that the SDP is unchanged and so indicate that when sending it. It is a bit > harder for the recipient to determine that. OTOH, as an implementor I'm not > very trusting and so am inclined to not trust that it is unchanged without > checking. Even so there are ways to take advantage of that indication without > trusting it. (If the version # is the same as prior then do a string > comparison of the two SDPs to verify. If the version #s are different, then > simply start parsing the SDP without bothering with the comparison.) > > And we shouldn't second guess what optimizations a peer may or may not want > to do. > > I guess the worst case is a situation where you would normally generate the > SDP from scratch for every message and so not have an easy way to tell if it > has changed. Then it becomes a question of whether you do the extra work to > determine changed or not, or force extra work on the recipient. I think you > should do it. > > The session timer connection is, IMO, a red herring. That draft is poorly > written, in that it seems to imply that an invite for session timer is > mutually exclusive with one for offer/answer. The two processes share > messages and can coexist or not. > >Thanks, >Paul > > On 1/22/20 6:50 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote: >> 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=fmtp:110 0-15 >> a=sendrecv >> a=ptime:20 >> >> >> SDP in re-INVITE from PBX >> SDP PDU >> v=0 >> o=- 195986 2 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=fmtp:110 0-15 >> a=sendrecv >> a=ptime:20 >> >> 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.edu >> Subject: Re: [Sip-implementors] SDP version >> >> 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 >> of servers) or just relay the message without any media level processing. If >> just the version number is incremented but t
Re: [Sip-implementors] SDP version
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 the previous SDP. If the version in the origin
line does not increment, the SDP MUST be identical to the SDP with
that version number. ...
Now you have a MUST you can point to.
(Nevertheless, in any code that I write I would never trust this!)
Good luck,
Paul
On 1/22/20 11:09 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
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 other way, but
we have a vendor that are claiming that it's a violation of RFC 4028 - Session
Timer and also claims that that violation is causing problems, so far
a bit unclear why and what, could be some kind of misunderstanding, but I have
also colleagues that are arguing that RFC 4028 is only valid for UA
with support for timer.
I think your view on the matter makes very good sense !
Thanks !
BR/pj
Sensitivity: Internal
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
On Behalf Of Paul Kyzivat
Sent: den 22 januari 2020 16:25
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP version
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 line here between what is required behavior, what is good
practice, what is considerate, ...
It really is a savings for the recipient of the SDP if he can avoid parsing it. And
generally it should be easier for the sender to "know"
that the SDP is unchanged and so indicate that when sending it. It is a bit
harder for the recipient to determine that. OTOH, as an implementor I'm not
very trusting and so am inclined to not trust that it is unchanged without
checking. Even so there are ways to take advantage of that indication without
trusting it. (If the version # is the same as prior then do a string comparison
of the two SDPs to verify. If the version #s are different, then simply start
parsing the SDP without bothering with the comparison.)
And we shouldn't second guess what optimizations a peer may or may not want to
do.
I guess the worst case is a situation where you would normally generate the SDP
from scratch for every message and so not have an easy way to tell if it has
changed. Then it becomes a question of whether you do the extra work to
determine changed or not, or force extra work on the recipient. I think you
should do it.
The session timer connection is, IMO, a red herring. That draft is poorly
written, in that it seems to imply that an invite for session timer is mutually
exclusive with one for offer/answer. The two processes share messages and can
coexist or not.
Thanks,
Paul
On 1/22/20 6:50 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
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=fmtp:110 0-15
a=sendrecv
a=ptime:20
SDP in re-INVITE from PBX
SDP PDU
v=0
o=- 195986 2 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=fmtp:110 0-15
a=sendrecv
a=ptime:20
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.edu
Subject: Re: [Sip-implementors] SDP version
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 of
servers) or just relay the message without any media level processing. If just
the version number is incremented but there is no actual change in SDP, then it
will trigger unnecessary processing on the receiver, so it should be avoided.
Also can you specify what could be the requirement ("but is that true also for UA
without support for timer") in which it is required to increment the SDP version
number without any actual change in SDP.
P
Re: [Sip-implementors] SDP version
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 other way, but
we have a vendor that are claiming that it's a violation of RFC 4028 - Session
Timer and also claims that that violation is causing problems, so far
a bit unclear why and what, could be some kind of misunderstanding, but I have
also colleagues that are arguing that RFC 4028 is only valid for UA
with support for timer.
I think your view on the matter makes very good sense !
Thanks !
BR/pj
Sensitivity: Internal
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
On Behalf Of Paul Kyzivat
Sent: den 22 januari 2020 16:25
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP version
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 line here between what is required behavior, what is good
practice, what is considerate, ...
It really is a savings for the recipient of the SDP if he can avoid parsing it.
And generally it should be easier for the sender to "know"
that the SDP is unchanged and so indicate that when sending it. It is a bit
harder for the recipient to determine that. OTOH, as an implementor I'm not
very trusting and so am inclined to not trust that it is unchanged without
checking. Even so there are ways to take advantage of that indication without
trusting it. (If the version # is the same as prior then do a string comparison
of the two SDPs to verify. If the version #s are different, then simply start
parsing the SDP without bothering with the comparison.)
And we shouldn't second guess what optimizations a peer may or may not want to
do.
I guess the worst case is a situation where you would normally generate the SDP
from scratch for every message and so not have an easy way to tell if it has
changed. Then it becomes a question of whether you do the extra work to
determine changed or not, or force extra work on the recipient. I think you
should do it.
The session timer connection is, IMO, a red herring. That draft is poorly
written, in that it seems to imply that an invite for session timer is mutually
exclusive with one for offer/answer. The two processes share messages and can
coexist or not.
Thanks,
Paul
On 1/22/20 6:50 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
> 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=fmtp:110 0-15
> a=sendrecv
> a=ptime:20
>
>
> SDP in re-INVITE from PBX
> SDP PDU
> v=0
> o=- 195986 2 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=fmtp:110 0-15
> a=sendrecv
> a=ptime:20
>
> 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.edu
> Subject: Re: [Sip-implementors] SDP version
>
> 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
> of servers) or just relay the message without any media level processing. If
> just the version number is incremented but there is no actual change in SDP,
> then it will trigger unnecessary processing on the receiver, so it should be
> avoided.
>
> Also can you specify what could be the requirement ("but is that true also
> for UA without support for timer") in which it is required to increment the
> SDP version number without any actual change in SDP.
> PS: Not able to get the attached picture.
>
> Regards,
> Rohit J
>
> On Wed, Jan 22, 2020 at 4:31 PM Sundbaum Per-Johan (Telenor Sverige AB)
> mailto:per-johan.sundb...@telenor.se>> wrote:
> 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 4028 - Session Timer
>
Re: [Sip-implementors] SDP version
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.edu
Subject: Re: [Sip-implementors] SDP version
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 of
servers) or just relay the message without any media level processing. If just
the version number is incremented but there is no actual change in SDP, then it
will trigger unnecessary processing on the receiver, so it should be avoided.
Also can you specify what could be the requirement ("but is that true also for
UA without support for timer") in which it is required to increment the SDP
version number without any actual change in SDP.
PS: Not able to get the attached picture.
Regards,
Rohit J
On Wed, Jan 22, 2020 at 4:31 PM Sundbaum Per-Johan (Telenor Sverige AB)
mailto:per-johan.sundb...@telenor.se>> wrote:
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 4028 - Session Timer
In that case, the offer MUST indicate
that it has not changed. In the case of SDP, this is accomplished by
including the same value for the origin field as did previous SDP
messages to its peer. The same is true for an answer exchanged as a
result of a session refresh request; if it has not changed, that MUST
be indicated. "
An example from reality in picture below, should it be accepted ?
I think it should be accepted.
[cid:image001.png@01D5D11B.59A78290]
BR/pj
Sensitivity: Internal
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Regards,
Rohit Jain
Sensitivity: Internal
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version
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 line here between what is required behavior, what is
good practice, what is considerate, ...
It really is a savings for the recipient of the SDP if he can avoid
parsing it. And generally it should be easier for the sender to "know"
that the SDP is unchanged and so indicate that when sending it. It is a
bit harder for the recipient to determine that. OTOH, as an implementor
I'm not very trusting and so am inclined to not trust that it is
unchanged without checking. Even so there are ways to take advantage of
that indication without trusting it. (If the version # is the same as
prior then do a string comparison of the two SDPs to verify. If the
version #s are different, then simply start parsing the SDP without
bothering with the comparison.)
And we shouldn't second guess what optimizations a peer may or may not
want to do.
I guess the worst case is a situation where you would normally generate
the SDP from scratch for every message and so not have an easy way to
tell if it has changed. Then it becomes a question of whether you do the
extra work to determine changed or not, or force extra work on the
recipient. I think you should do it.
The session timer connection is, IMO, a red herring. That draft is
poorly written, in that it seems to imply that an invite for session
timer is mutually exclusive with one for offer/answer. The two processes
share messages and can coexist or not.
Thanks,
Paul
On 1/22/20 6:50 AM, Sundbaum Per-Johan (Telenor Sverige AB) wrote:
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=fmtp:110 0-15
a=sendrecv
a=ptime:20
SDP in re-INVITE from PBX
SDP PDU
v=0
o=- 195986 2 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=fmtp:110 0-15
a=sendrecv
a=ptime:20
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.edu
Subject: Re: [Sip-implementors] SDP version
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 of
servers) or just relay the message without any media level processing. If just
the version number is incremented but there is no actual change in SDP, then it
will trigger unnecessary processing on the receiver, so it should be avoided.
Also can you specify what could be the requirement ("but is that true also for UA
without support for timer") in which it is required to increment the SDP version
number without any actual change in SDP.
PS: Not able to get the attached picture.
Regards,
Rohit J
On Wed, Jan 22, 2020 at 4:31 PM Sundbaum Per-Johan (Telenor Sverige AB)
mailto:per-johan.sundb...@telenor.se>> wrote:
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 4028 - Session Timer
In that case, the offer MUST indicate
that it has not changed. In the case of SDP, this is accomplished by
including the same value for the origin field as did previous SDP
messages to its peer. The same is true for an answer exchanged as a
result of a session refresh request; if it has not changed, that MUST
be indicated. "
An example from reality in picture below, should it be accepted ?
I think it should be accepted.
[cid:image001.png@01D5D11B.59A78290]
BR/pj
Sensitivity: Internal
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Regards,
Rohit Jain
Sensitivity: Internal
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
___
Sip-implementors mailing list
Sip-implementors@
Re: [Sip-implementors] SDP version
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=fmtp:110 0-15
a=sendrecv
a=ptime:20
SDP in re-INVITE from PBX
SDP PDU
v=0
o=- 195986 2 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=fmtp:110 0-15
a=sendrecv
a=ptime:20
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.edu
Subject: Re: [Sip-implementors] SDP version
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 of
servers) or just relay the message without any media level processing. If just
the version number is incremented but there is no actual change in SDP, then it
will trigger unnecessary processing on the receiver, so it should be avoided.
Also can you specify what could be the requirement ("but is that true also for
UA without support for timer") in which it is required to increment the SDP
version number without any actual change in SDP.
PS: Not able to get the attached picture.
Regards,
Rohit J
On Wed, Jan 22, 2020 at 4:31 PM Sundbaum Per-Johan (Telenor Sverige AB)
mailto:per-johan.sundb...@telenor.se>> wrote:
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 4028 - Session Timer
In that case, the offer MUST indicate
that it has not changed. In the case of SDP, this is accomplished by
including the same value for the origin field as did previous SDP
messages to its peer. The same is true for an answer exchanged as a
result of a session refresh request; if it has not changed, that MUST
be indicated. "
An example from reality in picture below, should it be accepted ?
I think it should be accepted.
[cid:image001.png@01D5D11B.59A78290]
BR/pj
Sensitivity: Internal
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--
Regards,
Rohit Jain
Sensitivity: Internal
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version
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 of servers) or just relay the message without any media level processing. If just the version number is incremented but there is no actual change in SDP, then it will trigger unnecessary processing on the receiver, so it should be avoided. Also can you specify what could be the requirement (*"but is that true also for UA without support for timer")* in which it is required to increment the SDP version number without any actual change in SDP. PS: Not able to get the attached picture. Regards, Rohit J On Wed, Jan 22, 2020 at 4:31 PM Sundbaum Per-Johan (Telenor Sverige AB) < per-johan.sundb...@telenor.se> wrote: > 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 4028 - Session Timer > In that case, the offer MUST indicate >that it has not changed. In the case of SDP, this is accomplished by >including the same value for the origin field as did previous SDP >messages to its peer. The same is true for an answer exchanged as a >result of a session refresh request; if it has not changed, that MUST >be indicated. " > > An example from reality in picture below, should it be accepted ? > I think it should be accepted. > > [cid:image001.png@01D5D11B.59A78290] > > BR/pj > > > > Sensitivity: Internal > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > -- Regards, Rohit Jain ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] SDP version
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 4028 - Session Timer In that case, the offer MUST indicate that it has not changed. In the case of SDP, this is accomplished by including the same value for the origin field as did previous SDP messages to its peer. The same is true for an answer exchanged as a result of a session refresh request; if it has not changed, that MUST be indicated. " An example from reality in picture below, should it be accepted ? I think it should be accepted. [cid:image001.png@01D5D11B.59A78290] BR/pj Sensitivity: Internal ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
