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 >
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.columbi
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 i
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
&g
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<mailto: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<mailto: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 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<mailto: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
Re: [Sip-implementors] SDP version increment without SDP change in early dialog
I just noticed this thread. So I'm jumping in where it seems to make sense. Note that 3261 and friends are *not* very clear about this. RFC6337 tried to clarify the original intent, without being normative. (In retrospect it would probably have been better to make a normative update.) There were many logical inferences made, across text from several documents, to determine original intent. The chain of logic is not always captured in 6337. IMO it is unfortunate that 3261 made it mandatory to ignore subsequent SDP in responses once the answer is received. While it may sometimes help keep a session working even when the UAS misbehaves, it is equally likely to simply result in a mess where the UAC and UAS disagree on the state of the session. If the answerer changes the SDP in a meaningful way (e.g., changing the media address) then things will not work unless the UAC also violates 3261 and honors the change. In your case is the *only* change in the SDP is to the version number? What is the point in doing that? Bottom line: IMO both UAC and UAS are non-conformant. The UAS is sending an invalid repetition of the answer, and the UAC is invalidly paying attention to it and objecting. On 9/18/15 7:59 AM, Roger Wiklund wrote: I agree with you but Nokia does not. Basically what they are saying is this: If SDP version number is incremented then this counts as an update/new offer period. The problem is I can't find an RFC stating "You MUST NOT increment version number if no change is made to the SDP" Even Paul Kyzviat is uncertain regarding this (at leat last year) https://lists.cs.columbia.edu/pipermail/sip-implementors/2014-July/029740.html I didn't go back and review that whole discussion, but IIRC, it was really more about subsequent O/As after the initial session establishment. In that case it is *valid* to change the SDP, and the question is whether a change to only the version number is acceptable. It is a bit different than in this case. Thanks, Paul On Fri, Sep 18, 2015 at 1:11 PM, Brett Tate wrote: The violation is: "When a reliable provisional response contains a session description, and is the first to do so, then that session description is the answer to the offer in the INVITE request. The answer cannot be updated, and a new offer cannot be sent in a subsequent reliable response for the same INVITE transaction." The only thing left to interpretation IMO is if version increment with no SDP change is considered an update. Thoughts on this? The SDP is not an updated answer. The SDP is not a new offer. It is an SDP that RFC 3261 says must be ignored. ___ 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@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version increment without SDP change in early dialog
> I agree with you but does not. > > Basically what they are saying is this: If SDP version number > is incremented then this counts as an update/new offer period. They can call it whatever they want. RFC 3261 says that the SDP must be ignored (i.e. it is not an updated answer or new offer). However if the vendor wants to disregard the "MUST ignore" and release the call, that is their prerogative. If the other vendor wants to interoperate with them, they will quit making the useless modification to the SDP. For completeness, I'll just say that the offer/answer model typically requires devices support RFC 3262, RFC 3311, and RFC 3261's forking interactions to avoid a poor user experience during call setup. Since there are vendors which still don't support such things (and operators that disable such functionality), devices occasionally have configuration options to intentionally disregard the "MUST ignore" in an attempt to improve the user experience (such as by handling as an updated answer). However, it sounds like there are others that prefer to disregard the "MUST ignore" and choose to release the call. -brett ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version increment without SDP change in early dialog
I agree with you but Nokia does not. Basically what they are saying is this: If SDP version number is incremented then this counts as an update/new offer period. The problem is I can't find an RFC stating "You MUST NOT increment version number if no change is made to the SDP" Even Paul Kyzviat is uncertain regarding this (at leat last year) https://lists.cs.columbia.edu/pipermail/sip-implementors/2014-July/029740.html On Fri, Sep 18, 2015 at 1:11 PM, Brett Tate wrote: >> The violation is: >> >> "When a reliable provisional response contains a session description, and >> is >> the first to do so, then that session description is the answer to the >> offer >> in the INVITE request. The answer cannot be updated, and a new offer >> cannot >> be sent in a subsequent reliable response for the same INVITE >> transaction." >> >> The only thing left to interpretation IMO is if version increment with no >> SDP change is considered an update. >> >> Thoughts on this? > > The SDP is not an updated answer. The SDP is not a new offer. It is an SDP > that RFC 3261 says must be ignored. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version increment without SDP change in early dialog
> The violation is: > > "When a reliable provisional response contains a session description, and > is > the first to do so, then that session description is the answer to the > offer > in the INVITE request. The answer cannot be updated, and a new offer > cannot > be sent in a subsequent reliable response for the same INVITE > transaction." > > The only thing left to interpretation IMO is if version increment with no > SDP change is considered an update. > > Thoughts on this? The SDP is not an updated answer. The SDP is not a new offer. It is an SDP that RFC 3261 says must be ignored. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version increment without SDP change in early dialog
So it's clear that the UAC is violating the "MUST ignore". I think this also makes it clear that the UAS is violating RFC. RFC 6337 section 2.2. Note that an offer/answer exchange initiated by an INVITE request must follow exactly one of the Patterns 1, 2, 3, 4. When an initial INVITE causes multiple dialogs due to forking, an offer/answer exchange is carried out independently in each distinct dialog. When an INVITE request contains no offer, only Pattern 2 or Pattern 4 apply. According to Section 13.2.1 of [RFC3261], 'The first reliable non-failure message' must have an offer if there is no offer in the INVITE request. This means that the User Agent (UA) that receives the INVITE request without an offer must include an offer in the first reliable response with 100rel extension. If no reliable provisional response has been sent, the User Agent Server (UAS) must include an offer when sending 2xx response. In Pattern 3, the first reliable provisional response may or may not have an answer. When a reliable provisional response contains a session description, and is the first to do so, then that session description is the answer to the offer in the INVITE request. The answer cannot be updated, and a new offer cannot be sent in a subsequent reliable response for the same INVITE transaction. In Pattern 5, a Provisional Response ACKnowledgement (PRACK) request can contain an offer only if the reliable response that it acknowledges contains an answer to the previous offer/answer exchange. — snip --- 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y YN 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y YN 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y YN 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y YN 5. PRACK Req. 200 PRACK Resp. RFC 3262 N YY 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N YY Table 1: Summary of SIP Usage of the Offer/Answer Model The violation is: "When a reliable provisional response contains a session description, and is the first to do so, then that session description is the answer to the offer in the INVITE request. The answer cannot be updated, and a new offer cannot be sent in a subsequent reliable response for the same INVITE transaction." The only thing left to interpretation IMO is if version increment with no SDP change is considered an update. Thoughts on this? /Roger On Thu, Sep 17, 2015 at 10:06 PM, Roger Wiklund wrote: > Thanks, makes sense! > > On Thu, Sep 17, 2015 at 10:02 PM, Brett Tate wrote: >> Hi, >> >> The UAC is violating the "MUST ignore". It is an SDP which MUST be ignored. >> Thus it is irrelevant what the UAS sends unless interacting with devices >> that ignore the "MUST ignore". However for interoperability reasons, the >> UAS can change their behavior. If I remember correctly, RFC 6337 might even >> recommend not including an SDP in that situation. >> >> >>> -Original Message- >>> From: Roger Wiklund [mailto:roger.wikl...@gmail.com] >>> Sent: Thursday, September 17, 2015 3:29 PM >>> To: Brett Tate >>> Cc: sip-implementors@lists.cs.columbia.edu >>> Subject: Re: [Sip-implementors] SDP version increment without SDP change >>> in >>> early dialog >>> >>> Hi >>> >>> Correct I forgot to mention that the initial INVITE contains SDP and it's >>> a >>> single dialog. >>> >>> RFC3261 section 13.2.1 >>> >>> If the initial offer is in an INVITE, the answer MUST be in a reliable >>> non- >>> failure message from UAS back to UAC which is correlated to that INVITE. >>> For >>> this specification, that is only the final 2xx response to that INVITE. >>> That >>> same exact answer MAY also be placed in any provisional responses sent >>> prior >>> to the answer. The UAC MUST treat the first session description it >>> receives >>> as the answer, and MUST ignore any session descriptions in subsequent >>> responses to the initial INVITE. >>> >>> "That same exact answer MAY also be placed in any provisional responses >>> sent >>> prior to the answer." >>> >>> You MAY place it in subsequent responses but the key is "that same exact >>> answer" So if you increment the version number it's not the exact same >>> answer. >>> >>> Is that not a violation? >>> >>> /Roger >>> >>> >>> >>> >>> >>> >&g
Re: [Sip-implementors] SDP version increment without SDP change in early dialog
Thanks, makes sense! On Thu, Sep 17, 2015 at 10:02 PM, Brett Tate wrote: > Hi, > > The UAC is violating the "MUST ignore". It is an SDP which MUST be ignored. > Thus it is irrelevant what the UAS sends unless interacting with devices > that ignore the "MUST ignore". However for interoperability reasons, the > UAS can change their behavior. If I remember correctly, RFC 6337 might even > recommend not including an SDP in that situation. > > >> -Original Message- >> From: Roger Wiklund [mailto:roger.wikl...@gmail.com] >> Sent: Thursday, September 17, 2015 3:29 PM >> To: Brett Tate >> Cc: sip-implementors@lists.cs.columbia.edu >> Subject: Re: [Sip-implementors] SDP version increment without SDP change >> in >> early dialog >> >> Hi >> >> Correct I forgot to mention that the initial INVITE contains SDP and it's >> a >> single dialog. >> >> RFC3261 section 13.2.1 >> >> If the initial offer is in an INVITE, the answer MUST be in a reliable >> non- >> failure message from UAS back to UAC which is correlated to that INVITE. >> For >> this specification, that is only the final 2xx response to that INVITE. >> That >> same exact answer MAY also be placed in any provisional responses sent >> prior >> to the answer. The UAC MUST treat the first session description it >> receives >> as the answer, and MUST ignore any session descriptions in subsequent >> responses to the initial INVITE. >> >> "That same exact answer MAY also be placed in any provisional responses >> sent >> prior to the answer." >> >> You MAY place it in subsequent responses but the key is "that same exact >> answer" So if you increment the version number it's not the exact same >> answer. >> >> Is that not a violation? >> >> /Roger >> >> >> >> >> >> >> >> On Thu, Sep 17, 2015 at 8:26 PM, Brett Tate wrote: >> > Hi, >> > >> > I assume that the INVITE contained an SDP and your example truly >> > reflects a single dialog (i.e. 18x/2xx To tags are the same). >> > >> > According to RFC 3261 section 13.2.1, the SDP modification must be >> > ignored. Thus it shouldn't cause the call to be released. With that >> > said, some devices have configuration options to violate that >> > statement and treat as an updated answer SDP (or a new offer SDP). >> > >> > RFC 3261 section 13.2.1: "The UAC MUST treat the first session >> > description it receives as the answer, and MUST ignore any session >> > descriptions in subsequent responses to the initial INVITE." >> > >> > More inline. >> > >> >> -Original Message- >> >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roger >> >> Wiklund >> >> Sent: Thursday, September 17, 2015 1:47 PM >> >> To: sip-implementors@lists.cs.columbia.edu >> >> Subject: [Sip-implementors] SDP version increment without SDP change >> >> in >> > early >> >> dialog >> >> >> >> Hi list >> >> >> >> I'm seeing the following behavior from an Aastra 400 PBX. >> >> >> >> Flow below is ITSP to PBX >> >> >> >> INVITE> >> >> <100Trying >> >> <183 w/SDP >> >> PRACK> >> >> <200OK (PRACK) >> >> <180 w/SDP >> >> >PRACK >> >> <200OK (PRACK) >> >> <200OK (INVITE)w/SDP >> >> ACK> >> >> BYE> >> >> <200OK (BYE) >> >> >> >> Each time the PBX sends an SDP, the version number is incremented >> >> even >> > though >> >> nothing is changed. >> >> >> >> ITSP does not like this and sends the BYE. >> >> >> >> I'm trying to wrap my head around this and to figure out who's at >> >> fault >> > here. >> >> >> >> According to RFC6337 section 3.2 >> >> >> >> When both UAs support the 100rel extension, they can update the >> >> session >> > in >> >> the early dialog once the first offer/answer exchange has been >> > completed. >> >> >> >> To me that means that the UAS can send many provisional responses >> >> each >> > with >> >> different SDP, each one updates the early dialog as long as PRACK is >> > used. >> > >> > RFC6337 section 2.2 (and RFC 3261) only allows 1 offer/answer for a >> > dialog's INVITE/response/ACK. After the INVITE's offer/answer >> > completes; PRACK and UPDATE can be used for new offer/answer exchanges >> > before the INVITE transaction completes. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version increment without SDP change in early dialog
Hi, The UAC is violating the "MUST ignore". It is an SDP which MUST be ignored. Thus it is irrelevant what the UAS sends unless interacting with devices that ignore the "MUST ignore". However for interoperability reasons, the UAS can change their behavior. If I remember correctly, RFC 6337 might even recommend not including an SDP in that situation. > -Original Message- > From: Roger Wiklund [mailto:roger.wikl...@gmail.com] > Sent: Thursday, September 17, 2015 3:29 PM > To: Brett Tate > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] SDP version increment without SDP change > in > early dialog > > Hi > > Correct I forgot to mention that the initial INVITE contains SDP and it's > a > single dialog. > > RFC3261 section 13.2.1 > > If the initial offer is in an INVITE, the answer MUST be in a reliable > non- > failure message from UAS back to UAC which is correlated to that INVITE. > For > this specification, that is only the final 2xx response to that INVITE. > That > same exact answer MAY also be placed in any provisional responses sent > prior > to the answer. The UAC MUST treat the first session description it > receives > as the answer, and MUST ignore any session descriptions in subsequent > responses to the initial INVITE. > > "That same exact answer MAY also be placed in any provisional responses > sent > prior to the answer." > > You MAY place it in subsequent responses but the key is "that same exact > answer" So if you increment the version number it's not the exact same > answer. > > Is that not a violation? > > /Roger > > > > > > > > On Thu, Sep 17, 2015 at 8:26 PM, Brett Tate wrote: > > Hi, > > > > I assume that the INVITE contained an SDP and your example truly > > reflects a single dialog (i.e. 18x/2xx To tags are the same). > > > > According to RFC 3261 section 13.2.1, the SDP modification must be > > ignored. Thus it shouldn't cause the call to be released. With that > > said, some devices have configuration options to violate that > > statement and treat as an updated answer SDP (or a new offer SDP). > > > > RFC 3261 section 13.2.1: "The UAC MUST treat the first session > > description it receives as the answer, and MUST ignore any session > > descriptions in subsequent responses to the initial INVITE." > > > > More inline. > > > >> -----Original Message- > >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roger > >> Wiklund > >> Sent: Thursday, September 17, 2015 1:47 PM > >> To: sip-implementors@lists.cs.columbia.edu > >> Subject: [Sip-implementors] SDP version increment without SDP change > >> in > > early > >> dialog > >> > >> Hi list > >> > >> I'm seeing the following behavior from an Aastra 400 PBX. > >> > >> Flow below is ITSP to PBX > >> > >> INVITE> > >> <100Trying > >> <183 w/SDP > >> PRACK> > >> <200OK (PRACK) > >> <180 w/SDP > >> >PRACK > >> <200OK (PRACK) > >> <200OK (INVITE)w/SDP > >> ACK> > >> BYE> > >> <200OK (BYE) > >> > >> Each time the PBX sends an SDP, the version number is incremented > >> even > > though > >> nothing is changed. > >> > >> ITSP does not like this and sends the BYE. > >> > >> I'm trying to wrap my head around this and to figure out who's at > >> fault > > here. > >> > >> According to RFC6337 section 3.2 > >> > >> When both UAs support the 100rel extension, they can update the > >> session > > in > >> the early dialog once the first offer/answer exchange has been > > completed. > >> > >> To me that means that the UAS can send many provisional responses > >> each > > with > >> different SDP, each one updates the early dialog as long as PRACK is > > used. > > > > RFC6337 section 2.2 (and RFC 3261) only allows 1 offer/answer for a > > dialog's INVITE/response/ACK. After the INVITE's offer/answer > > completes; PRACK and UPDATE can be used for new offer/answer exchanges > > before the INVITE transaction completes. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version increment without SDP change in early dialog
Hi Correct I forgot to mention that the initial INVITE contains SDP and it's a single dialog. RFC3261 section 13.2.1 If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. "That same exact answer MAY also be placed in any provisional responses sent prior to the answer." You MAY place it in subsequent responses but the key is "that same exact answer" So if you increment the version number it's not the exact same answer. Is that not a violation? /Roger On Thu, Sep 17, 2015 at 8:26 PM, Brett Tate wrote: > Hi, > > I assume that the INVITE contained an SDP and your example truly reflects > a single dialog (i.e. 18x/2xx To tags are the same). > > According to RFC 3261 section 13.2.1, the SDP modification must be > ignored. Thus it shouldn't cause the call to be released. With that > said, some devices have configuration options to violate that statement > and treat as an updated answer SDP (or a new offer SDP). > > RFC 3261 section 13.2.1: "The UAC MUST treat the first session description > it receives as the answer, and MUST ignore any session descriptions in > subsequent responses to the initial INVITE." > > More inline. > >> -Original Message- >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roger Wiklund >> Sent: Thursday, September 17, 2015 1:47 PM >> To: sip-implementors@lists.cs.columbia.edu >> Subject: [Sip-implementors] SDP version increment without SDP change in > early >> dialog >> >> Hi list >> >> I'm seeing the following behavior from an Aastra 400 PBX. >> >> Flow below is ITSP to PBX >> >> INVITE> >> <100Trying >> <183 w/SDP >> PRACK> >> <200OK (PRACK) >> <180 w/SDP >> >PRACK >> <200OK (PRACK) >> <200OK (INVITE)w/SDP >> ACK> >> BYE> >> <200OK (BYE) >> >> Each time the PBX sends an SDP, the version number is incremented even > though >> nothing is changed. >> >> ITSP does not like this and sends the BYE. >> >> I'm trying to wrap my head around this and to figure out who's at fault > here. >> >> According to RFC6337 section 3.2 >> >> When both UAs support the 100rel extension, they can update the session > in >> the early dialog once the first offer/answer exchange has been > completed. >> >> To me that means that the UAS can send many provisional responses each > with >> different SDP, each one updates the early dialog as long as PRACK is > used. > > RFC6337 section 2.2 (and RFC 3261) only allows 1 offer/answer for a > dialog's INVITE/response/ACK. After the INVITE's offer/answer completes; > PRACK and UPDATE can be used for new offer/answer exchanges before the > INVITE transaction completes. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] SDP version increment without SDP change in early dialog
Hi, I assume that the INVITE contained an SDP and your example truly reflects a single dialog (i.e. 18x/2xx To tags are the same). According to RFC 3261 section 13.2.1, the SDP modification must be ignored. Thus it shouldn't cause the call to be released. With that said, some devices have configuration options to violate that statement and treat as an updated answer SDP (or a new offer SDP). RFC 3261 section 13.2.1: "The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE." More inline. > -Original Message- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Roger Wiklund > Sent: Thursday, September 17, 2015 1:47 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] SDP version increment without SDP change in early > dialog > > Hi list > > I'm seeing the following behavior from an Aastra 400 PBX. > > Flow below is ITSP to PBX > > INVITE> > <100Trying > <183 w/SDP > PRACK> > <200OK (PRACK) > <180 w/SDP > >PRACK > <200OK (PRACK) > <200OK (INVITE)w/SDP > ACK> > BYE> > <200OK (BYE) > > Each time the PBX sends an SDP, the version number is incremented even though > nothing is changed. > > ITSP does not like this and sends the BYE. > > I'm trying to wrap my head around this and to figure out who's at fault here. > > According to RFC6337 section 3.2 > > When both UAs support the 100rel extension, they can update the session in > the early dialog once the first offer/answer exchange has been completed. > > To me that means that the UAS can send many provisional responses each with > different SDP, each one updates the early dialog as long as PRACK is used. RFC6337 section 2.2 (and RFC 3261) only allows 1 offer/answer for a dialog's INVITE/response/ACK. After the INVITE's offer/answer completes; PRACK and UPDATE can be used for new offer/answer exchanges before the INVITE transaction completes. ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] SDP version increment without SDP change in early dialog
Hi list I'm seeing the following behavior from an Aastra 400 PBX. Flow below is ITSP to PBX INVITE> <100Trying <183 w/SDP PRACK> <200OK (PRACK) <180 w/SDP >PRACK <200OK (PRACK) <200OK (INVITE)w/SDP ACK> BYE> <200OK (BYE) Each time the PBX sends an SDP, the version number is incremented even though nothing is changed. ITSP does not like this and sends the BYE. I'm trying to wrap my head around this and to figure out who's at fault here. According to RFC6337 section 3.2 When both UAs support the 100rel extension, they can update the session in the early dialog once the first offer/answer exchange has been completed. To me that means that the UAS can send many provisional responses each with different SDP, each one updates the early dialog as long as PRACK is used. RFC3262 section 8 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. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section The above does not state that you can't increment the version number without SDP change. Any tips? /Roger ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
