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 a
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:1
s 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
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 underst
ip-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
ntors@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 e
MA/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
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
Hi,
SIP entities (client/server) checks SDP version to determine whether there
is any change in SDP from previously received SDP. If the version is
changed then they go on to parse the entire SDP to determine the change.
Based on that SIP entity can initiate media processing(more relevant in
case
Hi !
What do you think about incrementing the version in SDP o-line, but not
changing anything else in SDP,
should such a behavior be accepted or should it be rejected ?
RFC 4028 states that such behavior at least should be avoided, but is that true
also for UA without support for timer ?
" RFC
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 we
> 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).
Ho
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 i
> 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 reliabl
hus 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: "Th
> 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
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
> Subje
t; 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
>>
>
TE."
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.ed
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
tho
21 matches
Mail list logo
