Subject: RE: [Sip] The Problem with PRACK - offerless invite

From: "Christian Jansson" <[email-masked]>
Date: Thu, 16 Mar 2006 21:54:22 +0100

>> So completely depending on Bob's UA, Alice may get _any_ kind of call
>> back, msrp+audio, video+application/whiteboard, 2 video streams? Even
>> though Alice initially invited Bob! Why would Alice invite Bob at all
if
>> she does not have _any_ clue of what session Bob will offer?
>
>Presumably bob wouldn't do this unless this is what he wants.

But what does Alice want? Why did she invite Bob in the first place if
she lets Bob decide the type of session without any hint to Bob of what
to do?

>In practice, offerless invites are useful in 3pcc scenarios, where
there
>is a controller acting as an intermediary in connecting two other
>parties. It may not know a priori what either of them support. 

I agree, but someone must at least have had an idea of the use of the
session that will be created by that 3pcc setup. So a quake+msrp session
is as good as an audio+whiteboard session. Shouldn't the initial
intention at least be stated, kind of "lets try to setup an 3pcc
audio+whiteboard session between Alice and Bob". And then Bob SHOULD use
that to build the offer or decline the call? And if Bob tried to use
whiteboard+quake he would be considered a little bit strange?

> It just
>asks one, and takes whatever is offered and offers it to the other. It
>doesn't care what that is as long as both parties are happy with it.

So, an "anything" session is ok? I guess that will be hard to explain to
the users. 

>This is true only if you care. Why would a ua that is capable of voice
>plus video not offer that?

Well I do care. Just because I have a video camera and Quake does not
mean that I will like to use them all the time. But if the offerless
invite at least stated what media types I was expected to use in the
offer I could at least take that into consideration when
accepting/declining the offerless invite.

Is it so that you think that the offer Bob should make should include
all supported media types, but that all of them (or configurable) should
be inactivated, and that Bob should not be alerted until Alice have
decided what media types she decided not to completely deny? After that
BoB's UA could ask Bob if he wanted to have an audio+video call, and Bob
would then only activate the audio stream in a re-INVITE, as he had a
bad-hair-day?

/ Christian Jansson

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Mar 2006 21:32:11 -0500

> she lets Bob decide the type of session without any hint to Bob of what

I'm sorry - I typed the wrong thing. What I meant to say was:

presumably *alice* wouldn't do this (send an offerless invite) unless 
this (getting an unpredictable offer) is what *she* wants.

> session that will be created by that 3pcc setup.

This is all context sensitive. The user controlling the B2BUA may be 
familiar with at least one of the UAs that will be used, and so has an 
expectation that the resulting session will involve some or all of the 
media supported by that UA. But that doesn't mean that the B2BUA needs 
to know.

It seems unlikely that someone with no knowledge of either UA would be 
interested in establishing a session between them.

> So a quake+msrp session

This is technically difficult to do with a B2BUA, unless it terminates 
media. Making an offer with media means specifying a media address. This 
can partially be mitigated by offering media with C=0.0.0.0, but then 
you can get some ugly clipping issues. (The clipping issues could be 
solved using preconditions, but lets not go there right now.)

> accepting/declining the offerless invite.

We cannot discuss this without delving into the UI of the devices.

I agree that you may not always want to offer video even if you have the 
capability. This can be handled by having default settings for use of 
media by your device: which media should be offered by default when you 
initiate an offer, and which should be accepted by default when you 
answer an incoming offer. Ideally it should be possible to change the 
defaults, and to change the settings for a given call either before the 
call is placed or answered, or after.

Directionality is also possible. For instance, that you are willing to 
receive video, but not transmit by default. (Then you can decide to 
enable transmission after you learn who it is, or get dressed.)

> would then only activate the audio stream in a re-INVITE, as he had a

Yeah, you seem to get the general idea. I think a well human-engineered 
video phone will need this kind of capability.

	Paul