Subject: [BLISS] Use of Warning: header to transport additional status indications

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 17 Aug 2007 15:05:34 +0200

In several use cases there is a need to provide additional information
about the status of the call or the activation of some additional
services.

For example in GSM and ISDN networks a common service is to provide
calling party a reminder that the call diversion is activated for his
line (A-party). This should not be mistake with the idication that the
call diversion is taking place at the (B-Party).

Another example is an indication for the A-Party, that the call-waiting
procedure is taking place on the B-Party side.

This indications are transmitted during call-establishment phase.

A proposal is to reuse the Warning: header by extanding the warn-code
with the values reflecting the described cases. The spare volumes of
warn codes at the moment are 340-369 and 390-399, so the following new
warn codes can be defined:

Warning: 341 isi.edu "Call is a waiting call"
Warning: 342 isi.edu "Diversion activated"

The procedure at the SIP proxy is then to include the Warning: Header in
to the 180 Ringing or 183 Session Progress response to provide the
required indication to the A-Party. 

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
To: Bob <sip:[email-masked]>;tag=a6c85cf
From: Alice <sip:[email-masked]>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:[email-masked]>
CSeq: 314159 INVITE
Warning: 342 atlanta.com "Diversion activated"
Content-Length: 0

Alice receives the idication from her home proxy atlanta.com that the
diversion service is active for her URI.

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
To: Bob <sip:[email-masked]>;tag=a6c85cf
From: Alice <sip:[email-masked]>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:[email-masked]>
CSeq: 314159 INVITE
Warning: 341 biloxy.com "Call is a waiting call"
Content-Length: 0

Alice receives the idication from the Bob's proxy biloxy.com that her
call is in call-waiting mode on the Bob's side.

Any comments question?

Greetings,
Denis Alexeitsev

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Aug 2007 14:38:43 +0100

Denis,
 
See below.
 
John

________________________________

	From: Alexeitsev, D [mailto:[email-masked]] 
	Sent: 17 August 2007 14:06
	To: [email-masked]
	Subject: [BLISS] Use of Warning: header to transport additional
statusindications

	In several use cases there is a need to provide additional
information about the status of the call or the activation of some
additional services.

	For example in GSM and ISDN networks a common service is to
provide calling party a reminder that the call diversion is activated
for his line (A-party). This should not be mistake with the idication
that the call diversion is taking place at the (B-Party).

	Another example is an indication for the A-Party, that the
call-waiting procedure is taking place on the B-Party side. 
	[JRE] I think these are quite different problems that merit
different solutions. 

	This indications are transmitted during call-establishment
phase. 
	[JRE] I understand why a user may wish to receive notifications
that call diversion is active, but I fail to see why this should be
synchronised with that user's attempts to establish calls. It seems to
me that the SIP event framework would be ideally suited to this. A UA
could subscribe to an event package, and any information related to the
way incoming calls are handled at the proxy (not merely a simple
indication that diversion is active) could be provided in notifications.
I see this as part of the automated call handling topic in BLISS, so I
will add it to my list of things to consider. 

	A proposal is to reuse the Warning: header by extanding the
warn-code with the values reflecting the described cases. The spare
volumes of warn codes at the moment are 340-369 and 390-399, so the
following new warn codes can be defined:

	Warning: 341 isi.edu "Call is a waiting call" 
	[JRE] Why is the 182 Queued response insufficient?
	Warning: 342 isi.edu "Diversion activated" 

	The procedure at the SIP proxy is then to include the Warning:
Header in to the 180 Ringing or 183 Session Progress response to provide
the required indication to the A-Party. 
	[JRE] Why would a proxy need to do anything for call waiting?
Call waiting is a function of the called UA, which would generate the
necessary indication (182 response, in my opinion) when appropriate. How
would the proxy be in a position to be able to generate such
information?

	SIP/2.0 180 Ringing 

	Alice receives the idication from her home proxy atlanta.com
that the diversion service is active for her URI. 

	SIP/2.0 180 Ringing 

	Alice receives the idication from the Bob's proxy biloxy.com
that her call is in call-waiting mode on the Bob's side. 

	Any comments question? 
	[JRE] So no, I don't see that warn codes are appropriate for
either of these two cases. 

	Greetings, 
	Denis Alexeitsev

---

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 17 Aug 2007 16:13:10 +0200

Hello John
 
Thanks for the comments, responses inline. 
 
[JRE] I understand why a user may wish to receive notifications that
call diversion is active, but I fail to see why this should be
 
[DA] I think using event framework would be an overkill for such simple
indication and Warning header even literary fits well for this case as a
reminder. In addition the interworking with ISDN/GSM would be way to
complicated if unbundled from the call establishment state.

[DA] It is not exactly the same as queued, because the B-party receives
the session setup request, but with indication that the resources shall
be made available in order to establish the session. In queued case the
session in not presented to the B-party but queued by some instance
before.

The procedure at the SIP proxy is then to include the Warning: Header in
to the 180 Ringing or 183 Session Progress response to provide the
required indication to the A-Party. 
[JRE] Why would a proxy need to do anything for call waiting? Call
waiting is a function of the called UA, which would generate the
necessary indication (182 response, in my opinion) when appropriate. How
would the proxy be in a position to be able to generate such
information?

[DA]The reasoning behind it is that network might limit the number of
simultaneous sessions, that can be established with a specific URI. In
this case an incoming call to the URI that has already reached the
maximum number of simultaneous sessions would fall in to the
call-waiting state. For this scenario an indication is needed to the
A-party that is it not just normal ringing but call-waiting case.

Greetings,

Denis Alexeitsev

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 17 Aug 2007 16:30:46 +0200

[DA] I think using event framework would be an overkill for such
simple indication and Warning header even literary fits well for this
case as a reminder. In addition the interworking with ISDN/GSM would be
way to complicated if unbundled from the call establishment state. 

[KED} These indications that diversion is active are equivalent to the
old black phone equivalent of giving special dial tone when diversion is
active and so on. When they were discussed in the evolution of the ISDN,
they were regarded as part of the stimulus protocol rather than the
functional protocol. Therefore no ISDN functional protocol was ever
defined for them (at least I cannot see anything in ETSI EN 300 207-1
V3.1.1 (2001-06) which is the latest version of the DSS1 protocol
document, and for which there should be a direct ITU-T equivalent. 

Rather, some stimulus indication can be given, such as a tone or
announcement. Now there have been extensive discussions in the past on
stimulus versus functional in SIP...

Regards

Keith

	From: Alexeitsev, D [mailto:[email-masked]] 
	Sent: Friday, August 17, 2007 3:13 PM
	To: [email-masked]
	Subject: AW: [BLISS] Use of Warning: header to
transportadditionalstatusindications

	Hello John

	 
	[DA] I think using event framework would be an overkill for such
simple indication and Warning header even literary fits well for this
case as a reminder. In addition the interworking with ISDN/GSM would be
way to complicated if unbundled from the call establishment state.

			A proposal is to reuse the Warning: header by
extanding the warn-code with the values reflecting the described cases.
The spare volumes of warn codes at the moment are 340-369 and 390-399,
so the following new warn codes can be defined:

			Warning: 341 isi.edu "Call is a waiting call" 
			[JRE] Why is the 182 Queued response
insufficient? 

			[DA] It is not exactly the same as queued,
because the B-party receives the session setup request, but with
indication that the resources shall be made available in order to
establish the session. In queued case the session in not presented to
the B-party but queued by some instance before.

			The procedure at the SIP proxy is then to
include the Warning: Header in to the 180 Ringing or 183 Session
Progress response to provide the required indication to the A-Party. 
			[JRE] Why would a proxy need to do anything for
call waiting? Call waiting is a function of the called UA, which would
generate the necessary indication (182 response, in my opinion) when
appropriate. How would the proxy be in a position to be able to generate
such information?

			[DA]The reasoning behind it is that network
might limit the number of simultaneous sessions, that can be established
with a specific URI. In this case an incoming call to the URI that has
already reached the maximum number of simultaneous sessions would fall
in to the call-waiting state. For this scenario an indication is needed
to the A-party that is it not just normal ringing but call-waiting case.

			Greetings,

			Denis Alexeitsev

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Aug 2007 16:03:37 +0100

Denis,

More below.

John 

> -----Original Message-----
> Sent: 17 August 2007 15:13
> To: [email-masked]
> Cc: Elwell, John
> Subject: AW: [BLISS] Use of Warning: header to transport 
> additionalstatusindications
> 
> Hello John
>  
> [JRE] I understand why a user may wish to receive 
> notifications that call diversion is active, but I fail to 
> see why this should be synchronised with that user's attempts 
> to establish calls. It seems to me that the SIP event 
> framework would be ideally suited to this. A UA could 
> subscribe to an event package, and any information related to 
> the way incoming calls are handled at the proxy (not merely a 
> simple indication that diversion is active) could be provided 
> in notifications. I see this as part of the automated call 
> handling topic in BLISS, so I will add it to my list of 
> things to consider.  
>  
> [DA] I think using event framework would be an overkill for 
> such simple indication and Warning header even literary fits 
> well for this case as a reminder. In addition the 
> interworking with ISDN/GSM would be way to complicated if 
> unbundled from the call establishment state.
[JRE] I don't see how it is needed for interworking with ISDN/GSM
networks, because your proposal is only between a calling user's proxy
and the calling user's UA. The only case I can think of is where the
calling UA is actually an adaptor to an ISDN or GSM phone. I must admit
I forget whether there is Q.931 signalling for this to an ISDN phone and
I don't know what provision there is for a GSM phone. I am doubtful
about the wisdom of assigning SIP codepoints for such specific
interworking purposes, particularly when it only satisfies a small
subset of a potentially bigger problem space of more general
applicability. Let's see what others think.

> extanding the warn-code with the values reflecting the 
> described cases. The spare volumes of warn codes at the 
> moment are 340-369 and 390-399, so the following new warn 
> codes can be defined:
> 
> because the B-party receives the session setup request, but 
> with indication that the resources shall be made available in 
> order to establish the session. In queued case the session in 
> not presented to the B-party but queued by some instance before.
[JRE] I see nothing in the definition of 182 Queued in RFC 3263 to say
that the session is not presented to the B-party. This is just a user
interface matter, and I would imagine, for both queued and call waiting,
the B-party would be given some indication as to the presence of the
queued or waiting call. In other words, I fail to see the difference.

> include the Warning: Header in to the 180 Ringing or 183 
> Session Progress response to provide the required indication 
> to the A-Party. 
> call waiting? Call waiting is a function of the called UA, 
> which would generate the necessary indication (182 response, 
> in my opinion) when appropriate. How would the proxy be in a 
> position to be able to generate such information?
> 
> might limit the number of simultaneous sessions, that can be 
> established with a specific URI. In this case an incoming 
> call to the URI that has already reached the maximum number 
> of simultaneous sessions would fall in to the call-waiting 
> state.
[JRE] I don't see it this way. If the called UA is busy on one session,
and a further INVITE request arrives that cannot be processed normally
because resources are occupied by the existing session, then that is
exactly the situation where the UA might apply call waiting (according
to policy dictated by the user) and send back a 182 response. So in
other words, we get to the call waiting state without exceeding any
network limit to the number of sessions - only the UA limit to the
number of active sessions has been exceeded, which is typically 1
(although could well be more for message sessions, for example, or if
join is requested).
I think what you are talking about here is the case where the "network"
(the inbound proxy) has a policy to limit the number of sessions at the
UA (including those in call waiting state), and that any further
sessions establishment requests beyond this limit also be given call
waiting state, but not by the UA. That could certainly be done, and in
effect the proxy would forward any further INVITE requests to an
alternative UA (which could be collocated with the proxy) that would
queue the requests and send back 182. However, I see two difficulties
with this. How is the user advised of these additional queued requests?
How do they eventually get answered? Presumably the proxy has to somehow
know when the normal UA has resources to accept further requests, and
then cancel them from the alternative UA and forward them to the normal
UA. It all seems rather complicated and all it seems to do is save some
resources at the normal called UA. Shouldn't it be a matter for the
called UA to decide how many it can accept, and then deal with any
additional INVITE requests appropriately, e.g., reject or redirect to an
alternative answering point?

> For this scenario an indication is needed to the 
[JRE] Why does the calling user need to be aware of this subtle
difference between waiting at the called UA and waiting at an
alternative UA somehow closely associated with the proxy?

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Aug 2007 11:39:48 -0400

The 182 Queued response may be a little underspecified.
Its far from clear to me that it is appropriate in the call waiting case.

I fail to see any significant difference between call waiting and a 
phone with two lines for the same number. And little difference between 
that and two phones registered for the same number and sitting on the 
same desk in front of a single person.

In all of these cases, when the second call comes in the callee is 
alerted, and has the option of answering the call. The callee may need 
to do something before answering the phone - put a different call on 
hold, put down his cup of coffee, or whatever. In all these cases why 
isn't 180 the appropriate response?

Why should I expect to get some special call waiting status if it is a 
phone with "call waiting" service and another call active, while not if 
it is a phone with two "lines", or two phones on one desk?

If I am implementing a phone, how do I decide whether to return "call 
waiting" status?

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Aug 2007 17:04:55 +0100

Paul,

I agree that the called UA could choose to send 180, but I think 182 is
equally valid. However, my point really was that I don't see the need
for anything beyond what is already in RFC 3261 for call waiting.

John 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 17 August 2007 16:40
> To: Elwell, John
> Cc: Alexeitsev, D; [email-masked]
> Subject: Re: [BLISS] Use of Warning: header to

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 17 Aug 2007 12:51:44 -0500

I would agree with you John, that what's needed for CWT is already
specified in 3261.

180 versus 182 (to me) is just a matter of 'politeness' if you consider
that it might be nice to send a 182 back if you suspect that the
terminator will take a little longer than usual to evaluate your new
call to them because they're already engaged in a call. It could also be
used to let you know a little bit about why your call might have been
diverted or declined, but this could be equally well handled with a 181
or a 486, 603, etc. response depending upon the desired outcome.

I've never found much use for 182. Can anyone who is using 182 explain
why they are using it?

Regards,
Brian

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Friday, August 17, 2007 11:05 AM
> To: Paul Kyzivat
> Cc: [email-masked]; Alexeitsev, D
> Subject: RE: [BLISS] Use of Warning: header to 
> I agree that the called UA could choose to send 180, but I 
> think 182 is equally valid. However, my point really was that 
> I don't see the need for anything beyond what is already in 
> RFC 3261 for call waiting.
> 
> John 
> 
> > phone with two lines for the same number. And little difference 
> > between that and two phones registered for the same number 
> and sitting 
> > on the same desk in front of a single person.
> > 
> > phone with "call waiting" service and another call active, 
> while not 
> > if it is a phone with two "lines", or two phones on one desk?
> > 
> > >> synchronised with that user's attempts to establish 
> calls. It seems 
> > >> to me that the SIP event framework would be ideally 
> suited to this. 
> > >> A UA could subscribe to an event package, and any information 
> > >> related to the way incoming calls are handled at the proxy (not 
> > >> merely a simple indication that diversion is active) could be 
> > >> provided in notifications. I see this as part of the 
> automated call 
> things to 
> > >> consider.
> > >> simple indication and Warning header even literary fits well for 
> > >> this case as a reminder. In addition the interworking 
> with ISDN/GSM 
> > >> would be way to complicated if unbundled from the call 
> > >> establishment state.
> extanding the 
> because the B-party 
> > >> receives the session setup request, but with indication that the 
> > >> resources shall be made available in order to establish the 
> > >> session. In queued case the session in not presented to 
> the B-party 
> include the Warning: 
> > >> Header in to the 180 Ringing or 183 Session Progress response to 
> > >> provide the required indication to the A-Party.
> call waiting? 
> > >> Call waiting is a function of the called UA, which would 
> generate 
> > >> the necessary indication (182 response, in my opinion) when 
> > >> appropriate. How would the proxy be in a position to be able to 
> > >> generate such information?
> > >>
> might limit the 
> > >> number of simultaneous sessions, that can be established with a 
> > >> specific URI. In this case an incoming call to the URI that has 
> > >> already reached the maximum number of simultaneous 
> sessions would 
> > >> fall in to the call-waiting state.
> > >> For this scenario an indication is needed to the A-party 
> that is it 
> > >> not just normal ringing but call-waiting case.

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 17 Aug 2007 13:04:32 -0500

I don't know about everyone else, but just sitting here trying to work
through in my head how all of these indicators are going to sync up
during a relatively quick call establishment phase is making my head
spin with race conditions (esp. with SUB/NOTIFY in parallel with the
INVITE).

If someone were to want to provide this type of service, I think you'd
be best served by simply connecting your call to a media source prior to
routing the INVITE onward to play the CFD active tone. I don't think
warning headers were intended to trigger services like this, and it's
pretty unlikely that clients will pay attention to it the way you want.
I've seen implementations that use the Alert-Info header for this type
of function (essentially convey the information that supervision used to
handle for us) and it's something that is going to be very
non-compatible with most every implementation out there (read: nobody is
going to honor it, so the service will break).

A problem with the Warning header (or Alert-Info for that matter)
approach is that it these headers are in responses that ostensibly
describes something related to the party you are intending to reach, not
the party making the call.

Regards,
Brian

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Friday, August 17, 2007 9:31 AM
> To: Alexeitsev, D; [email-masked]
> in notifications.
> I see this as part of the automated call handling topic in 
> BLISS, so I will add it to my list of things to consider.  
> 	 
> 	[DA] I think using event framework would be an overkill 
> for such simple indication and Warning header even literary 
> fits well for this case as a reminder. In addition the 
> [KED} These indications that diversion is active are 
> equivalent to the old black phone equivalent of giving 
> special dial tone when diversion is active and so on. When 
> they were discussed in the evolution of the ISDN, they were 
> regarded as part of the stimulus protocol rather than the 
> functional protocol. Therefore no ISDN functional protocol 
> was ever defined for them (at least I cannot see anything in 
> ETSI EN 300 207-1
> V3.1.1 (2001-06) which is the latest version of the DSS1 
> protocol document, and for which there should be a direct 
> ITU-T equivalent. 
> 
> Rather, some stimulus indication can be given, such as a tone 
> or announcement. Now there have been extensive discussions in 
> the past on stimulus versus functional in SIP...
> 
> Regards
> 
> Keith
> 
> in notifications.
> I see this as part of the automated call handling topic in 
> BLISS, so I will add it to my list of things to consider.  
> 	 
> 	[DA] I think using event framework would be an overkill 
> for such simple indication and Warning header even literary 
> fits well for this case as a reminder. In addition the 
> 			A proposal is to reuse the Warning: 
> header by extanding the warn-code with the values reflecting 
> the described cases.
> The spare volumes of warn codes at the moment are 340-369 and 
> 390-399, so the following new warn codes can be defined:
> 
> 			[DA] It is not exactly the same as 
> queued, because the B-party receives the session setup 
> request, but with indication that the resources shall be made 
> available in order to establish the session. In queued case 
> the session in not presented to the B-party but queued by 
> some instance before.
> 
> 			
> 			The procedure at the SIP proxy is then 
> to include the Warning: Header in to the 180 Ringing or 183 
> 			[JRE] Why would a proxy need to do 
> anything for call waiting? Call waiting is a function of the 
> called UA, which would generate the necessary indication (182 
> response, in my opinion) when appropriate. How would the 
> proxy be in a position to be able to generate such information?
> 
> 			[DA]The reasoning behind it is that 
> network might limit the number of simultaneous sessions, that 
> can be established with a specific URI. In this case an 
> incoming call to the URI that has already reached the maximum 
> number of simultaneous sessions would fall in to the 
> call-waiting state. For this scenario an indication is needed

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Aug 2007 16:22:41 -0400

Another way of achieving this sort of thing, if you want it (why?), is 
with an Alert-Info header in the response. The UAC may act on that to 
generate a selected local ringback.

But IMO using ringback, however triggered, to indicate you have call 
forwarding enabled is just an old PSTN hack. And does the pstn even do 
it as part of the response to a call establishment request? I thought it 
resulted in an altered dial tone, which in sip terms means it is known 
to the phone *before* an invite is sent.

A subscription can deliver the info to the UA, and it can then remember 
the state. If it has a suitable UI it can light a light or put something 
on a display about the state. If not it can alter the dialtone it plays.

There could be a special subscription for this. But I expect the kind of 
environment where this is interesting may well already involve a 
subscription to the config event package. It would then be simple to 
include the forwarding mode as a piece of the configuration state, and 
send a notification if/when it is changed. (I.e. because you went to a 
web page and changed it.)

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 17 Aug 2007 16:19:30 -0500

> Sent: Friday, August 17, 2007 3:23 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: DRAGE, Keith (Keith); Alexeitsev, D; [email-masked]
> Another way of achieving this sort of thing, if you want it 
> (why?), is with an Alert-Info header in the response. The UAC 
> may act on that to generate a selected local ringback.

IMHO- Alert-Info is generally a bad idea. I know it's used, but it's
usually used as a hack from what I've seen. I certainly wouldn't trust
an Alert-Info from another domain, so in the case of a roaming mobile,
it seems fairly unlikely that it would be proxied along. I'm pretty
certain that most operators actually strip this header out of any
signaling received from another proxy and only allow Alert-Info headers
generated by an authoritative/local outbound type proxy toward the UA to
be passed along.

> 
> But IMO using ringback, however triggered, to indicate you 
> have call forwarding enabled is just an old PSTN hack. And 
> does the pstn even do it as part of the response to a call 
> establishment request? I thought it resulted in an altered 
> dial tone, which in sip terms means it is known to the phone 
> *before* an invite is sent.

It's handled via line supervision. Serious PSTN voodoo.

> 
> A subscription can deliver the info to the UA, and it can 
> then remember the state. If it has a suitable UI it can light 
> a light or put something on a display about the state. If not 
> it can alter the dialtone it plays.

This seems more reasonable, especially for a form-factor smart enough to
run SIP. I've seen implementations that do this in the wild. I thought
we were talking about trying to do it inline with the INVITE.

> 
> There could be a special subscription for this. But I expect 
> the kind of environment where this is interesting may well 
> already involve a subscription to the config event package. 
> It would then be simple to include the forwarding mode as a 
> piece of the configuration state, and send a notification 
> if/when it is changed. (I.e. because you went to a web page 
> and changed it.)
> 
> 	Paul
> 
> Brian Stucker wrote:
> > be best served by simply connecting your call to a media 
> source prior 
> > to routing the INVITE onward to play the CFD active tone. I don't 
> > think warning headers were intended to trigger services 
> like this, and 
> > it's pretty unlikely that clients will pay attention to it 
> the way you want.
> > of function (essentially convey the information that 
> supervision used 
> > to handle for us) and it's something that is going to be very 
> > non-compatible with most every implementation out there 
> (read: nobody 
> > is going to honor it, so the service will break).
> > 
> > describes something related to the party you are intending 
> to reach, 
> > not the party making the call.
> > 
> > Regards,
> > Brian
> > 
> notifications that 
> >> synchronised with that user's attempts to establish calls. 
> It seems 
> >> to me that the SIP event framework would be ideally suited 
> to this. A 
> >> UA could subscribe to an event package, and any 
> information related 
> >> to the way incoming calls are handled at the proxy (not merely a 
> >> simple indication that diversion is active) could be provided in 
> >> notifications.
> BLISS, so 
> >> I will add it to my list of things to consider.
> >> 	 
> for such 
> >> case as a reminder. In addition the interworking with 
> ISDN/GSM would 
> >> be way to complicated if unbundled from the call 
> establishment state.
> >>
> >> [KED} These indications that diversion is active are equivalent to 
> >> the old black phone equivalent of giving special dial tone when 
> >> diversion is active and so on. When they were discussed in the 
> >> evolution of the ISDN, they were regarded as part of the stimulus 
> >> protocol rather than the functional protocol. Therefore no ISDN 
> >> functional protocol was ever defined for them (at least I 
> cannot see 
> >> anything in ETSI EN 300 207-1
> >> announcement. Now there have been extensive discussions in 
> the past 
> notifications that 
> >> synchronised with that user's attempts to establish calls. 
> It seems 
> >> to me that the SIP event framework would be ideally suited 
> to this. A 
> >> UA could subscribe to an event package, and any 
> information related 
> >> to the way incoming calls are handled at the proxy (not merely a 
> >> simple indication that diversion is active) could be provided in 
> >> notifications.
> BLISS, so 
> >> I will add it to my list of things to consider.
> >> 	 
> for such 
> >> case as a reminder. In addition the interworking with 
> ISDN/GSM would 
> >> be way to complicated if unbundled from the call 
> establishment state.
> >>
> >> header by extanding the warn-code with the values reflecting the 
> >> described cases.
> queued, because the B-party 
> >> resources shall be made available in order to establish 
> the session. 
> >> In queued case the session in not presented to the B-party 
> but queued 
> >> by some instance before.
> >>
> >> 			
> to include the Warning: 
> anything for call waiting? Call 
> >> necessary indication (182 response, in my opinion) when 
> appropriate. 
> >> How would the proxy be in a position to be able to generate such 
> >> information?
> >>
> network might limit the number 
> >> of simultaneous sessions, that can be established with a specific 
> >> URI. In this case an incoming call to the URI that has already 
> >> reached the maximum number of simultaneous sessions would 
> fall in to 
> >> the call-waiting state. For this scenario an indication is 
> needed to 
> >> the A-party that is it not just normal ringing but 
> call-waiting case.
> >>
> >> 			Greetings,
> >>
> >> 			Denis Alexeitsev
> >>
> >>

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 20 Aug 2007 10:41:53 +0200

[DA] Because the call-waiting service is based on the network policy
(for example how many simultaneous session can be active over a given
URI) the phone does not have to anything for this indication. It is
network that adds this information to a response.

My experience with UAs tells me that it is hard to say what kind of tone
if at all the UA will apply on the receipt of the 182 Queued. That is
why it is safer to add this Warning header to a 180 response. The UA
that does not understand the Warning will ignore it and provide the
normal ring back tone. The UA that knows the header will apply some
additional indication.

The question is does anything prohibits the use of Warning header to
convey some additional indication on the status of the call or the
status of the configuration?

Greetings,
Denis Alexeitsev

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 20 Aug 2007 10:44:53 +0200

[DA] Got the point. Is there an appropriate parameter that can be used
to convei some indication from the home proxy to the A party?

Greetings,
Denis Alexeitsev

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Aug 2007 09:51:15 +0100

Denis,

See below.

John 

> Sent: 20 August 2007 09:45
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: AW: [BLISS] Use of Warning: header 
> totransportadditionalstatusindications
> 
> 
[JRE] I don't think the requirement has arisen before. Based on
discussions on this thread to date, it seems that diversion is not a
compelling case for introducing such a capability.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 20 Aug 2007 11:17:29 +0200

In the ISDN, there the call waiting service encompasses both a network
recognition of insufficient resources to process the call and a terminal
recognition of insufficient resources to process the call. 

Surely from the called side, it is irrelevant who makes who makes this
decision to send an indication. Therefore we should not be
distinguishing the two cases as different responses, which is what is
currently implied.

Regards

Keith

> Sent: Monday, August 20, 2007 9:42 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: AW: [BLISS] Use of Warning: header totransport 
> If I am implementing a phone, how do I decide whether to 
> return "call waiting" status?
> 
> [DA] Because the call-waiting service is based on the network 
> policy (for example how many simultaneous session can be 
> active over a given
> URI) the phone does not have to anything for this indication. 
> It is network that adds this information to a response.
> 
> My experience with UAs tells me that it is hard to say what 
> kind of tone if at all the UA will apply on the receipt of 
> the 182 Queued. That is why it is safer to add this Warning 
> header to a 180 response. The UA that does not understand the 
> Warning will ignore it and provide the normal ring back tone. 
> The UA that knows the header will apply some additional indication.
> 
> The question is does anything prohibits the use of Warning 
> header to convey some additional indication on the status of 
> the call or the status of the configuration?
> 
> Greetings,
> Denis Alexeitsev
> 
>

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 20 Aug 2007 09:09:41 -0500

We're still talking about the call forwarding enabled indication here,
right (not call waiting)?

If so, then I think what it sounds like you're asking for is really two
things, not one, and it's the second thing that people are having the
most heartache about. You can send a notification using RFC-3265 back to
party A at any time to tell them that call forwarding is active. The
terminal can then do whatever it pleases with that information: change
the UI, play a blurp when the user next dials, etc.

The second thing it sounds like you want, though, in order to mimic
existing PSTN behavior (where there may be no opportunity to send
information outside of an estblished circuit) is that you want this
information to be sent only once the user has initiated a call using the
existing set of messages that are normally exchanged for a call setup.

Is this correct? Because I don't think folks are opposed to having the
proxy send information about the state of the user's services, but that
there isn't a clear way of sending this information via response codes
and headers in response messages while establishing a session.

Regards,
Brian

> Sent: Monday, August 20, 2007 3:45 AM
> To: Stucker, Brian (RICH1:AR00); [email-masked]; 
> [email-masked]
> A problem with the Warning header (or Alert-Info for that 
> matter) approach is that it these headers are in responses 
> that ostensibly describes something related to the party you 
> are intending to reach, not the party making the call.
> 
> [DA] Got the point. Is there an appropriate parameter that 
> can be used to convei some indication from the home proxy to 
> the A party?
> 
> Greetings,
> Denis Alexeitsev
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Aug 2007 10:38:49 -0400

Brian Stucker wrote:
> Is this correct?

I'm curious to see the answer to this.

If the answer is YES, then I have to ask WHY? Doing it that way in sip 
just because the PSTN did it that way isn't a good enough reason. (If 
the issue is gatewaying between the two models, then it may be worth 
discussing how that might be done.)

> Because I don't think folks are opposed to having the

---

From: "Alexeitsev, D" <[email-masked]>
Date: Mon, 20 Aug 2007 18:11:08 +0200

> right (not call waiting)?

There are two distinctive issues

A) call forwarding enabled indication
B) call waiting indication

The initial idea was to use the Warning header for both of them. After
the discussion it seams like for the case A) the Warning header is not
applicable as it shall come from the B-party. By the way - where is this
limitation defined?

For the case B) I still think that Warning header could be reused, but
I'm open to any proposals. If there is any interest of course.

>discussing how that might be done.)

Exactly - the interworking restrictions. Interworking unsynchronised
SUB/NOT with call progress messages on the ISDN side that carry this
indication is not the easiest thing to do.

Greetings,
Denis Alexeitsev

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Aug 2007 20:57:43 +0100

Denis,

> indication is not the easiest thing to do.
[JRE] I agree in this particular case, interworking NOTIFY would be
difficult. However, I cannot get enthusiastic about a warning code for
this purpose.
1. Call from PSTN. A warning code helps only if the called UA implements
it, which for standard SIP devices is unlikely. There is just as much
chance (maybe more chance) that a UA will issue a 182 as issue a warn
code. Of course, if call waiting is done at the proxy (which I don't
think is the best place to do it - I can't figure out exactly how it
would work in all cases) the proxy could issue a warn code, but I don't
see this as a mainstream case.
2. Call to PSTN. A standard SIP device as calling UA is unlikely to
understand a warn code. There is probably more chance it will indicate
something meaningful on receipt of a 182.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Aug 2007 16:33:04 -0400

Denis,

How do you imagine this working (indicating forwarding is enabled locally)?

My understanding is that the ISDN/whatever model is that this is 
signaled via a special dial tone, much as MWI is. As a result, it is 
signaled when you pick up the phone, *before* initiating a call.

If you were to do this via a header in the response to an invite, then 
the device won't know about it until *after* a call has been dialed. So 
then when/how do you render an indication to the user? After he hangs up 
and then picks up the phone again? That doesn't seem very useful.

You could use sub/not but refuse to maintain the subscription. Just send 
the initial notification with an indication the subscription has been 
terminated. This would only be useful for polling. But you could then 
have your device poll as soon as the device goes off-hook.

But for any of this to matter it means that you have a sip phone 
connected through a gateway to an ISDN system that is handling the 
forwarding for it. That seems pretty peculiar. Wouldn't the forwarding 
for a sip phone normally be done by a sip server?

	Paul

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 21 Aug 2007 14:34:54 +0200

Thank you for the comments Paul

>signaled when you pick up the phone, *before* initiating a call.

There is a difference in implementation for analog and ISDN/GSM lines.
Analog lines indeed have the tone applied immediately after off-hook.
ISDN/GSM terminals provide the display information based on the generic
notification indicator received in the call progress messages. There is
no dial tone for GSM at all and ISDN supports dialling without going
off-hook. That is why the off-hook tone can not be always applicable
here.

Greetings,
Denis Alexeitsev

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 21 Aug 2007 15:02:40 +0200

Comments below

>something meaningful on receipt of a 182.

The UAs that are interested in this indication (Access Gateways, IAD,
new SIP terminals) will implement the Warning: header and become new
functionality. The ones that are not interested - legacy SIP terminals
will not get harmed as Warning: header is optional. Is not it the
rational way of adding new functionality?

I still fail to see a technical problem with the call-waiting indication
being transferred by means of Warning: or any other header (proposals?).

Greetings,
Denis Alexeitsev

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2007 09:11:50 -0400

So, if you forget that you enabled forwarding, and you don't get any 
calls for a long time, you will only discover the condition if you 
*make* a call???

That is not a service that I would be trying hard to emulate.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 21 Aug 2007 08:20:42 -0500

> Sent: Tuesday, August 21, 2007 8:03 AM
> To: [email-masked]; [email-masked]; Stucker, 
> Brian (RICH1:AR00)
> Cc: [email-masked]
> Subject: Use of Warning: for Call-Waiting
> 
> Comments below
> 
> The UAs that are interested in this indication (Access 
> Gateways, IAD, new SIP terminals) will implement the Warning: 
> header and become new functionality. The ones that are not 
> interested - legacy SIP terminals will not get harmed as 
> Warning: header is optional. Is not it the rational way of 
> adding new functionality?
> 
> I still fail to see a technical problem with the call-waiting 
> indication being transferred by means of Warning: or any 
> other header (proposals?).

The warning header is designed to carry human-consumable text indicating
further information in the case of a problem arising while establishing
a session. Take a look at section 20.43 and I think you'll quickly see
that it was not intended to kick off a service and if, as you say, the
UAs, gateways, IADs and new SIP terminals implement this, they'll not be
implementing the intent of this SIP header. 

On this basis, you could say that the Organization header is an
appropriate place to put information to key off a service, or the
Subject header. If everyone agrees that it's so, and the header isn't
used for other essential functions, then it'll "work" but it won't be
interoperable outside of your development community which I assume is
important since you're posting to a list dedicated to solving interop
problems. :)

Alert-Info is more appropriate, but as a point in fact, if you go and
talk to folks familiar with Alert-Info they'll tell you it might as well
be a P-header because it's regularly stripped from messages and in order
to make this work you'll have to specify a resource that is local to the
device unless you want the devices to go to a box to play the
appropriate tone. You could also investigate using early media along
with RFC-4733 to denote playing a particular tone during call setup as
another alternative.

There are also techniques where you can have the BBUA point the call to
a box that generates early media tones and announcements to generate the
indication you are looking for in-band. As long as the client renders
early media appropriately (and supports multiple responses to an offer
correctly unless a relay is used) this will also work in many cases, but
will break other services and may be fragile once forking is introduced
into the mix (see my early media coping draft for a description of this
type of service behavior and the associated problems).

Regards,
Brian

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 21 Aug 2007 14:22:23 +0100

Denis,

Below.

John 

> Sent: 21 August 2007 14:03
> To: Elwell, John; [email-masked]; [email-masked]
> Cc: [email-masked]
[JRE] Sure, that is the normal way, but we only add new functionality
when existing protocol mechanisms are inadequate. The advantage of using
an existing mechanism is that existing devices just might support it.
Hence my suggestion of 182.

> indication
[JRE] Perhaps not a technical reason, but I am generally not a fan of
the Warning header field. A lot of devices just ignore it, and asking a
device that does not take account of the Warning header field when
presenting information at its user interface to start taking it into
account for this one case seems overkill. Had you thought about a new
18x response code if you regard 180 and 182 as unsuitable?

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 21 Aug 2007 16:54:48 +0200

Hi,

just for the Call Waiting case, I also think it would be the best solution if this CW information for the caller is carried in the 180. Because the basic situation is, that the call is presented to the callee. But, as Brian said, it probably takes a littlebit longer until the callee really answeres the call (e.g. because he first puts another call on hold), so it's good to inform the caller about that fact.
So if the caller is informed of the ringing with the 180 it's sufficient, a very useful additional information for the caller is the information about the CW case at the callee.

So what we are looking for is something within the 180 to give the caller additional CW information, which would at least make it possible for the caller's terminal to render the information to the caller.

Regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: Elwell, John [mailto:[email-masked]] 
> Gesendet: Dienstag, 21. August 2007 15:22
> An: Alexeitsev, Denis; [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: [BLISS] RE: Use of Warning: for Call-Waiting
> 
> 
> Denis,
> 
> Below.
> 
> John 
> 
> Gateways, IAD,

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 21 Aug 2007 11:33:31 -0500

Hi Martin,

I'm not aware of an appropriate header to convey this information in a 180. I believe that's why John and I were mentioning using a different response code to convey the difference in the call progression (much like we have 183 versus 180 today).

The downside is that terminals probably won't recognize a CWT specific 18x response, but unless they're supporting a mechanism for conveying this information today, they won't recognize an alternate method of signaling this either. So if any given way of doing this has the downside that it requires uptake by devices to support it, then we should try to pick the best possible solution to the problem rather than being a slave to a non-existant backwards compatability problem.

I've typically seen this type of service implemented using an application server/BBUA that is manipulating the early media streams presented to the originator. The reason for doing this wasn't that it was particularly brilliant, but that it required the terminals to do very little other than render the early media RTP that was sent to them.

The downside to this approach is that it creates conditions to aggravate the existing problems within SIP with respect to early media, and in particular, interworking PSTN early media with a SIP device.

Regards,
Brian 

> From: Huelsemann, Martin [mailto:[email-masked]] 
> Sent: Tuesday, August 21, 2007 9:55 AM
> To: [email-masked]; Alexeitsev, D; 
> [email-masked]; Stucker, Brian (RICH1:AR00)
> Cc: [email-masked]
> Subject: AW: [BLISS] RE: Use of Warning: for Call-Waiting
> 
> Hi,
> 
> just for the Call Waiting case, I also think it would be the 
> best solution if this CW information for the caller is 
> carried in the 180. Because the basic situation is, that the 
> call is presented to the callee. But, as Brian said, it 
> probably takes a littlebit longer until the callee really 
> answeres the call (e.g. because he first puts another call on 
> hold), so it's good to inform the caller about that fact.
> So if the caller is informed of the ringing with the 180 it's 
> sufficient, a very useful additional information for the 
> caller is the information about the CW case at the callee.
> 
> So what we are looking for is something within the 180 to 
> give the caller additional CW information, which would at 
> least make it possible for the caller's terminal to render 
> the information to the caller.
> 
> 
> Regards, Martin
> 
> 
> 
> 
> > when existing protocol mechanisms are inadequate. The advantage of 
> > using an existing mechanism is that existing devices just might 
> > support it.
> > > indication being transferred by means of Warning: or any other 
> > > header (proposals?).
> > the Warning header field. A lot of devices just ignore it, 
> and asking 
> > a device that does not take account of the Warning header 
> field when

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 21 Aug 2007 17:42:45 +0100

I wouldn't go down the media server path. I prefer an indication in a 18x response that the UA can render by whatever means is appropriate (e.g., in the language of the caller). I thought 182 would fit this, but I guess a further consideration is what do you want an existing UA to do? If you wish it to apply ringback tone as a result, then 180 seems to be the appropriate response code. If you don't want it to give ringback tone, then don't use 180.

Assuming we choose 180, as Martin suggested in his last message, then I don't particularly like using the Warning header field for this purpose, but I don't have an alternative suggestion (inventing a new header field for this also seems excessive). So let's see what others prefer.

John

> From: Brian Stucker [mailto:[email-masked]] 
> Sent: 21 August 2007 17:34
> To: Huelsemann, Martin; Elwell, John; Alexeitsev, D; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [BLISS] RE: Use of Warning: for Call-Waiting
> 
> Hi Martin,
> 
> I'm not aware of an appropriate header to convey this 
> information in a 180. I believe that's why John and I were 
> mentioning using a different response code to convey the 
> difference in the call progression (much like we have 183 
> versus 180 today).
> 
> The downside is that terminals probably won't recognize a CWT 
> specific 18x response, but unless they're supporting a 
> mechanism for conveying this information today, they won't 
> recognize an alternate method of signaling this either. So if 
> any given way of doing this has the downside that it requires 
> uptake by devices to support it, then we should try to pick 
> the best possible solution to the problem rather than being a 
> slave to a non-existant backwards compatability problem.
> 
> I've typically seen this type of service implemented using an 
> application server/BBUA that is manipulating the early media 
> streams presented to the originator. The reason for doing 
> this wasn't that it was particularly brilliant, but that it 
> required the terminals to do very little other than render 
> the early media RTP that was sent to them.
> 
> The downside to this approach is that it creates conditions 
> to aggravate the existing problems within SIP with respect to 
> early media, and in particular, interworking PSTN early media 
> with a SIP device.
> 
> Regards,
> Brian 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2007 14:01:10 -0400

IMO this is all about "a distinction without a difference". I see no 
useful reason to either convey or render this information.

There are multitudes of ways in which a UAS (or group of UASs associated 
with an AOR) and the users of those device(s) can choose to multiplex 
themselves among multiple incoming calls.

Does it make sense to try to enumerate those, signal which one is being 
applied back to the UAC, and expect the UAC to signal it to the caller? 
I don't think so. In this case the intent is to single out a particular 
way of doing the multiplexing and signal that one. Why is it more 
important than any other way?

We already have something to give you info about the status of the 
callee - presence. It can tell you "on the phone" and a host of other 
things.

	Paul

---

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 22 Aug 2007 16:26:35 +0200

Comments inline 

>important since you're posting to a list dedicated to solving interop

Well my little understanding of standard bodies tells me that if
everyone agrees to use the Organization header, than it is the standard.
Having no standard at all is even less beneficial to interoperability
isn't it?  :)
The IETF developer community and TISPAN/3GPP industry community together
cover probably 70% of the telecom industry, so everything we define here
is the de facto standard.

>You could also investigate using early media along with RFC-4733 to
denote playing a particular tone during call setup as another
alternative.

It is not about the tones, as I've pointed out the ISDN and GSM
terminals provide a visual indication, so a parameter is needed. I'm not
particularly keen on the Warning header but used it as an example to
boost the discussion.

---

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 22 Aug 2007 16:36:32 +0200

Comments below

>18x response code if you regard 180 and 182 as unsuitable?

If new response codes are defined, than we have an undefined behaviour
at the deployed UAs. How would an IAD or a soft client react when it
receives for example a 187 response?

Would it 
A) apply the ring tone,
B) default special tone,
C) Nothing, as it only implements a ring tone with static mapping to the
180

That is why I think a header for existing 180, 183 responses would be
more appropriate.

Greetings,
Denis Alexeitsev

---

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 22 Aug 2007 16:41:42 +0200

Comments below

>calls for a long time, you will only discover the condition if you 

Correct

>That is not a service that I would be trying hard to emulate.

I would be happy to discuss a proposal on how to make the service better
without making interworking impossible.

Greetings,
Denis Alexeitsev

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 22 Aug 2007 09:55:31 -0500

> Sent: Wednesday, August 22, 2007 9:37 AM
> Subject: AW: Use of Warning: for Call-Waiting
> 
> Comments below
> 
> and asking a 
> If new response codes are defined, than we have an undefined 
> behaviour at the deployed UAs. How would an IAD or a soft 
> client react when it receives for example a 187 response?
> 
> Would it
> A) apply the ring tone,
> B) default special tone,
> C) Nothing, as it only implements a ring tone with static 
> mapping to the 180

Probably C. But sending a 183 after a 180 is likely to be just as
provocative an action at the UA as sending a second 180 or sending the
example 187 response. What I don't think we want to do here is have 187
mean ring tone A, 188 mean special tone B, 186 mean some other tone C
except if you're in Antartica in which case it means tone R, etc, etc...

Ringback procedures in SIP implementations are pretty fragile.

> 
> That is why I think a header for existing 180, 183 responses 
> would be more appropriate.
> 
> Greetings,
> Denis Alexeitsev
> 
> 
>

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 22 Aug 2007 10:05:58 -0500

> Sent: Wednesday, August 22, 2007 9:27 AM
> To: Stucker, Brian (RICH1:AR00); [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Well my little understanding of standard bodies tells me that 
> if everyone agrees to use the Organization header, than it is 
> the standard.

Just because someone writes something down doesn't make it a good idea.
:)

> Having no standard at all is even less beneficial to 
> interoperability isn't it?  :) The IETF developer community 
> and TISPAN/3GPP industry community together cover probably 
> 70% of the telecom industry, so everything we define here is 
> the de facto standard.
> 
> It is not about the tones, as I've pointed out the ISDN and 
> GSM terminals provide a visual indication, so a parameter is 
> needed. I'm not particularly keen on the Warning header but 
> used it as an example to boost the discussion.

I had not caught the need for a visual indication. I thought you were
trying to put a tone or stutter into the existing ringback heard by the
originator. I think your requirements here really fall into a gap. Some
folks will be opposed to the service itself (which, although I don't
particularly like the service you describe I don't think it should
prohibit the discussion of an acceptable way of signaling what you're
looking for), some folks will not want to add yet-another-header and
there's not a real great match that I'm aware of in an existing header
to solve your issue, some folks will want to overload the semantics of
an existing header or response code or define a new response code...

For call diversion indication to a terminal, I think using 3265 is
really the best solution. When/how it gets rendered will leave you with
options going forward. For gateway to gateway communication though, I
can see where this would be more difficult to deal with but not
impossible though. It would look something like the SMDI indications
that come back for MWI that the network is able to process. Unless we
think this is an area of the protocol that is likely to grow in the
future (I doubt that it will ever extend beyond PSTN interworking)
you're probably looking at using a new p-header quite honestly.

For Call waiting, I'm not sure why a 182 and some specified behavor at
the UA wouldn't do the trick.

Regards,
Brian

---

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 22 Aug 2007 17:36:16 +0200

Response below

>Ringback procedures in SIP implementations are pretty fragile.

That is why I don't want to mess with the existing procedures, but to
extend the 180 with an indication.
If a UA will implement the new parameter it will be able to provide an
additional service to the user. If not, then well known service will not
get corrupted.

Greetings,
Denis Alexeistev

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Aug 2007 13:53:52 -0400

Based on what I have heard so far I do think that Alert-Info is the best 
fit. I have proposed before, in other fora, that Alert-Info be used with 
a URN. It is then up to the recipient to understand the meaning of the 
URN - there are no games with trying to reference local files on the 
device, or forcing network access.

Certainly Alert-Info may be stripped in some environments, but as 
described, this should not be a problem in the environments where this 
is desired.

Using A-I with a URN you just have to go find, or define, a suitable 
family of URNs to denote the things you want to convey.

	Paul

---

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 23 Aug 2007 11:35:05 +0200

Thanks for the proposal.

>family of URNs to denote the things you want to convey.

Are there any objections, comments from the group to the use of the
Alert-Info header to convey additional information about the
call-waiting service?

Greetings,
Denis Alexeitsev

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Aug 2007 08:30:04 -0400

To elaborate, there are multiple ways to use this technique, depending 
on the approach you use for the URN:

- you can use a URN that identifies what is to be presented
   in the alert. E.g. urn:tones:call-waiting-tone
   This would be a way to identify a particular sound
   (or picture, or text) by name rather than reference.

- you can use a URN that identifies semantically what
   is to be presented, rather than a particular presentation.
   E.g. urn:alerts:call-waiting
   This way only the concept has been conveyed and it is
   up to the recipient to decide what sort of presentation
   is appropriate for the particular device and user.
   One UA might play a tone, while another displays an
   indicator on a display.

Either way, this approach is only appropriate if what is being conveyed 
is truly *alert* info - info that is intended to impact the way the 
alert is done for the current call.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Aug 2007 13:41:30 +0100

I would go for the semantic approach, so that no assumptions need to be
made about the nature of the user interface on the calling device and it
can apply to media other than audio, e.g., real-time text. Or it might
be used in an intelligent way, e.g., offer the user the option of being
informed when the called user is free (i.e., offer to set up a dialog
package subscription). Also it might be usable by an automaton in some
way. Finally, I think it would be better from a PSTN interworking point
of view.

John

> Sent: 23 August 2007 13:30
> To: Alexeitsev, D
> Cc: [email-masked]; Elwell, John; [email-masked]
> Subject: Re: AW: [BLISS] RE: Use of Warning: for Call-Waiting
>

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 23 Aug 2007 22:18:01 -0500

No. I think it's probably the best fit without adding new headers to
make it happen. The trick will all be in the urn definition though.

I would strongly oppose something like http://localhost/tone/cwt1.wav or
similar being proposed as the value. I've done this myself in a past
life and it was a stupid thing to do in retrospect for a number of
reasons.

Regards,
Brian 

> Sent: Thursday, August 23, 2007 4:35 AM
> To: [email-masked]; Stucker, Brian (RICH1:AR00)
> Cc: [email-masked]; [email-masked]
> Are there any objections, comments from the group to the use 
> of the Alert-Info header to convey additional information 
> about the call-waiting service?
> 
> Greetings,
> Denis Alexeitsev
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Aug 2007 15:10:16 -0400

> life and it was a stupid thing to do in retrospect for a number of

I agree. That sort of usage is *evil*.

	Paul

---

From: [email-masked]
Date: Sat, 25 Aug 2007 23:04:31 -0400

From: "Alexeitsev, D" <[email-masked]>

"... a desire to provide additional information ..."

I don't think this is a good idea.

In regard to telling the caller that his call is being diverted, the
181 response seems to be already defined.

In the case of call waiting, if the called party is being alerted now,
then 180 is a good response.  If the called party is not being alerted
right now, but is expected to be alerted in the future, 182 has been
defined for this purpose.

In regard to indicating in some way to the caller that he has call
forwarding engaged for his address, this should not be encoded within
a dialog he makes to another party, because it is not a fact *about
that dialog*.  Instead, the mechanism by which he activates call
forwarding should include a mechanism by which his UA can know whether
call forwarding is activated, and inform the user of that status.  But
since no such mechanism has been standardized, we are not in a
position to discuss it.

Dale

---

From: [email-masked]
Date: Mon, 27 Aug 2007 16:08:13 -0400

From: "Brian Stucker" <[email-masked]>

   > In the case of call waiting, if the called party is being 
   > alerted now, then 180 is a good response.  If the called 
   > party is not being alerted right now, but is expected to be 
   > alerted in the future, 182 has been defined for this purpose.

   True. I agree wrt 180, but if there's a delay, sending a 182 will
   typically not trigger ringback at the originator to start. The "example"
   in RFC-3960, section 3.2 is the model most UAs use to generate local
   ringback, so a 182 would typically cause nothing to be heard at the
   originator, they potentially freak out thinking the call died, and
   potentially hangup as a result.

That's true, but that's also the point of it.  If the called UA (or
service provider) wants the calling UA to play ringback, it sends
180.  If it wants to indicate that the call is being forwarded but
*not* to play ringback, it sends 182.

   > In regard to indicating in some way to the caller that he has 
   > call forwarding engaged for his address, this should not be 
   > encoded within a dialog he makes to another party, because it 
   > is not a fact *about that dialog*.  Instead, the mechanism by 
   > which he activates call forwarding should include a mechanism 
   > by which his UA can know whether call forwarding is 
   > activated, and inform the user of that status.  But since no 
   > such mechanism has been standardized, we are not in a 
   > position to discuss it.

   The problem here is with gateway-to-gateway signaling. The SIP UA for
   the calling party is a gateway and not an end-device. I completely agree
   that the best way of handling this at the endpoint is through some other
   mechanism (RFC-3265 springs to mind along with a notification of a
   change in configuration data for the subscriber). Given that, and the
   very likely problem that something will eventually get specified
   regardless of the advice of those on this mailing list, I'd prefer that
   it at least be something that has the least amount of impact to the way
   SIP works naturally.

This automatically introduces some complexities, however.  If the SIP
UA is a gateway, then how is the gateway going to set up the call
forwarding that we want to report back to the user?  The special dial
tone used to indicate to the caller that call forwarding is in effect
for this UA and the user of special dial codes to set up call
forwarding are two parallel responses to the poverty of the POTS user
interface.

In the best case, a native SIP UA has a special interface and
mechanism to control call forwarding, and to indicate that call
forwarding is active.

In the next case, a gateway intercepts appropriate dial codes from a
black phone and provides a special dial tone.  The gateway is
translating from a more orthogonal SIP interface to call forwarding to
the more impoverished black phone interface.

In the worst case, the gateway is completely unaware of call
forwarding.  In the outgoing direction, we can probably have the proxy
recognize and divert special dial codes for call forwarding.  But the
reverse channel is harder to manipulate.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 27 Aug 2007 19:47:56 -0500

It seems to me that what you are trying to replicate is an indication of
"call diversion/
forwarding" being currently activated.

In the current PSTN model, because of device limitations, this is often
a tone when you pick up the handset (so it is not a real asynchronous
notification).
If you are lucky enough to have a phone with a display, it can be a
visual indication
(in which case it is anynchronous).

The 182 sugested by others is NOT appropriate for what you are looking
for. The 182
tells the caller when making a call that the call is being diverted.

You are looking for an indication for a User that his own device has
diversion
activated, and that it will therefore not be able to receive calls.

The problem with this feature is that it doesn't really match how things
work
in SIP, where instead of simple "Call Forwarding == ON | OFF", you
normally have
a set of routing rules applied to you.  Sometimes, it is done through a
REGISTER
message, sometimes it's done with configuration on the proxy (e.g.,
scripts allowing
routing calls in parallel or in sequence to other AORs, including PSTN
numbers for
example). In other words, forking and retargeting don't match that well
to 
"call forwarding indication".

When you send a REGISTER for example, the Registrar will tell you you
current
active AOR contact bindings. In a way, that tells you your current
"forwarding" 
settings to other devices that share your AOR. It does not tell you
however if you
are set-up for retargeting to other devices.

If this feature you are looking for is to be useful, I don't believe it
is
sufficient to be a PSTN "call forwarding" indication equivalent. It
would have
to be a way (probably through a subscription package) to query your
current retargeting
settings. So some document describing the routing policy applies to you
AOR.

I do think that it is a useful feature, but only if it is complete.

> Sent: Wednesday, August 22, 2007 07:42
> To: [email-masked]
> Cc: [email-masked]
> Subject: AW: AW: [BLISS] Use of Warning: header 
> I would be happy to discuss a proposal on how to make the 
> service better without making interworking impossible.
> 
> Greetings,
> Denis Alexeitsev
> 
> 
>

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 28 Aug 2007 03:50:44 -0500

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, August 27, 2007 11:08 PM
> To: [email-masked]
> Subject: Re: [BLISS] Use of Warning: header to transport 
> additional status indications
> 
> That's true, but that's also the point of it.  If the called 
> UA (or service provider) wants the calling UA to play 
> ringback, it sends 180.  If it wants to indicate that the 
> call is being forwarded but

So I call you, you're already on a call so my call is waiting, therefore
you send me a 182. My phone triggers local ringback when I get a 180
(which I have not) so as I'm waiting on you to switch calls, I hear
silence. People won't tolerate that and will hang up thinking the call
failed. That's why we have to provide comfort tones. Regardless of the
protocol used there's still a human being using the phone.

> This automatically introduces some complexities, however.  If 
> the SIP UA is a gateway, then how is the gateway going to set 
> up the call forwarding that we want to report back to the 
> user?  The special dial tone used to indicate to the caller 
> that call forwarding is in effect for this UA and the user of 
> special dial codes to set up call forwarding are two parallel 
> responses to the poverty of the POTS user interface.

I don't think this automatically introduces some complexities, I think
it *is* the complexity. I don't believe this thread was trying to
address how you setup call forwarding. It's talking about how you tell
the user that they have call forwarding is active when dealing with a
SIP UA that is not able to subscribe to configuration event packages. I
believe everyone can envision a rough method of subscribing to an event
package to be told when their call fowarding is active. 

I must admit that I thought that this POTS feature wasn't very useful,
but the more I think about it, being reminded when I make a call that
people may or may not be able to call me back at the number I'm using
(because the phone is forwarded) is pretty useful. 

Being alerted when you make a call has nothing to do with the poverty of
the POTS user interface because the phone itself could be reminding me
that it has forwarded activated: the phone could be configured locally
to generate a 302 response to forward my calls. Further, may people make
calls today without ever looking at any sort of UI on their phone: think
voice-activated dialing via a bluetooth headset.

The question here is, given that there is no resource in the network
that the phone can asynchronously determine that call forwarding is
active, how else can the user be told that their calls are being
forwarded? 

> mechanism to control call forwarding, and to indicate that 
> call forwarding is active.

We're only talking about indicating that it's active here, not
configuring it to be enabled or disabled. You're making the assumption
that the network element that is providing call forwarding is a SIP
device. It could simply be that call forwarding is being provided by a
non-SIP PSTN element in the network for the user who is connected in via
a SIP to ISUP gateway. In this case it'll be the SIP device that is at a
disadvantage. Devices connecting via ISUP will hear the tone, but unless
we can agree on a way to convey that tone to a SIP device (again,
there's no resource here to subscribe to) in this case, the SIP device
will not. So this isn't necessarily the best case.

> 
> In the next case, a gateway intercepts appropriate dial codes 
> from a black phone and provides a special dial tone.  The 
> gateway is translating from a more orthogonal SIP interface 
> to call forwarding to the more impoverished black phone interface.

Turn that model around such that the gateway is translating from a PSTN
network to a 'more orthogonal SIP interface'.

> forwarding.  In the outgoing direction, we can probably have 
> the proxy recognize and divert special dial codes for call 
> forwarding.  But the reverse channel is harder to manipulate.

I don't follow what you're trying to describe here.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Aug 2007 09:28:14 -0400

> protocol used there's still a human being using the phone.

I agree with Brian wrt the user experience.
I've proposed use of Alert-Info with a URN that identifies semantically 
the desired sort of alerting. IMO that is an appropriate solution.

The below is something entirely different. It is quite confusing to be 
discussing them in the same thread. Nevertheless...

>>    it at least be something that has the least amount of 

IMO it is in general a bad idea to introduce mechanisms that are 
specific to GW-GW calling. In general you can't know in advance that 
there is a GW-GW situation, and in general for whatever "feature" is 
enabled that way you will need to define some other mechanism when one 
or both of the parties aren't GWs.

GW-GW mechanisms are useful when SIP is only being used to tunnel some 
other protocol. While that is something people do with sip, I don't 
think that is something most of us are interested in spending our time on.

> (because the phone is forwarded) is pretty useful. 

It may indeed be useful to be informed about the status of some remote 
agent working on your behalf.

And I do believe this is about that aspect - things working on your 
behalf, and under your control (at least in some limited way).

> the POTS user interface

Its the poverty of the UI that leads to alerting when you pick up the phone.

Its the stupidity of the PSTN UA and the communication path between it 
and the other components acting on your behalf that prevent ongoing 
monitoring and display of the status and instead lead to checking it 
only when making a call.

> because the phone itself could be reminding me

Clearly there are a variety of UIs that might be involved. And they may 
limit how and when status may be conveyed to the user. But we should 
distinguish that from the signaling.

> active, how else can the user be told that their calls are being

There isn't? Or is there just no resource that is willing to hold a 
subscription? And why is that? This is between *my* phone and *my* call 
agent. There is some dedicated resource in there. To be a viable system 
the call agent must have knowledge of whether my phone is connected or 
not, so there is probably a sip registrar involved even if the primary 
call processing isn't done in sip. So I think there is something that 
could service a subscription. How it handles the other side of the 
signaling is its business. When a subscription is active it could poll 
from time to time by initiating fake calls to an address that won't 
answer. Or whatever works. But it can turn that into something 
appropriate for the sip side.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 28 Aug 2007 08:43:08 -0500

> From: Paul Kyzivat [mailto:[email-masked]] 

[snip]

> 
> IMO it is in general a bad idea to introduce mechanisms that 
> are specific to GW-GW calling. In general you can't know in 
> advance that there is a GW-GW situation, and in general for 
> whatever "feature" is enabled that way you will need to 
> define some other mechanism when one or both of the parties 
> aren't GWs.
> 
> GW-GW mechanisms are useful when SIP is only being used to 
> tunnel some other protocol. While that is something people do 
> with sip, I don't think that is something most of us are 
> interested in spending our time on.
> 

True enough, let's deprecate SIP-I immediately. I don't think anyone is
asking us to spend any time on tunneling protocols. If I recall
correctly, Denis was simply asking us what the best way was to convey a
service indication during an INVITE transaction to trigger a
notification of some sort at the phone.

Stick your head in the sand, and wait a few months for the eventual spec
to be written that will handle this from other SDOs and then deploy an
SBC to fix the issue when your products are asked to interwork with the
other solution and customers complain that you don't support their
feature set. It's a well-trodden path... So well trodden in fact, that
we are now corresponding on this email list as a result.

[SNIP]

> > Being alerted when you make a call has nothing to do with 
> the poverty 
> > of the POTS user interface
> 
> Its the stupidity of the PSTN UA and the communication path 
> between it and the other components acting on your behalf 
> that prevent ongoing monitoring and display of the status and 
> instead lead to checking it only when making a call.

Forget about the PSTN UA. Take the case where it's a SIP UA talking into
a PSTN network that is hosting your services. You can either use early
media to convey a tone to the SIP UA (the bad-old PSTN way) or, if the
SIP GW is aware enough to do so, it could give the SIP UA an explicit
note as to what it is being alerted to.

[SNIP]

> There isn't? Or is there just no resource that is willing to 
> hold a subscription? And why is that? This is between *my* 
> phone and *my* call agent. There is some dedicated resource 
> in there. To be a viable system the call agent must have 
> knowledge of whether my phone is connected or not, so there 
> is probably a sip registrar involved even if the primary call 
> processing isn't done in sip. So I think there is something 
> that could service a subscription. How it handles the other 
> side of the signaling is its business. When a subscription is 
> active it could poll from time to time by initiating fake 
> calls to an address that won't answer. Or whatever works. But 
> it can turn that into something appropriate for the sip side.

Huh? This is about getting service parity via a SIP UA connected to a
network where the service is not hosted by a SIP proxy . How do you get
a subscription to interwork with another protocol that does not support
the notion of subscriptions? What's the difference between sending a
subscribe and getting the notifications at a different time, and only
getting them when a call is made? And if that's true, why would you
require that the information be conveyed using a notify if there's
always an INVITE transaction open at that given moment?

Regards,
Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Aug 2007 09:28:17 -0400

Brian Stucker wrote:
> True enough, let's deprecate SIP-I immediately.

:-)

All I was saying is that such usage hasn't been a primary focus of 
effort for awhile. The work was done, and is in use, and I'm not 
suggesting it be deprecated.

> I don't think anyone is

I was getting the feeling the places where this would be useful are only 
tunneling. If thats not true, then the story is different.

> we are now corresponding on this email list as a result.

My point is to find a way to have a common mechanism for both sip-sip 
communication and sip-gw communication scenarios. Having different 
solutions for the sip parts of these two cases is at least undesirable.

I think most of us would agree that in a sip-sip scenario we would not 
want to restrict the solution to conveying this indication at the time 
of call initiation. If there is a more general solution, and a way can 
be found to make it work with GWs as well, that would be better than the 
proposed indication during call initiation.

> a PSTN network that is hosting your services.

Can you be more explicit about the topology you are talking about?

Are you assuming a GW with configured knowledge of particular sip phones 
that are mapped onto PSTN lines? Or are you talking about sip phones 
that register with a sip registrar, and the proxy/registrar delegates 
all calls through a GW? Or what?

> You can either use early

As long as there is either a registrar/proxy that has state for each 
phone, or a GW with configured knowledge of each, then that component 
could also terminate subscriptions to an event package. It could 
generate notifications based on occasionally polling the PSTN side by 
making a "fake" call, as well as observing the indications on the PSTN 
side for any actual calls that are originated. It could also monitor the 
dialtone on the PSTN side when that is used to convey the indication. 
None of the idiosyncrasies of the PSTN signaling need be carried over to 
the sip signaling.

> the notion of subscriptions?

See above?

> What's the difference between sending a
> getting them when a call is made?

When the services are provided in a network that only provides the 
indications at time of a call then that may be the only time that 
notifications are received. But at least that limitation is then 
governed by the poverty of the service provider - not the sip machinery. 
If you upgrade to a different service provider you can get better service.

And as I noted above, a GW implementing the event package can overcome 
some of these limitations by polling.

	Paul

> And if that's true, why would you

---

From: [email-masked]
Date: Wed, 29 Aug 2007 14:44:58 -0400

You're quite correct that the user receives a deficient experience.
But I think you're mis-identifying the *cause* of the deficient
experience.  From a SIP point of view, the called end is reporting
status quite correctly and usefully -- 182 means "you're being queued
and a user has not yet been notified".  The problem, IMHO, is that
when the calling UA receives a 182 that it does not relay that
information to the user in some manner.  It thus fails to transport
the status information that it has receives to the user.  What the UA
needs to do is to provide some sort of comfort tone or ringback when
it receives such status messages, not just for 180.  (IIRC some PSTN
systems will provide a tone when a call is forwarded; this would be a
natural report for receiving a 181.)

Dale

---

From: [email-masked]
Date: Wed, 29 Aug 2007 14:48:14 -0400

From: Paul Kyzivat <[email-masked]>

Why would we need a URN to carry the semantics when we have the
response code?

Dale

---

From: [email-masked]
Date: Wed, 29 Aug 2007 15:03:33 -0400

Why doesn't it subscribe to the resource that is handling and
implementing the call forwarding?

OK, I think I see what you're getting at -- You have a SIP phone going
through a SIP network to a gateway to the PSTN, which *PSTN* is doing
the call forwarding.  Ugh.

It would have helped if you'd stated that at the beginning of the
discussion.  Normally we talk about SIP networks here.

In this sort of situation, I would expect the SIP-to-PSTN gateway to
provide the resource to which the SIP UA subscribes in order to
discover the call forwarding status for the AOR.  The gateway is
already translating all other aspects of the attachment of the UA to
its real home switch down in the PSTN.

The next question is how does the gateway discover the call forwarding
status?  There are probably as many answers to that as there are
call-forwarding-indication systems.  I expect that ISDN or SS7
provides some direct way of obtaining call-forwarding status without
having to initiate a call.  But if we were truly stuck and the only
way the PSTN would report call-forwarding status was via the dial tone
when the line went off-hook, the gateway could monitor the dial tone
at the start of every call that it passed through, and by occasionally
taking the line off-hook when the line was otherwise idle.

I was talking about gateways for analog phones hanging off SIP
networks, which is what you seemed to be talking about.  Phones like
that have no other way to indicate call-forwarding status than dial
tones and similar status tones.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Aug 2007 16:22:42 -0400

> Why would we need a URN to carry the semantics when we have the

If there is a response code that conveys the proper semantics then I agree.

I believe the case we are discussing is call waiting. Maybe there are 
other cases, but AFAIK in the call waiting case the called user *is* 
alerted, and so 182 is probably the wrong response. I gather that in 
addition to informing the caller that the callee has been alerted, there 
is a desire to indicate that the callee is in some state where answering 
response may be delayed longer than "normal".

I am personally far from convinced that there is any information here 
that ought to be conveyed. But if I assume that there is reason to 
inform the caller of this, I have proposed the use of A-I to convey it. 
It is a reasonable mechanism for "alerting the caller" in a particular way.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 30 Aug 2007 01:35:46 -0500

> I believe the case we are discussing is call waiting. Maybe 
> there are other cases, but AFAIK in the call waiting case the 
> called user *is* alerted, and so 182 is probably the wrong 
> response. I gather that in addition to informing the caller 
> that the callee has been alerted, there is a desire to 
> indicate that the callee is in some state where answering 
> I am personally far from convinced that there is any 
> information here that ought to be conveyed. But if I assume 
> that there is reason to inform the caller of this, I have 
> proposed the use of A-I to convey it. 

I agree.

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 30 Aug 2007 01:57:48 -0500

> Sent: Wednesday, August 29, 2007 10:04 PM
> To: [email-masked]

Because the resource handling call forwarding may be a big brown box
that will never be upgraded to support SIP endpoints natively, but you'd
still like to use SIP endpoints.

> OK, I think I see what you're getting at -- You have a SIP 
> phone going through a SIP network to a gateway to the PSTN, 
> which *PSTN* is doing the call forwarding.  Ugh.

Yep. Nasty from a SIP point of view, but the alternative is no SIP
endpoint at all.

> 
> It would have helped if you'd stated that at the beginning of 
> the discussion.  Normally we talk about SIP networks here.

I didn't start the fire. This came from Denis (cc'ed). I'm just trying
to facilitate a solution that is palatable to myself and the community
to avoid hacks.

> 
> In this sort of situation, I would expect the SIP-to-PSTN 
> gateway to provide the resource to which the SIP UA 
> subscribes in order to discover the call forwarding status 
> for the AOR.  The gateway is already translating all other 
> aspects of the attachment of the UA to its real home switch 
> down in the PSTN.

I don't think this is a reliable solution because the status of the call
forwarding could change in the PSTN and the gateway would not know that
such had changed until a call is made. This doesn't mean that you can't
use subscribe/notify in any situation. I definitely think you can, but
just that it's likely not realistic in this case. I don't know, but I
have a strong suspicion that this is the case.

> 
> The next question is how does the gateway discover the call 
> forwarding status?  There are probably as many answers to 
> that as there are call-forwarding-indication systems.  I 
> expect that ISDN or SS7 provides some direct way of obtaining 
> call-forwarding status without having to initiate a call.  
> But if we were truly stuck and the only way the PSTN would 
> report call-forwarding status was via the dial tone when the 
> line went off-hook, the gateway could monitor the dial tone 
> at the start of every call that it passed through, and by 
> occasionally taking the line off-hook when the line was 
> otherwise idle.
> 
> I was talking about gateways for analog phones hanging off 
> SIP networks, which is what you seemed to be talking about.  
> Phones like that have no other way to indicate 
> call-forwarding status than dial tones and similar status tones.

Ok. Right. Both models should be covered by the same set of mechanisms.
The difference I was trying to point out here is that folks were
assuming that the thing doing call forwarding was SIP. It could be, but
there are several cases:

1. SIP core doing the call forwarding, SIP endpoints: use
subscribe/notify please.
2. SIP core doing the call forwarding, non-SIP endpoints: use alert-info
and/or subscribe/notify? Unclear. Gateway would have to act as a
persistient SIP UA for the non-SIP endpoint instead of a shared,
on-demand, resource. 
3. Non-SIP core doing the call forwarding, SIP endpoints: use alert-info
and/or subscribe/notify? Unclear. Probably can't expect subscribe/notify
to work because you'd have to upgrade too of the existing equipment out
there.
4. Non-SIP core, non-SIP endpoints: Use SIP-I or something else if you
have SIP in the middle in there somewhere.

Regards,
Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 30 Aug 2007 02:02:37 -0500

> Sent: Wednesday, August 29, 2007 9:45 PM
> To: [email-masked]
> But I think you're mis-identifying the *cause* of the 
> deficient experience.  From a SIP point of view, the called 
> end is reporting status quite correctly and usefully -- 182 
> means "you're being queued and a user has not yet been 
> notified".  The problem, IMHO, is that when the calling UA 
> receives a 182 that it does not relay that information to the 
> user in some manner.  It thus fails to transport the status 
> information that it has receives to the user.  What the UA 
> needs to do is to provide some sort of comfort tone or 
> ringback when it receives such status messages, not just for 
> 180.  (IIRC some PSTN systems will provide a tone when a call 
> is forwarded; this would be a natural report for receiving a 181.)

If we were having this discussion 7 years ago, I'd agree with you, and
to a certain extent I agree with you now. However, this is pretty much
the way UAs are told to work and are built to work (don't start ringback
until 180) to avoid ghost-ringback problems which are equally confusing
to people. There's too many SIP UAs out there that would need to be
changed, and it's unclear that the change is safe.

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 30 Aug 2007 15:28:10 +0200

Hi all,

the notifications we are talking here about are more or less 'nice to have' notifications. Probably not many people would subscribe to this kind of information, to avoid signalling overload or processing power, especially at their mobile devices. But if they receive these notifications within messages they will receive anyway during the basic call, they won't be angry but probably be contented about this additional information. 

Therefore I would also prefer a solution that avoids SUB/NOT.

Regards, Martin

> Von: Brian Stucker [mailto:[email-masked]] 
> Gesendet: Donnerstag, 30. August 2007 08:36
> An: Paul Kyzivat; [email-masked]
> Cc: [email-masked]
> Betreff: RE: [BLISS] Use of Warning: header to transport 
> additional statusindications
> 
> 
>  
>

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Thu, 30 Aug 2007 15:28:44 +0200

As the basic information is, that the call is presented to the callee, I would also prefer the 180, with additional information in a regarding Alert-Info header.

182 says you are queued, for me that means that your call isn't really presented to the callee yet.

Regards, Martin

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 30 Aug 2007 08:46:45 -0500

> Sent: Thursday, August 30, 2007 4:28 PM
> To: Stucker, Brian (RICH1:AR00); [email-masked]; 
> [email-masked]
> the notifications we are talking here about are more or less 
> 'nice to have' notifications. Probably not many people would 
> subscribe to this kind of information, to avoid signalling 
> overload or processing power, especially at their mobile 
> devices. But if they receive these notifications within 
> messages they will receive anyway during the basic call, they 
> won't be angry but probably be contented about this 
> additional information. 
> 

Just so there's no confusion (since this was in reply to an email I posted), I do not support a solution that *avoids* SUB/NOT, but am not against solutions that include a way of conveying the information that does not rely exclusively on SUB/NOT. I think the case is fairly clear that SUB/NOT is the preferred way of conveying configuration information from a SIP network to a SIP UA.

Regards,
Brian

> > Betreff: RE: [BLISS] Use of Warning: header to transport additional 
> > statusindications
> > 
> > 
> >  
> > 
> > > If there is a response code that conveys the proper 
> semantics then I 
> > > agree.
> > > 
> > > I believe the case we are discussing is call waiting. Maybe there 
> > > are other cases, but AFAIK in the call waiting case the 
> called user 
> > > *is* alerted, and so 182 is probably the wrong response. I gather 
> > > that in addition to informing the caller that the callee has been 
> > > alerted, there is a desire to indicate that the callee is in some 
> > > state where answering response may be delayed longer than 
> "normal".
> > > 
> > > I am personally far from convinced that there is any information 
> > > here that ought to be conveyed. But if I assume that 
> there is reason 
> > > to inform the caller of this, I have proposed the use of A-I to 
> > > convey it.

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 30 Aug 2007 09:14:59 -0500

> From: Stucker, Brian (RICH1:AR00) 
> Sent: Thursday, August 30, 2007 4:47 PM
> To: Huelsemann, Martin; [email-masked]; [email-masked]
> Subject: RE: [BLISS] Use of Warning: header to transport 
> > Subject: AW: [BLISS] Use of Warning: header to transport additional 
> > statusindications
> > 
> > Hi all,
> > 
> > the notifications we are talking here about are more or 
> less 'nice to 
> > have' notifications. Probably not many people would 
> subscribe to this 
> > kind of information, to avoid signalling overload or 
> processing power, 
> > especially at their mobile devices. But if they receive these 
> > notifications within messages they will receive anyway during the 
> > basic call, they won't be angry but probably be contented 
> about this 
> > additional information.
> > 
> Just so there's no confusion (since this was in reply to an 
> email I posted), I do not support a solution that *avoids* 
> SUB/NOT, but am not against solutions that include a way of 
> conveying the information that does not rely exclusively on 
> SUB/NOT. I think the case is fairly clear that SUB/NOT is the 
> preferred way of conveying configuration information from a 
> SIP network to a SIP UA.

Correction/clarification... SUB/NOT is the preferred way to convey a
change has occurred in configuration information.

---

From: [email-masked]
Date: Thu, 30 Aug 2007 17:32:44 -0400

Well, yes, you wouldn't want to give the user ringback unless a 180
was received, because ringback *means* the same thing as a 180.

But if the phone receives other call-progress messages, it should
provide corresponding other indicators to the caller.

As for "too many SIP UAs out there that would need to be changed",
every SIP UA I've ever seen gets its software updated multiple times
per year...

In regard to the sub-problem of "ringing for call waiting", I think
Paul has described it well, because no existing 18x message has the
right semantics -- the user is being notified, but we have reason to
expect the user to answer more slowly than normal.  Though I suppose
we should check whether the users really do answer more slowly -- the
user is occupied, yes, but he's also right there at the phone.  A good
test would be "Do networks give the call more time to ring during call
waiting before forwarding to voicemail?"  If the telcos have never
found need to allow more time, then they've probably determined that
people answer call waiting calls as fast as ordinary calls.

Dale

---

From: [email-masked]
Date: Thu, 30 Aug 2007 17:37:48 -0400

There's something here that I am overlooking...  Let me propose that
the gateway provide an event package that reports the call-forwarding
status that it obtains by some undefined means, and that we understand
that the event package status may lag behind the real call-forwarding
status by some period of time.  In that case, the data is reliable,
but it may be slow.  Indeed, it's no slower than reporting the status
using a special dial tone or ring tone, which is the PSTN technique
we're comparing with.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Aug 2007 20:36:04 -0400

This is what I had in mind as well. I know there is resistance to having 
event packages for every little thing like this. A solution that has 
been discussed elsewhere is to couple this with the config event 
package. There is already the notion of per-aor config obtained that 
way. IMO the forwarding status is a pretty plausible piece of config 
information about the AOR, so this fits pretty well.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 31 Aug 2007 09:13:42 +0100

Martin,

I am fine with this distinction. However, going back to much earlier in this thread, I seem to recall some mention of call waiting being implemented at a proxy and not at the UAS, and in this case the user would not be aware of the waiting call. Or have I misunderstood something? I am not advocating proxy involvement - but I do seem to recall something.

John 

> Sent: 30 August 2007 14:29
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [BLISS] Call Waiting: Response code vs. Alert-Info
> 
> As the basic information is, that the call is presented to 
> the callee, I would also prefer the 180, with additional 
> information in a regarding Alert-Info header.
> 
> 182 says you are queued, for me that means that your call 
> isn't really presented to the callee yet.
> 
> 
> Regards, Martin
> 
> 
>

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 31 Aug 2007 11:18:19 +0200

Yes of course, if there are state changes you have to use SUB/NOT to receive notifications about this, no doubt about that. 
But in our use-case there has been no change in the state of your call-diversion activation, it's just a reminder (or warning?) that the diversion is still active, and it will be active until you deactivate it again.

BR, Martin

> Gesendet: Donnerstag, 30. August 2007 16:15
> An: Brian Stucker; Hülsemann, Martin; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; Alexeitsev, Denis

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Fri, 31 Aug 2007 11:55:20 +0200

Hi John,

there are different scenarios for CW, implemented at a UAS or a proxy. In both cases the call will be presenred to the callee and a CW notification to the caller is needed.

In the proxy case, also a CW indication to the callee is needed, informing the callee about the fact that there are currently no resources for this call. So the user can actively decide if he puts another call on hold and accepts the new call, or if he doesn't accept the new call. But that is another issue, I will start a thread to this, too, but first I have to check what can be done with RFC 3312 preconditions.

Regards, Martin

> Gesendet: Freitag, 31. August 2007 10:14
> An: Hülsemann, Martin; [email-masked]; 
> [email-masked]; [email-masked]
> Betreff: RE: [BLISS] Call Waiting: Response code vs. Alert-Info
> 
> 
> Martin,
> 
> I am fine with this distinction. However, going back to much 
> earlier in this thread, I seem to recall some mention of call 
> waiting being implemented at a proxy and not at the UAS, and 
> in this case the user would not be aware of the waiting call. 
> Or have I misunderstood something? I am not advocating proxy 
> involvement - but I do seem to recall something.
> 
> John 
>

---

From: [email-masked]
Date: Fri, 31 Aug 2007 16:46:33 -0400

Interesting way of putting it, but you've missed one thing: the
   indication is always present and in-sync with the status of the feature
   in the existing PSTN technique.

Is that really so, though?  My PSTN-provided voicemail uses a modified
dial tone to indicate that I have new voicemail present.  But there is
a delay in reporting -- I can call the voicemail retrieval number,
play and delete a new message, but if I hang up and immediately go
off-hook again, the modified dial tone will remain.

Is PSTN call-forwarding reporting actually always in-sync?  Or is it
just good enough that people are satisfied?

   It may not be in your case. Otherwise, I agree, yes, this would be
   equivalent. However, if people KNOW that they have call forwarding
   setup and don't get the indication as they expect, due to lag, that
   can be confusing to them and interpreted as unreliable.

We can also use some tricks to improve the reporting time lag -- e.g.,
the gateway can be programmed to know the dial codes for activating
and deactivating call forwarding, and can be careful to quickly get a
refresh of the call-forwarding state after the end of a call that was
dialed using one of those dial codes.

I don't think that these problems are really that difficult that we
must meticulously replicate what the PSTN already does.  And we really
should avoid architectural contortions of SIP; it's messy enough
already.

Dale