Hi, >>>You might consider the "early-session" mechanism specified by RFC 3959. >>>But I have never heard of it being implemented, so it may not be >>>useful to you. >> >>I have been assuming that we ARE talking about the 3959 mechanism, and >>the question has been whether an "early-session" SDP offer fullfills >>the MUST rule to include SDP offer in the first reliable response. >> >>IF we decide to relax the rule I guess it doesn't really matter, but >>if we maintain the rule I guess it is a valid question. > >Frankly I don't expect to see 3959 ever used. But if it is... In IMS it is an alernative solution to providing some services. It is optional to support, though. >IMO the "early-session" and the "session" must each independently comply with the o/a rules. So if you take any call flow >using early-session, and transform it in either of the following ways, the transformed flow should still be valid >according to the normal rules for o/a using "session": > >1) remove all the body parts with content-disposition of "early-session" >and content-type "application/sdp". Then if that results in multipart/mixed body parts containing only an application/sdp >body part with c-d of session, remove the multipart, leaving just the sdp in its place. Then remove any >Supported/Required references to early-session. > >2) remove all the body parts with content-disposition of "session" and content-type "application/sdp". Then if that >results in multipart/mixed body parts containing only an application/sdp body part with c-d of early-session, remove the >multipart, leaving just the sdp in its place. >Then replace occurrences of C-D:early-session with C-D:session. Then remove any Supported/Required references to early- >session. > >In theory, the above would allow the UAC to initiate both, but in practice that would make no sense. > >If what I say is correct, then it relaxes no restrictions on anybody. I am not sure I understand what you tried to explain :) But, based on your arguments: according to the current rules, if the first reliable SDP contains an early-session SDP offer, is it also required to contain a session SDP offer? Or, I the early-session SDP offer enough? >I don't understand why anybody would bother with early-session. For the cases where it might be useful I think the same >effect can be accomplished easier by simply establishing an early dialog with one to-tag, and a different early/final >dialog with a different to-tag. Why weren't you in 3GPP when I was arguing exactly the same thing... ;) Regards, Christer _______________________________________________ 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
