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
v=0
>> o=- 195986 2 IN IP4 10.81.253.92
>> s=RFC3264OfferAnswerExchange
>> c=IN IP4 10.81.253.92
>> b=CT:10000000
>> 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=
se !
>
> 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:
ul 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 you
@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
@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
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 S
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
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 ?
"
r 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
>>> ear
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
> 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
> 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).
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
uot;
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
>
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
ger.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
>>
&g
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
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
>>
21 matches
Mail list logo
