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: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=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: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=fmtp:110 0-15 a=sendrecv a=ptime:20 BR/pj From: Rohit Jain <jainrohit...@gmail.com> Sent: den 22 januari 2020 12:36 To: Sundbaum Per-Johan (Telenor Sverige AB) <per-johan.sundb...@telenor.se> 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) <per-johan.sundb...@telenor.se<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