On 2/28/15 8:05 PM, brez wrote:
Hi Paul,
Please see inline..
On 2/28/2015 10:58 PM, Paul Kyzivat wrote:
On 2/28/15 3:36 PM, brez wrote:
Hello,
Is it possible to establish a session (INVITE) with SDP constructed in
such a way so that neither party initiates a media session, nor
allocates resources (ports) for a non-existent media session?
In principle you can send an initial offer with SDP that has no m-lines.
AFAIK that is valid.
Thanks for giving me direction. This is indeed a valid case which is
described in RFC3264, Section 5, Paragraph 4:
The offer will contain zero or more media streams (each media stream
is described by an "m=" line and its associated attributes). Zero
media streams implies that the offerer wishes to communicate, but
that the streams for the session will be added at a later time
through a modified offer.
But I have recently had discussions with someone about this, and about
a UAS that wants to return 488 for this case. I *think* that in
*practice* you will find that many UASs will reject such an offer one
way or another.
Would that depend on the policy of service provider? i.e. you don't want
UAC who doesn't know how it wants to communicate, and by returning 488
you get rid of any such clients requesting your service.
Yes, policy is significant here.
The fundamental issue is that a session without media isn't useful in
the long term. To make it useful, somebody has to do something more -
typically another offer. But once the first offer is done it isn't clear
where the responsibility resides? *Who* should do something? And what?
This isn't written down anywhere. Logically, I think it makes sense that
the UA that caused this media-less situation should be responsible for
fixing it. So if the initial offer had no m-lines, then that end should
take responsibility for making another offer to fix it. (Of course, if
it can, then why didn't it do so in the first offer?)
There is also another case, where the initial offer contains m-lines but
the answer rejects them all but still accepts the INVITE. *That* case
makes more sense. It can happen because the offer had no media
acceptable to the answerer, but there are *some* media that the answerer
would like to use. But there is danger in accepting the INVITE in this
case: if the call has been forked, there might be another fork that will
accept the media in the initial invite. If another UA accepts without
media, it may preempt that. :-(
There is a special case in the wild: the offer has no media, but is
accepted. Then messages are exchanged within the dialog using MESSAGE.
(This is arguably an abuse of MESSAGE.) I think the intent to use the
dialog this was is signaled somehow, so the answerer knows what to expect.
Bottom line - while this is a *possible* mechanism it seems only suited
to some special cases.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
