Subject: [SIP] FW: Delaying alerting at UAS

From: "Mark Watson" <[email-masked]>
Date: Fri, 6 Oct 2000 11:07:56 +0100

Hi,

Is it possible for a UAC to request that the UAS delays alerting of the user
until a subsequent 'go ahead' message is sent from UAC to UAS ??

For example, if the UAC has some action it requires to take before full
session commencement, but it only wants to take this action if the required
user can be sucessfully located and is available ?

The UAC action might be some kind of local resource reservation or an
indication to the calling user etc.

Can this be done with SIP as it stands ?

I looked in draft-manyfolks-sip-resource, but there does not appear to be
any way for the UAC to *require* that the UAS delay alerting until receipt
of confirmation from the UAC - the behaviour is optional on the part of the
UAS.

Regards,

Mark Watson
Nortel Networks

---

From: [email-masked]
Date: Fri, 6 Oct 2000 14:42:02 +0300

Hi,

This issue was presented in the last IETF meeting.
http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-camarillo-3pccprecon-sip
-48.ppt

I have submitted a draft about it. I sent it to the IETF a
couple of days ago, 
so it will be available very soon. It is called: 
draft-camarillo-manyfolks-confirm-00.txt

It outlines how to ask the UAS to wait until it receives a
COMET from the UAC in 
order to go on with the session establishment.

The draft contains an example related to third party call
control using SIP, but 
as you said, it is a general mechanism that can be employed in
several 
situations.

Best regards,

Gonzalo

>For example, if the UAC has some action it requires to take
before full session 
>commencement, but it only wants to take this action if the
required user can be
>
>sucessfully located and is available ?
>
>
>I looked in draft-manyfolks-sip-resource, but there does not
appear to be any 
>way for the UAC to *require* that the UAS delay alerting until
receipt of 
>confirmation from the UAC - the behaviour is optional on the
part of the UAS.
>Nortel Networks 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 6 Oct 2000 13:49:41 +0100

Thanks, this seems to answer the question - I look forward to reading the
draft. If I understand rightly, the idea is one of precoditions of which the
UAC is aware, but the UAS is not, so you need to force the UAS to wait for
the COMET.

I think this would need to be a session layer indication (i.e. in SIP, not
in the SDP) - the precondition is not necessarily related to the media
stream between UAC and UAS - in fact the UAS is never aware of what the
precondition actually is.

I had a further questions about the use of PRACKs to carry SDP in the
manyfolks draft. (Apologies in advance if this has already been discussed
too!).

I though that the purpose of PRACKs was to support reliability of
provisional responses. If this is their purpose then of course they are not
required if running over reliable transport (TCP and SCTP). So, how can they
be used for carrying information as well ?

Regards,

Mark Watson
Nortel Networks

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: 06 October 2000 12:42
To: Watson, Mark 
Cc: [email-masked]
Subject: [SIP] FW: Delaying alerting at UAS

Hi,

This issue was presented in the last IETF meeting.
http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-camarillo-3pccprecon
-sip
-48.ppt

Best regards,

Gonzalo

before full session 
required user can be
appear to be any 
receipt of 
part of the UAS.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 6 Oct 2000 10:38:56 -0400

-----Original Message-----
>From: Mark Watson [mailto:[email-masked]]
>Sent: Friday, October 06, 2000 8:50 AM
>To: [email-masked]'
>Subject: RE: [SIP] FW: Delaying alerting at UAS
>
>
draft. If I 
>understand rightly, the idea is one of precoditions of which the UAC is
aware, but the UAS 
>is not, so you need to force the UAS to wait for the COMET.

>I think this would need to be a session layer indication (i.e. in SIP, not
in the SDP) - 
>the precondition is not necessarily related to the media stream between UAC
and UAS - in 
>fact the UAS is never aware of what the precondition actually is.

>I had a further questions about the use of PRACKs to carry SDP in the
manyfolks draft. 
>(Apologies in advance if this has already been discussed too!).

>I though that the purpose of PRACKs was to support reliability of
provisional responses. If 
>this is their purpose then of course they are not required if running over
reliable 
>transport (TCP and SCTP). So, how can they be used for carrying information
as well ?

No, that is not correct. As there can be many hops along the way, each with
different transports, no one entity can know whether end to end tcp is used
or not. As a result, PRACK is always used for reliable provisional
responses, independent of the transport.

-Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 09 Oct 2000 09:29:45 +0300

Hi,

> Mark Watson wrote:
> 
> Thanks, this seems to answer the question - I look forward to reading
> the draft.

http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-confirm-00.txt
 
> I think this would need to be a session layer indication (i.e. in SIP,
> not in the SDP) - the precondition is not necessarily related to the
> media stream between UAC and UAS - in fact the UAS is never aware of
> what the precondition actually is.

Well, this might be an interesting discussion. The thing is that the
preconditions are very well described in the SDP part, but then SIP
signalling in used to confirm that the preconditions have been met.

Regards,

Gonzalo

> manyfolks draft. (Apologies in advance if this has already been
> discussed too!).
> 
> provisional responses. If this is their purpose then of course they
> are not required if running over reliable transport (TCP and SCTP).
> So, how can they be used for carrying information as well ?
> 
> Regards,
> 
> Mark Watson
> Nortel Networks
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 9 Oct 2000 11:06:54 +0100

Gonzalo,

This provides an excellent solution for preconditions related to the media
path between caller and callee, and using SDP obviously allows you to
negotiate different preconditions for different media streams.

However, what about preconditions which aren't related to the media path
between caller and callee ? Preconditions which the other party does not
know, or need to know about.

I think there is a requirement for a generic mechanism for the caller to
specify that the callee should wait for a COMET (or vice versa) without this
needing to be related to a particular media stream. To my mind this should
be a session level indication and would force the other UA to wait for the
COMET independent of whatever is agreed about QoS/Security.

Regards,

Mark Watson
Nortel Networks

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 09 October 2000 07:30
To: Watson, Mark 
Cc: [email-masked]
Subject: Re: [SIP] FW: Delaying alerting at UAS

Hi,

> Thanks, this seems to answer the question - I look forward to reading

http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-confirm-00.
txt

Regards,

Gonzalo

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 9 Oct 2000 10:49:47 +0100

Jonathan,

Mayby I am missing something, but if there are multiple hops, with different
transports, then there is always a stateful proxy on the boundry between the
reliable transport hops and the unreliable transport hops (I understand that
proxies supporting reliable transport must be stateful - perhaps that it
where I am wrong ?)

This proxy on the boundry could provide the PRACKs on the unreliable
transport hops.

Regards...Mark

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 06 October 2000 15:39
To: Watson, Mark ; [email-masked]'
Cc: [email-masked]'
Subject: RE: [SIP] FW: Delaying alerting at UAS

-----Original Message-----
>Subject: RE: [SIP] FW: Delaying alerting at UAS

<snip>

reliable 
as well ?

-Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 09 Oct 2000 13:13:05 +0300

When reliability is provided end to end there is no need of storing
state in the network (proxies).

Gonzalo

> Mark Watson wrote:
> 
> Jonathan,
> 
> Mayby I am missing something, but if there are multiple hops, with
> different transports, then there is always a stateful proxy on the
> boundry between the reliable transport hops and the unreliable
> transport hops (I understand that proxies supporting reliable
> transport must be stateful - perhaps that it where I am wrong ?)
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Oct 2000 02:39:08 -0400

-----Original Message-----
>Sent: Monday, October 09, 2000 5:50 AM
>To: 'Jonathan Rosenberg'; Mark Watson; [email-masked]'
different transports, 
>then there is always a stateful proxy on the boundry between the reliable
transport hops 
>and the unreliable transport hops (I understand that proxies supporting
reliable transport 
>must be stateful - perhaps that it where I am wrong ?)
>
transport hops. 

We've been down that path.

Doing PRACK hop by hop was a huge nightmare. It had backwards compatibility
problems, had difficulties dealing with forking, etc. Thats why we settled
on the e2e model, which works just like 200 OK for INVITE.

In any case, there is a reasonable (not great, but reasonable) separation of
SIP function from transport details right now. There is currently no SIP
message which does or does not get sent based on the transport, and I'd
rather not change that.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com