Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service

From: [email-masked]
Date: Wed, 17 Jan 2001 16:53:50 +0530

If you want such services, your SIP entity might serve as a B2BUA for this
interaction.
Note that Stateless/full Proxy, Redirect, modes are logic roles - your SIP
entity can change its
behaviour depending on their needs.
In this case, if you want your server to send a BYE to both parties, it
will be taking the role of a B2BUA
 and not that of a regular SIP Proxy functionality. See the 3pcc drafts for
examples of B2BUAs.

The important point to realise is that when you a deploying services such
as above, you will often use a combination
of these logical roles - that of a Proxy, Redirect, B2BUA etc. The
"physical" entity that you install, will change its "logical"
role depending on what it needs to do to provide a service.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

james jack <[email-masked]> on 01/17/2001 04:39:26 PM

To:   [email-masked]
cc:

Subject:  [SIP] Some idea on Stateful SIP Proxy for Card Service

Dear All:
   My question is on card serice, how to realize
 the traditional card service with SIP. one difficulty
 is that if the money in the card is over, how to
 control the terminal to break the connection.
   For example, User B use the Terminal to dial
 terminal C through Proxy P, the charging is
controlled by the application layer in proxy P--which
can contact the database, then if the money in the
card is over, how to control to break the connection?
   In my opinion, the application layer of Proxy P
 can send a instruction, then the proxy send BYE to
both sides (B and C), then the connection can be
broken.
  But the proxy will never generate BYE request
according to RFC2543?  then how to solve such problem?
  Any suggestions and ideas are welcome!
  I am looking forwards to getting your reply as
 soon as possible!
     Best Regards!
                           Yours: james

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: <[email-masked]>
Date: Wed, 17 Jan 2001 12:31:49 +0100

You can check Third Party Call Control in SIP
(draft-rosenberg-sip-3pcc-01.txt) and, since it seems that you want to base
the charging on SIP message flows,  SIP session timer
(draft-ietf-sip-session-timer-04.txt)) in order to avoid neverending
charging when there is any problem when delivering BYE message.

Javier

---

From: William Marshall <[email-masked]>
Date: Wed, 17 Jan 2001 07:46:31 -0500 (EST)

P is clearly a back-to-back-UA, since it speaks SIP to
both user B and terminal C.  However, its need to initiate
a BYE doesn't fit the profile of a proxy.  Just a B2BUA.

In looking at various enhanced services, it is not clear
to me that a "stateful proxy" will ever exist.  They will
all be B2BUAs for some case or another.

Bill Marshall
[email-masked]