Subject: RE: [Sipping] update to 3pcc I-D

From: "Taniguchi, Claire" <[email-masked]>
Date: Tue, 14 May 2002 14:23:48 -0700

I understand your intent to establish best current practice now, but I must
comment that as it currently stands, these are significant issues from a
service provider perspective. I look forward to seeing a revised flow that
overcomes these issues as then 3pcc will have wider application (and an
easier deplyment model).

Regards,
Claire Taniguchi
SBC TRI

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, May 14, 2002 1:01 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [Sipping] update to 3pcc I-D

Here is my proposed text to be added to the description of flow 4, which
documents the limitations that Paul has pointed out:

There are some limitations associated with this flow. First, user A
will be alerted without any media having been established yet. This
means that user A will not be able to reject or accept the call based
on its media composition. Secondly, both A and B will end up answering
the call (i.e., generating a 200 OK) before it is known whether their
is compatible media. If there is no media in common, the call can be
terminated later with a BYE. However, the users will have already been
alerted, resulting in user annoyance and possibly resulting in billing
events. 

Comments?

-Jonathan R.

Jonathan Rosenberg wrote:
> 
> Paul Kyzivat wrote:
> >
> > Jonathan Rosenberg wrote:
> > >
> > > * addition of a new flow, flow 4. This is a variation on the
> > previously
> > > recommended flow. It uses SDP with no media lines (as opposed to no
> > SDP)
> > > to avoid the SDP hacking that flow 3 requires. This is now the
> > > recommended flow.
> >
> > I am wondering about how alerting is handled in this flow. Specifically,
> > wonder whether a UA should alert upon receiving a media-less initial
> > invitation. There are a number
> > of problems with alerting at this time:
> 
> To be honest, the entire point of the flow is that alerting occurs at
> this time, rather than later. If it occurs later, the response to the
> re-INVITE is delayed, and the same transaction timeout problem as in
> flow I occurs.
> 
> >
> > - The proper manner of alerting may depend on the media to be used.
> > (E.g. Generate ring tone vs pop a window.)
> 
> Media can always change during the call anyway. If the call started as
> video, would you delay the ringing till audio is added? To me, the
> ringing inquires whether or not the user wishes to communicate.
> 
> >
> > - The called user may not be able to decide whether to answer the call
> > without knowing what media are to be used. (E.g. will accept audio but
> > not video, or IM but not
> > audio)
> 
> Again, these may change during the call in any case.
> 
> >
> > - The call may eventually fail because the two ends have no media in
> > common. In that case the alert was an annoyance. (This property is
> > shared with an offer-less
> > invitation.)
> 
> Yes, that is a fundamental issue with third party call control.
> 
> >
> > Flow 4 doesn't really mention alerting, but I think it implicitly
> > assumes that alerting will happen between messages (1) and (2), and not
> > between (6) and (7).
> 
> Correct.
> 
> > If the
> > alerting of A is delayed until after message (6) when media information
> > is available, then this flow has the same timeout problem as Flow 1.
> 
> Correct.
> 
> >
> > I think what is really needed is a way to determine whether there is
> > going to be a match on the media between A and B before either side
> > alerts. But I don't see a way to
> > achieve this with existing SIP features. So I think that flows 3 or 4
> > are best practice at the moment, regardless of their limitations.
> 
> Sounds like preconditions to me.
> 
> >
> > For the future, tweaking SIP features could provide a better solution.
> > For instance, assume:
> >
> > EXTENSION-1) a media-less invite doesn't alert
> >
> > Using that, the following flow would be possible. (Excuse me for not
> > drawing a real flow - hopefully this is sufficient to get the point
> > across):
> >
> > - invite A with no media (assume no alert)
> > - invite B with no media (assume no alert)
> > - send OPTIONS to A within the dialog
> > - send OPTIONS to B within the dialog
> > - compute intersection of SDP from the two options
> > - sent UPDATE to A with offer containing the
> >   intersected SDP, with address set to blackhole
> >   (assume this alerts).
> > - wait for answer from A & ack.
> > - send UPDATE to B using  A's answer, with
> >   the address set to blackhole
> >   (assume this alerts.)
> > - wait for answer from B & ack.
> > - send UPDATE to A with no offer & await answer.
> > - send UPDATE to B with A's answer as the offer.
> > - wait for answer from B & ack.
> > - send B's answer in ack to A.
> >
> > The above leaves a lot to be desired.
> 
> Yeah; one of the things I really don't like is that the controller does
> all this SDP mucking. Thats what flow IV was trying to help alleviate.
> 
> The following would be better:
> >
> > - invite A with no media (assume no alert)
> > - invite B with no media (assume no alert)
> > - send OPTIONS to A within the dialog
> > - send OPTIONS to B within the dialog, but include
> >   A's SDP as a pseudo-offer. Assume B responds with
> >   SDP like it would if it received such an offer.
> > - sent UPDATE to A with offer containing B's
> >   answer, with address set to blackhole
> >   (assume this alerts).
> > - wait for answer from A & ack.
> > - send UPDATE to B using  A's answer
> >   (assume this alerts.)
> > - wait for answer from B & ack.
> > - send UPDATE to A with no offer & await answer.
> >   (assume new requirement that offer-less update
> >    MUST return prior SDP.)
> > - send B's answer in ack to A.
> >
> > It assumes:
> >
> > EXTENSION-2) When OPTIONS contains an SDP body, it is treated like an
> > offer and the SDP in the response then contains what the corresponding
> > answer would be
> >
> > EXTENSION-3) UPDATE with no offer is required to return the last SDP as
> > its offer.
> >
> > I realize I am on thin ice postulating changes like this, but without
> > doing something 3pcc just doesn't work very well for multimedia calls.
> 
> I agree that the current 3pcc mechanisms could do better with some
> additional extensions. I have some ideas on those too; what I really
> want is to finally completely decouple offer/answer from SIP messages,
> so that offers and answers could appear across transactions. Once this
> is done, I can actually send an INVITE w/o SDP, get an offer in the 2xx,
> and send an ACK without SDP (thus stopping the spurious retransmits).
> Then, UPDATE later on with the answer.
> 
> So, the ideal flow to me is:
> 
>           A              Controller               B
>           |(1) INVITE no SDP  |                   |
>           |no alerting        |                   |
>           |<------------------|                   |
>           |(2) 183 offer1     |                   |
>           |------------------>|                   |
>           |(3) PRACK          |                   |
>           |<------------------|                   |
>           |(4) 200 PRACK      |                   |
>           |------------------>|                   |
>           |                   |(5) INVITE offer1  |
>           |                   |------------------>|
>           |                   |(6) 200 OK answer1 |
>           |                   |<------------------|
>           |                   |(7) ACK            |
>           |                   |------------------>|
>           |(8) UPDATE answer1 |                   |
>           |alerting           |                   |
>           |<------------------|                   |
>           |(9) 200 UPDATE     |                   |
>           |------------------>|                   |
>           |(10) 200 INVITE    |                   |
>           |when answered      |                   |
>           |------------------>|                   |
>           |(11) ACK           |                   |
>           |<------------------|                   |
>           |(12) RTP           |                   |
>           |-------------------------------------->|
> 
> This doesn't require the controller to so much as peep at the SDP, and
> it has no timeout issues, and it won't cause alerting until agreed upon
> media is present. I'm not sure how the preconditions stuff would work to
> prevent alerting until a media stream is set up, but I am sure it could
> be worked out.
> 
> However, for now, we are specifying the best current practice for doing
> 3pcc in SIP. That means we document what can be done, and also document
> its limtations. Thus, I will incorporate your specific issues and
> assumptions that you describe above.
> 
> -Jonathan R.
> 
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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

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

---

From: "Sanjoy Sen"<[email-masked]>
Date: Tue, 14 May 2002 17:23:34 -0500

I had the impression that the first 3 exchanges (INVITE(no media), 200OK(no
media), ACK) of Flow IV establishes a dialog without a media session (O/A
draft says that an SDP sent without media is an intent to communicate
conveying the expectation that media will be added later through SDP
modification). The O/A draft allows us to separate these three cases:
1) dialog established with no media 
2) dialog established with media
3) media with no dialog established (early media)

So I agree the alerting in case 1) need to be somewhat different than what
is done in the regular case 2), but I don't see the same time-out problem as
Flow I happening in this case. With a new type of alert, the user behavior
can be modified.

Sanjoy

> Sent: Tuesday, May 14, 2002 3:01 PM

---

From: "Sanjoy Sen"<[email-masked]>
Date: Tue, 14 May 2002 18:56:15 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, May 14, 2002 6:31 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Yeah, I figured as much, but thought it was worth mentioning.
> In an earlier reply on this thread I brought up the problem 
> of how this should be handled by a gateway device that can't 
> separate media from signalling. It was
> consideration of that that first made me question when 
> alerting should happen.
> 

[SS] I'm not clear about the time-out issue though. When an UA has received 
and acknowledged an INVITE (without m= line), it clearly must be ready to
receive future SDP modification (unless it takes several minutes to receive
the re-INVITE, which wouldn't be the case). So it should respond to the
re-INVITE immediately and the timeout problem doesn't exist. What am I
missing here?

> Alerting is used to inquire whether the user wishes to 
> communicate or not. But there may be different sorts of 
> alerting appropriate to different media or combinations of
> media. 
> 
> The issue of media changing during a call is a very tricky 
> one. Ideally every media change shouldn't result in fresh 
> alerting. Yet is it valid to assume that if I answered
> a voice call I am willing to have video added, without 
> receiving some new indication of this? 
> 
> (What if I am sitting in front of my pc in my underwear, and 
> my pc has a camera?)
> 

[SS] The UA, in that case, should be configured not to accept video session
offer.

> Managing a multimedia UA is just plain more complex than a 
> monomedia UA. I don't think all the important use cases wrt 
> alerting have been explored.
> 
> Maybe we have to say that it is up to the user to configure 
> supported media for the UA at the time of answering the call, 
> so that the UA is capable of handling all
> subsequent reinvites without added alerting. 
> 
> > 
> > >
> Once I answer, I can presumably prevent them from changing. I 
> suppose we could assume that I must decide upon answering 
> what media I am willing to use without knowing if
> that will be acceptable to the caller.
> 
> As Sanjoy said, possibly this can be handled by having a 
> distinct alert indicating no-media.
> 

[SS] We need to handle the SIP dialog establishment without any media as
a special case to modify user behavior from traditional PSTN. 

> I think so too, but haven't figured out how to make it work.
> 
> If this can be worked out then it would be a great improvement.
> 
> > 
> Can't ask for more than that.
> 
> 	Thanks,
> 	Paul
>