John,
On 4/26/2011 9:37 AM, Elwell, John wrote:
I know last call finished already, but the following has just been brought to my attention:
In section 5.2.5
"Changing the o-line,
except version number value, during the session is an error case.
The behavior when receiving such a non-compliant offer/answer SDP
body is implementation dependent. "
I would content this is NOT an error situation, or at least not an error in the case where a NEW session is being signalled.
Consider a 3PCC situation along the lines described in section 7 of RFC 3725. The controlling B2BUA converts a session between UA A and UA B into a session between UA B and UA C. Prior to this conversion, UA B has received UA A's SDP (SDP A). As a result of the conversion, UA B receives UA C's SDP (SDP C).
SDP C is likely to be completely different from SDP A. Therefore just a change of version number in the o-line is insufficient and would probably violate RFC 3264. In particular, if SDP A has 2 m-lines and SDP C has only one m-line, the change from 2 m-lines to 1 m-line is not permitted according to RFC 3264. So although RFC 3725 talks about the controlling B2BUA adjusting version numbers, that is insufficient in some cases.
It was precisely issues like this that led to the statements you are
taking issue with.
As I understand it, what you describe is not permitted - you can't
reduce the number of m-lines, even by changing the o-line.
This does put a burden on the 3pcc device - to patch up the SDP.
I would actually prefer to have a change that would loosen up what can
be done in this regard but it would be a normative change with pretty
severe backward compatibility issues.
The text of 5.2.5 then goes on to say:
"The behavior when receiving such a non-compliant offer/answer SDP
body is implementation dependent."
It is not clear what this fails to comply with. I can find nothing in RFC 3264 that stops you sending a new o-line if there is a new session. Yes, it would be non-compliant if only modifying an existing session, but how does the recipient know whether or not it is a new session, and therefore whether or not it is valid?
I think you are describing "SessionS Initiation Protocol", not the
"Session Initiation Protocol". AFAIK you only get one session per
invite-dialog-usage.
It then goes on to recommend use of Replaces in this situation (i.e. change of session):
"If a UA needs to negotiate a
'new' SDP session, it should use the INVITE/Replaces method."
But Replaces is not feasible if the UA concerned does not support it (and hence "should", presumably). So there will still be cases where a controlling B2BUA is forced to change the o-line (not just the version) in order to comply with RFC 3264.
So there needs to be a mechanism for changing to a 'new' session without relying on Replaces. As far as I can see, there is no standards track RFC that forbids changing the o-line to achieve this, so this new Informational draft should not attempt to make that change, and in particular should not do so without proposing an alternative solution.
I think the mechanism requires a normative change to SIP.
But I'm interested to hear what others think about this.
A simple fix would be to delete the entire bullet beginning "In the o-line, only the version number may change".
Its awfully late - in the category of the "it ain't happening unless you
lodge a complaint with the IESG".
But regardless of that, it seems we have a difference of opinion here
about what the standard is, and should discuss it.
Thanks,
Paul
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
