Comment at end
Christer Holmberg wrote:
Hi Paul,
I've changed the subject, because I don't think this is related to the
re-transmission of 18x. It is a little related to the discussion about
relaxing the must-insert-SDP-in-first-reliable-18x, but let's still have
a separate thread for it.
> > > >>>Is the flows below valid according to recent arguments?
> > > >>>
> > > >>> UAC UAS
> > > >>> |----invite(SDP)--->|
> > > >>> |<--- 183(SDP)------|
> > > >>> |-----prack(SDP)--->|
> > > >>> |<--- 200(SDP)------|
> > > >>>
> > > >>> flow 1
> > Does it means,the first flow is allowed?
>
> Yes.
> > I think, the restriction the first reliable response
must contain
SDP if > > the INVITE without SDP > > should restrict the called
user.
>
> That's the way it is now.
Sure, I means, the first reliable response from the called
user must contain NORMAL SESSION SDP in order to communication,but
AS(application server) shouldn't be restricted by this rule
as AS may only concern about early-session for pronunciation. Or, the
AS is also restricted if early-session plays the same role as normal
session.
The AS is an artifact of IMS, it has no role in any of the
ietf standards. It has been expected that components playing
various roles such as this are bound by normal distinctions
between UAC, UAS, Proxy, etc.
IMO it isn't a good idea to introduce a new kind of UA (or
proxy) that is bound by different rules.
I don't think a new role is proposed. The AS was just an example, but
from a SIP perspective it is of course behaving as a UAS in this case :)
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...
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 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.
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
