Subject: [Sip] RE: [Sip-implementors] another problem related to multiple call l egs at UAC

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jun 2001 16:04:32 -0400

Moving from sip-implementors to sip since there are some open issues and
changes to bis in here.

> -----Original Message-----
> From: Barry Desborough [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 6:34 AM
> To: 'Paul Kyzivat'; Bob Penfield
> Cc: [email-masked]
> Subject: RE: [Sip-implementors] another problem related to 
> multiple call
> l egs at UAC
> 
> 
> I like the NAK idea. Consider a prong of a fork which gets 
> routed to a PSDN
> gateway. When the PSDN called party picks up, a connection 
> charge may be
> incurred if the gateway gets ACK-followed-by-BYE

Don't confuse billing and SIP messaging. You can just as easily not charge
users if a BYE follows the ACK by some small time lag.

> 
> I also agree that encoded reasons should be added to BYEs and 
> CANCELs such
> that a PSDN gateway can map them to and from Q.931 cause codes.

I also like these BYE reasons. This has come up countless times. Its also
helpful in CANCEL, to know whether a call was cancelled because the caller
aborted, or because some other branch picked up (the former would generate a
missed call entry in a call log, whilst the other won't). I don't think
Warning is right, but some kind of header that conveys both a
machine-interpretable and human-interpretable value would be good.

Paul writes:
 > Bob Penfield wrote:
> > [snip]
> > > If the UAC only wants the first 200-OK, it can accept it. If it
> > > sees another 200-OK, it can just ACK it and send a BYE.
> >
> > I have seen this answer many times.
> > But I have never seen any discussion of the kind of user
> > experience this provides.
> 
> More often than not, the callee will just get dead air.

Lets be clear that this will happen only under race conditions. Generally,
when a 200 OK arrives, this generates a CANCEL that stops the other lines
from ringing. This is therefore like the home phone experience (the behavior
is different if you pick up after the call is answered - this is the Single
Line Extension work that was going to define how to emulate that model where
if you pick up, you get to join a conference call).

That said, I agree that having a reason in BYE/CANCEL would help the
experience under the race condition, should it happen. 

Harpreet writes:
> Another thing  Section 5.2 of bis 03.txt also says that
> "A proxy client generates a CANCEL request for branches without
>    a final response after it has forked a request and 
> receives a 2xx or
>    6xx response from one of the branches. "
> Whereas section 17.4, pg. 122 says that
> "After receiving a 2xx, the server MAY terminate all other
>              pending requests by sending a CANCEL request"
> 
> Note that there is no "MAY" in section 5.2.

These need to be consistent. Honestly, it should probably be a SHOULD as
opposed to a MAY in both places. Anyone object to me changing that?

Harpreet writes:
> I have a basic question here. The intent of the UAC by sending the
> INVITE to the proxy was to open just one call leg, but the proxy's
> forking resulted in formation of multiple call legs. Now why isn't it
> made mandatory in SIP for the proxy to handle all these extra multiple
> call legs & present the UAC with just one 2xx for one call 
> leg only. Why

No, the intent of the IVNITE is not to open one call leg, its to contact the
user at the multiple places they may reside.

If a SIP proxy handles the multiple call legs, then forking proxies must
become B2BUAs. We want to avoid keeping stateful devices in the network like
this in order to support what is, IMHO, a key component for any user
discovery system. Ultimately, the end-to-end principle will argue that
treatment of the multiple-200 case is best left to the client, since it
needs to handle it no matter what (serverless operation), and it is best
positioned to determine what the right treatment is. 

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

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

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 25 Jun 2001 16:44:35 -0400

Jonathan Rosenberg writes:
<snip>
> opposed to a MAY in both places. Anyone object to me changing that?

Wouldn't that break the cancel-feature of the Request-Disposition header in
the caller preferences draft? If the proxies always cancel the other legs,
then clients that do fancy things with multiple answers could never work.

For example, I use a one-number service (unfortunately PSTN based) with a
call screening feature that tells the callee who the call is for and who is
holding and asks the callee to press 1 to accept the call. The service
simultaneouly rings my office, home, and cell phone. If this were
implemented in SIP with a forking proxy to get to all the devices I
registered, and the proxy canceled the unanswered call legs as soon as one
answered, I could not receive the call if my wife picked up the home phone
before I answered my office or cell phone.

I think it should be a MAY.

(-:bob

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 25 Jun 2001 17:03:47 -0400

<snip>
> Barry Desborough wrote:
How about a "Reason" request header (or is that already defined elswhere)
that uses the same format as the Warning header?

        Reason        =  "Reason" ":" 1#reason-value
        reason-value  =  reason-code SP reason-agent SP reason-text
        reason-code   =  3DIGIT
        reason-agent  =  host [ ":" port ]
                          ;  the name of the server adding
                          ;  the Reason header, for use in tracing/debugging
        reason-text   =  quoted-string

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jun 2001 17:47:58 -0400

> users if a BYE follows the ACK by some small time lag.

[Beware - I freely admit I don't know squat about phone systems billing,
so take this with a grain of salt...]

The way I understood this conversation, the concern was that the gateway
would incur a charge from the PSTN. While it may be possible to detect
the ACK-quickly-followed-by-BYE and prevent the generation of a bill to
the SIP user by the gateway, the PSTN charge may still be present. If
the gateway is owned by the PSTN provider then this may not be an issue,
but if the gateway is owned by a separate enterprise or provider then it
could be a problem.

Of course, if the race condition that leads to this situation happens
infrequently enough then maybe nobody will care.

	Paul