Subject: AW: [Sipping] 3G entities: Proxy or B2BUA?

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Wed, 24 Oct 2001 18:23:01 +0200

Hello Rohan, Miguel et al,

now it is getting really interesting ...
<s(n)ip>

>> 2) It is not written anywhere that the P-CSCF has to 
>> release a session by sending a BYE. I agree with you that 
>> such a thing will make the P-CSCF automatically a B2BUA. 
>> There are other methods to force the session release, and no 
>> one has been agreed in 3GPP at the moment.
>
>
> If it looks like a BYE, and feels like a BYE, and smells 
> like a BYE.....   ;-)
> 
> Since BYE would do exactly what 3G intends, I would like to 
> pursue this option first.

Yes, BYE is the right solution. Maybe you want to follow me inside an
example scenario.

UA-A is attached to P-CSCF1. UA-A is calling UA-B and now UA-A loses raido
coverage. P-CSCF1 gets aware of that. The situation that we now have is:
There is no user anymore. 

Why should P-CSCF1 in this specific case not be allowed to act as a Proxy /
Replacement for UA-A and provide the BYE message for that user? It would
just turn form call-stateful proxy mode to UA mode and generate the BYE. It
is definitly the endpoint of the session. I see now real problem in sending
a BYE message (as it is the last request in the call) from the physical
endpoint of the call.

Well, I know this only solves one problem - but at least it solves
something. It leaves open the case when S-CSCF needs to release the call. 

> 
> >The main problem with B2BUA, as it is defined by the bis 
> draft, it that it acts as a UA on both sides. Therefore, it 
> needs to understand every method, header, codec, etc that 
> the UA sends. If it does not understand anything, it has to 
> reject it.
> 
> This assumption is fortunately not correct.  It is possible, 
> reasonable, and legal to implement a B2BUA that 
> transparently passes headers, method, and bodies that it 
> does not directly understand.  An anonymizer is a perfect 
> example of such a B2BUA--it only needs to understand a few 
> headers, plus the SDP, and pass the rest transparently.
> 
>
Well, I would regard such an entity as something that is not in line with
the definition in 2543bis-04. I also think that the B2BUA definitoin becomes
very interesting when you look at methods such as COMET or PRACK, even if
you look at responses to requests. For example when is the first response
for an incoming INVITE message sent back? (a) When the request came into the
B2BUA? (b) Or when the B2BUA receives the response from UE-B?

From the defintion in 2543bis-04 I would assume that (a) is the case. If
that is the case, then the B2BUA is not well-suited for 3GPP.

If (b) is the case then I would like to know where that has been defined. Or
re-phrased: How can I be sure that there is nobody out there who implemented
(a) instead of (b). In the IMS we want to interconnect with a wide range of
SIP Application Servers - we need to get some more clarification on the
behavior of the B2BUA therefore, as some of these AS might want to act as
such an entity. 

You see - I am not in favour of them. I also think they will delay the call
unnecesarily. And we need that much effort just in order to get a network
initiated BYE (I attentionally do not say network initiated release -
because I think that BYE is the right thing to do). 

So why we do not allow that a call-stateful proxy in general is allowed to
change *only for the generation of a BYE request* its mode of operation to
two UAs? We saw some arguments against other proposals - maybe we can have
some discussion here why such an approach would not work.

>
> 
> Please let me know if you still object to the type of B2BUA 
> I have described.  I would like to discuss how you could use 
> this architecture to implement more of the 3G requirements.

I would love to have a very clear description of the behavior of a B2BUA -
if we want it to be different from two real UAs (which I think is the
current definition - which seems to be open for interpretation, as we have
different readings of it). 

Thanks and keep on signaling!
Georg

_______________________________________________________
Georg Mayer - Siemens AG

> -----Ursprüngliche Nachricht-----
> Von: Rohan Mahy [mailto:[email-masked]]
> Gesendet: Mittwoch, 24. Oktober 2001 17:47
> An: Miguel A. Garcia
> Cc: Rohan Mahy; [email-masked]
> Betreff: Re: [Sipping] 3G entities: Proxy or B2BUA?
> 
> 
> Hi,
> 
> Comments inline...
> 
> ---- Original message ----
> >Date: Wed, 24 Oct 2001 17:48:58 +0300
> >From: "Miguel A. Garcia" <[email-masked]>
> >Subject: Re: [Sipping] 3G entities:  Proxy or B2BUA?
> >To: Rohan Mahy <[email-masked]>
> >Cc: [email-masked]
> >
> >Rohan:
> >
> >1) It is certain that the P-CSCF removes the Via and Record-
> Route headers and inserts them back in responses. The main 
> reason for that is to reduce the size of the messages when 
> transmitted over the air interface and some sort of 
> security. However, I don't think that doing such a thing 
> moves the P-CSCF to the B2BUA category. The From, To, Call-
> ID and the rest of the headers are not modified. There is 
> not other "hacking" than removing those (unneeded at the 
> mobile UA) headers.
> 
> I believe we agree to disagree here.  As the spec is 
> ambiguous on this point we can leave it at that or ask for 
> some consensus from the SIP WG.
> 
> >2) It is not written anywhere that the P-CSCF has to 
> release a session by sending a BYE. I agree with you that 
> such a thing will make the P-CSCF automatically a B2BUA. 
> There are other methods to force the session release, and no 
> one has been agreed in 3GPP at the moment.
> 
> If it looks like a BYE, and feels like a BYE, and smells 
> like a BYE.....   ;-)
> 
> Since BYE would do exactly what 3G intends, I would like to 
> pursue this option first.
> 
> >The main problem with B2BUA, as it is defined by the bis 
> draft, it that it acts as a UA on both sides. Therefore, it 
> needs to understand every method, header, codec, etc that 
> the UA sends. If it does not understand anything, it has to 
> reject it.
> 
> This assumption is fortunately not correct.  It is possible, 
> reasonable, and legal to implement a B2BUA that 
> transparently passes headers, method, and bodies that it 
> does not directly understand.  An anonymizer is a perfect 
> example of such a B2BUA--it only needs to understand a few 
> headers, plus the SDP, and pass the rest transparently.
> 
> The main advantage of a B2BUA in this environment is that it 
> can keep per-call-leg state and can be involved in mid-call 
> signaling.  As a proxy is only involved in transactions, it 
> can only handle pre-call features.  A B2BUA can insert SIP 
> messages (for example BYE messages), run timers, and may 
> change the required headers: (To, From, Call-ID, CSeq, 
> Via).  
> 
> Also, there may be resistance to keeping lots of state on 
> the B2BUA.  It is possible (though a bit complicated) to 
> implement a B2BUA that is completely call stateless, by 
> pushing encrpyted call-state to the edges.
> 
> >Such a behaviour is not acceptable if we want to progress 
> the development of UAs, create innovative services, etc.
> 
> I agree that an *implementation* of a B2BUA with this 
> property would be unacceptable.
> 
> >I am not stopping you to write a proposal, I am open to 
> hear proposals. But personally, I don't like B2BUA, and I 
> will try to avoid them unless there is no other chance at 
> all.
> 
> Please let me know if you still object to the type of B2BUA 
> I have described.  I would like to discuss how you could use 
> this architecture to implement more of the 3G requirements.
> 
> thanks,
> -rohan
> 
> >/Miguel
> >
> >
> >Rohan Mahy wrote:
> >> 
> >> Hi Folks,
> >> 
> >> I've seen a lot of email flying by about various 
> functions needed by 3G on
> >> their SIP "Proxies".  SIP defines a number of logical 
> *roles*, among them
> >> Proxy, Registrar, B2BUA, etc.  (If you do such and such, 
> then you are
> >> acting in such and such role.)
> >> 
> >> I've listed a couple of the functions that are required 
> by one of the 3G
> >> SIP servers (the P-CSCF or SIP outgoing "proxy") that 
> automatically put it
> >> in the B2BUA category.  Note that this is not a *bad* 
> thing, it just helps
> >> us talk about entities in a consistent way.  You can 
> build a B2BUA that is
> >> less complex than many true proxies.
> >> 
> >> - Removal of Via, Route, Record-Route headers: the 
> language about what you
> >> can do with these headers is a little vague, but one 
> valid interpretation
> >> is that proxies CANNOT do this.
> >> 
> >> - Automatic release of sessions: [when a mobile 
> disappears from the radio
> >> network, the P-CSCF wants to send a BYE.  This is a 
> completely reasonable
> >> thing to do, but a SIP server that initiates a BYE is 
> *definitely NOT* a
> >> proxy.]
> >> 
> >> Why does this matter?  For one, it makes discussions more 
> precise and less
> >> confusing. For another, it makes opens up some new 
> options architectually
> >> for implementing the rest of the 3G requirements.  For 
> example, instead of
> >> the proposed Path header that adds a "vector" or pre-
> loaded route, the
> >> P-CSCF could REGISTER on behalf of the UE and expect a 
> body that contains
> >> this vector in the 200 OK to the REGISTER.  Also, instead 
> of redefining
> >> registrations and adding special rules for de-
> registrations, the P-CSCF
> >> could potentially SUBSCRIBE to the status of the 
> subscriber, and use that
> >> state information to authorize initial usage and 
> terminate calls when money
> >> runs out, service is disconnected, or a mobile is stolen.
> >> 
> >> I can write out a proposal based on this assumption that 
> should meet the 3G
> >> requriements (from
> >> http://standards.ericsson.net/sip/drafts/draft-garcia-
> sipping-3gpp-reqs-00.txt
> >> ).  I'm happy to do this if folks think this is useful, 
> but I would like
> >> some feedback first.
> >> 
> >> thanks,
> >> -rohan
> >> 
> >> _______________________________________________
> >> Sipping mailing list  
> http://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP
> >> Use [email-masked] for questions on 
> current sip
> >> Use [email-masked] for new developments of core SIP
> >
> >-- 
> >Miguel-Angel Garcia                     Oy LM Ericsson AB
> >                                        Jorvas, Finland
> >mailto:[email-masked]     Phone:  +358 9 299 
> 3553
> >mailto:[email-masked]        Mobile: +358 40 
> 5140002
> 
> _______________________________________________
> Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

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

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 24 Oct 2001 11:31:04 -0500

>headers, plus the SDP, and pass the rest transparently.

This would be ideal. Unfortunately I do not believe it is correct.

>change the required headers: (To, From, Call-ID, CSeq, 

A B2BUA has the advantage and the burden of keeping per-call-leg
state. SIP proxies benefit from not having the complexity or
the overhead of maintaining this call-leg state. It is precisely
because a B2BUA maintains call state that it cannot be transparent
as you mention.  For example, if a B2BUA is deployed that does 
not understand the REFER extension, what happens? It could
reject the REFER request, breaking transparency. Or it could 
"proxy" the request along not understanding that call leg 
state may be modified as a result. A true UserAgent does not
have this problem, nor does a proxy. What about future extensions
that create "call legs" that the B2BUA does not know about? For 
example, SUBSCRIBE for RFC2543 based B2BUAs. What about the Replaces:
or Joins: headers? What about In-Reply-To: and To-Join:? What about
INVITE requests that use SMIL or the next generation of SDP? Does
the B2BUA have to be updated for this? 
 
BR,
Sean Olson
Ericsson Inc.

---

From: [email-masked]
Date: Thu, 25 Oct 2001 10:40:22 +0300

> There is no user anymore. 

How is this different from someone tripping over my LAN connection at the
office?

Why does my local proxy need to send a BYE when the media is already cut? I
would imagine the other end will notice that.

Cheers,
Aki

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Thu, 25 Oct 2001 10:41:53 -0400

Comments inline [RRR].

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, October 25, 2001 10:11 AM
To: Mayer Georg ICM N MC MI E71
Cc: 'Sean Olson (EUS)'; 'Rohan Mahy'; Miguel A. Garcia; [email-masked]
Subject: Re: AW: [Sipping] 3G entities: Proxy or B2BUA?

All,

Another thought from left field.  In some protocols, there is the concept 
of a lower layer initiated abort.  

[RRR] Yes, the lower layer is supposed to do many things: 1. Changes of
locations/addresses and 2. Changes in media (e.g., radio coverage, etc.).
This communication may be a part of UE <-> GGSN and/or GGSN <-> P-CSCF1.
(Item 2 as discussed before.)

While here, we are talking about 
signaling within the layer, not between layers, this is still the case of 
one entity using another entity to gain service.  

[RRR] This is the communication scenarios for UE A <-> P-CSCF1 <-> S-CSCF1
<-> UE B. (Item 1 as discussed before.)

Should we also be 
considering the possibility of using other messages?  

[RRR] Why not, if we think that it serves the purpose?

If we assume the 
Invite/Bye messages are the domain of the end system.  Could there also be 
a Notify type message rather than a Bye that indicates, to the controlling 
UA "You are about to lose your bearer (because I control that flow to the 
public Internet/other carrier, etc.), add more credit, or terminate and 
clean up your call state."

[RRR]  I would even extend the list to examine whether REFER, NOTIFY,
SUBSCRIBE, and/or other messages can serve the purpose.

Bye would seem more appropriate, but goes against the grain of end-user 
control.  Thought it might be useful to briefly consider if other SIP 
methods would work.

[RRR] BYE is more appropriate for UAs <-> UAs in SIP terminology. However, I
do not see any problems if we can convey the same meaning using REFER,
NOTIFY, SUBSCRIBE, and/or other messages in communications scenarios of UE A
<-> P-CSCF1 <-> S-CSCF1 <-> UE B.

Mike

At 07:26 PM 10/24/2001 +0200, Mayer Georg  ICM N MC MI E71 wrote:

>Hello again!
>
>In general I think we have an interpretation problem here.
>
>Reading the RFC 2543bis-04 defintion of a B2BUA it clearly states that 
>there are two UAs. It seems to be a valid interpretation that this means 
>the B2BUA should act as a UA-S on the incoming and a UA-C on the outgoing 
>side (of a Request). Reading then the procedures of a UA (also in the 
>other SIP related IETF drafts) brings up all the implications that Sean 
>and I listed.
>
>Ok, one could say there is a "transparent" B2BUA - but what is this? Where 
>is it defined? It is currently not defined and if one tries to define it, 
>she/he in the end needs to add the "transparent" B2BUA specific behaviour 
>under every line in the SIP Draft (and the supporting Drafts) which 
>mention UA behavior. Else the definition is either as restrictive as 
>stated above or it is open for interpretation - and I do not know which of 
>these two alternatives is really the "better" one.
>
>Well, I agree, we can do that - but this introduces a complete new entity 
>- one that I would not like to name B2BUA, because it is something like a 
>"call manipulating proxy".
>
>The problem is that if you follow the definition of UA and B2BUA, a B2BUA 
>does a lot of things and if you look at the 3G requirements you need to 
>introduce it mainly because of the case of network initiated session 
>release. This - furhter more - would cause that both S- and both P-CSCF 
>need to act as B2BUAs for every call. So each end-to-end call would be 
>splitted up in five (!!) call-pieces which all would have their unique 
>call-id, etc. etc. .
>
>I know, 3GPP has sent out a long wish-list for christmas (don't ask for 
>the year) and this specific item on the list is very ... interesting.
>
>Keep on signaling!
>
>Georg
>
>Information and Communication Mobile
>ICM N MC MI E71
>Hofmannstr. 51, 81359 Munich, Germany
>Fon: +49-89-722-33114
>Fax: +49-89-722-62250
>Mobile: +49-172-5371233
>Email: [email-masked]
>
>>Von: Sean Olson (EUS) [mailto:[email-masked]]
>>Gesendet: Mittwoch, 24. Oktober 2001 18:31
>>An: 'Rohan Mahy'; Miguel A. Garcia
>>Cc: [email-masked]
>>Betreff: RE: [Sipping] 3G entities: Proxy or B2BUA?
>>

---

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Thu, 25 Oct 2001 18:27:09 +0200

Hello Aki,

thank you very much for your comment. 

> would imagine the other end will notice that.

That is right, but the user walking out of radio coverage will be charged
for the call by an entity in her/his home network and this home network is
not involved in the transport of the media - i.e. just the SIP flows go
through the home network. 

In other words: The home network is completely dependent on the SIP
signaling. When the connection cuts, the home network needs a SIP indication
in order to get aware that the connection is no longer provided, i.e. that
charging shall stop.

Furthermore my personal view is that a signaling protocol should reflect the
actions taken at the bearer if something is happening. But this might be
seen different by other people and I do not want to start a discussion on
that. 

Keep on signaling!
Georg

> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Donnerstag, 25. Oktober 2001 09:40
> An: Mayer Georg ICM N MC MI E71; [email-masked];
> [email-masked]
> Cc: [email-masked]

---

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Thu, 25 Oct 2001 18:44:45 +0200

Hello Michael,

thanks for your message - I have some comments to it..

> clean up your call state."

I think that Subscribe/Notify might open a door to another possible
solution. But we have to be careful that we do not run into the same problem
as with the REFER method. 3G operators will provide and control the network
to the user, whereby the user equipment (the SIP clients) are completely
under the control of the users. If I want to cheat I can just hack my SIP
client on my PDA in order to NOT release the call if the network (S-CSCF)
requests me to do so. Ok - I cannot do it myself, but my colleague here is
rather good in C++-Programming.

Operators see some fraud potential when it comes to billing / bearer
provision. That's why they want a mechanism that 
- allows the network to initiate a call release
- avoids certain actions from the UE
Some people furthermore like the idea that the BYE message is the only
trigger for session release - we heard some good comments on this list why
this might be reasonable. 

So if we choose Subscribe/Notify for that purpose then we should send it to
the entity that controls the bearer (P-CSCF / outbound proxy). And then we
still need to inform the UE and the other side. So again it would be best to
send a BYE. 

Keep on signaling!
Georg

> Von: Michael Hammer [mailto:[email-masked]]
> Gesendet: Donnerstag, 25. Oktober 2001 16:11
> An: Mayer Georg ICM N MC MI E71
> Betreff: Re: AW: [Sipping] 3G entities: Proxy or B2BUA?
> 
> 
> All,
> 
> of a lower layer initiated abort.  While here, we are talking about 
> one entity using another entity to gain service.  Should we also be 
> considering the possibility of using other messages?  If we 
> assume the

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Thu, 25 Oct 2001 13:31:35 -0400

inline [RRR].

-----Original Message-----
From: Mayer Georg ICM N MC MI E71 [mailto:[email-masked]]
Sent: Thursday, October 25, 2001 12:45 PM
To: 'Michael Hammer'

Hello Michael,

[RRR] I guess that there can a check and balance. For example, Proxy
indicates through SUBSCRIBE/NOTIFY that the UA needs to send a BYE. Now, UAs
ignore the request and, BYE is not sent. To protect against this situation,
a timer can be initiated. The entities like GGNS can cut-off the media after
certain time as soon as proxy indicates it via SUBSCRIBE/NOTIFY. That is,
the proxy will also communicate with the GGNS while it is communicating with
the UE. Or, there can be other mechanisms as well. This kind of mechanism
provides the proxy almost the equivalent power to that of the BYE.

[RRR] The other thing is that any system can be mis-used no matte what
mechanisms we define. All we need to do to guard against those mechanisms
and, SUBSCRIBE/NOTIFY may not be an exception.

[RRR] Yes, it seems to be very attractive and, I will depend on the SIP
experts to provide their opinion because it will have the fundamental impact
on the specification. If people do not agree to modify the SIP
specifications, the alternatives need to be explored including the
suggestions made above without delaying the work too much.

[RRR] I know that it would be good, but it is too restrictive. Let us
assume, per SIP rule, that UEs have to take certain actions. We have to find
solutions considering all cases. 

[RRR] The protocol and system design need to be robust enough to guard
against any mis-behavior of entities as well.

[RRR] No, BYE message triggers the release of both session and media (let us
not create unnecessary confusions.)

So if we choose Subscribe/Notify for that purpose then we should send it to
the entity that controls the bearer (P-CSCF / outbound proxy). 

[RRR] I guess so and, it will be GGNS per 3G specs.

And then we still need to inform the UE and the other side. 

[RRR] Yes, it is.

So again it would be best to  send a BYE. 

[RRR] It could be, but we may not have the SIP extension to do so. However,
the system can also be designed without sending BYE as well.

Keep on signaling!
Georg

---

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Fri, 26 Oct 2001 11:51:44 +0200

Good morning,

> Your proposal sounds to me like a REFER for a BYE, rather 
> than a NOTIFY.

There is a difference between the NOTIFY proposal and the usage of REFER:

NOTIFY: P-CSCF subscribes to a S-CSCF event package, i.e. P-CSCF acts as a
UE in that case. If the network initiated call release event ("nicre" -
spells nearly as nice, but sounds different) occurs at the S-CSCF it sends a
NOTIFY ->to the P-CSCF<- which is directly addressed. The P-CSCF then
releases the bearer. 

REFER: Upon occurence of "nicre", the S-CSCF sends a REFER ->to the UE<-.
The P-CSCF - if it wants to release the bearer immediately (which it should
do, as the user has no money anymore - i.e. nobody pays for the bearer) has
to sneak into the REFER method, which is destined to the user. To be sure it
does not miss one of these "REFER instead of BYE" messages, the P-CSCF
therefore needs to sneak in every REFER method.

Therefore I see a real advantage in the usage of NOTIFY and I see it as the
first step into the right direction. In doing so there are still some minor
and major open issues, which I would like to discuss:

a) Does P-CSCF subscribe to S-CSCF on a per-call basis or on a
per-registration basis? I would recommend it should do it on a
per-registration basis. Or is there any reason against that?

b) What happens if S-CSCF refuses the SUBSCRIBE request from P-CSCF? 

c) What we gain with the NOTIFY-based solution is a bearer release
mechanism. Still the question is open how we get the call control level back
to "call released/null" state. I still hope somebody is coming up with a
solution for that. 

After sending the NOTIFY, the scenario now looks exactly the same as the
"user walks out of radio coverage" scenario: P-CSCF releases the bearer and
should now inform both end entities and all proxies on the route about the
released call, in order to clear the call states. 

Keep on signaling!
Georg
ICM N PG SP ST SN1

> Von: Miguel A. Garcia [mailto:[email-masked]]
> Gesendet: Freitag, 26. Oktober 2001 08:24
> An: Anders Kristensen
> Cc: Michael Hammer; Mayer Georg ICM N MC MI E71; 'Sean Olson (EUS)';
> 'Rohan Mahy'; [email-masked]
> Anders:
> Your proposal sounds to me like a REFER for a BYE, rather 
> than a NOTIFY.
> 
> However, I must say that 3G operators have a lot of concerns 
> on the power
> of REFER (e.g., it could be used for abuse).
> 
> On the other hand, the REFER I-D says very clearly that the 
> UA, upon the
> reception of a REFER, should ask the user for permission to 
> proceed. So,
> if I get a REFER from the P-CSCF to send a BYE, I will always 
> say NO, and
> my client silently ignore it.
> 
> Therefore, NOTIFY seems to be a better solution.
> 
> /Miguel
> 
> Anders Kristensen wrote:
> > 
> > This makes a lot of sense to me. Just let the P-CSCF proxy set up an
> > "implicit" event subscription for the endpoint and send a 
> NOTIFY to it
> > when time's up, refering to the corresponding call leg in the body.
> > That's not inconsistent with baseline SIP like sending a 
> BYE would be.
> > 
> > Anders
> > 
> > Michael Hammer wrote:
> > >
> > > All,
> > >
> > > considering the possibility of using other messages?  If 
> we assume the
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
>

---

From: [email-masked]
Date: Fri, 26 Oct 2001 18:50:52 +0300

Hi Georg et al.

You compare REFER and NOTIFY mechnisms and say (here shortend):
REFER -> UE  and  NOTIFY -> P-CSCF
 
The same way, the REFER could also be sent to the P-CSCF, which
releases bearer and clears the call state (as in walk out of
coverage case).

Thus I see no such difference between the REFER and
NOTIFY solution.

Just that the problems a) and b) you've mentioned are not an
issue in the REFER to P-CSCF solution.

This is why I think the REFER is a better way, as REFER is meant to
trigger an action, wheras as NOTIFY is meant to inform about some
happening.

So we have nwo 4 alternatives to the B2BUA:

i) REFER to P-CSCF
ii) REFER to UA
iii) NOTIFY to P-CSCF
iv) NOTIFY to P-CSCF (is probably not so useful.)

Let's continue discussing about these alternatives and
elaborate the most useful solution to avoid the B2BUA!

cheers
 Bernie

>From: ext Mayer Georg ICM N MC MI E71
>[mailto:[email-masked]]
>Sent: 26. October 2001 12:52
>To: 'Miguel A. Garcia'; Anders Kristensen
>Cc: Michael Hammer; 'Sean Olson (EUS)'; 'Rohan Mahy'; [email-masked]
>Subject: AW: AW: [Sipping] 3G entities: Proxy or B2BUA?
>
>
>Good morning,
>

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 26 Oct 2001 09:12:10 -0700

Hi,

Comments inline..

[snip]
>> I'm also attaching the definition of B2BUA from bis-04 
with
>> a few comments:
>> > Back-to-Back User Agent: Also known as a B2BUA, this is 
a
>> > logical entity that receives an invitation, and act as a
>> > UAS to process it.  In order to determine how the 
request
>> > should be answered, it acts as a UAC and initiates a 
call
>> > outwards.  Unlike a proxy server, it maintains complete
>> > call state and must participate in all requests for a
>> > call. Since it is purely a concatenation of other 
logical
>> > functions, no explicit definitions are needed for its
>> > behavior.
>> 
>> I can imagine two areas of potential confusion with this
>> definition:
>> 
>> "acts as a UAS to *process* it"
>> 
>> and
>> 
>> "must *participate* in all requests"
>> 
>> I interpret these to mean merely that the UAS half of the
>> B2BUA must respond to each request with the same Via and
>> Contact handling rules as a UA, and that it must be a 
party
>> to each request, so that it can keep track of call-leg 
state
>> and CSeq numbers.
>
>Miguel> This is the key question. To me, one of the 
capabilities 
>of the B2BUA is to terminate the SIP signalling at the UAS, 
and 
>initiate SIP signalling at the UAC. One thing the B2BUA can 
do is 
>to change From, To, Call-ID headers, as the two signalling 
>relations in the B2BUA are just correlated by some internal 
logic.
>
>As such, terminating the signalling at the B2BUA means, to 
>populate the headers appropriately (for instance, the 
Contact 
>header in 200 for INVITE should point to the B2BUA). 

agreed

>As such, the
>B2BUA needs to understand all the extensions required by 
the 
>end points, in order to decide how to process them. 

No, I strongly believe the B2BUA only needs to understand 
the basic rules of call-legs; Contact, Via, and Route 
handling; and the interaction of INVITE/ACK/CANCEL/BYE.

>I have my 
>doubts that one can build a B2BUA with certain 
transparency. And
>of course, this is not what I understand from the 
definition of
>B2BUA in the spec. Perhaps Jonathan or Henning can comment 
on the
>intention of the definition.

Yes, I think a bit of clarification on the spec would be in 
order.

>> >> The main advantage of a B2BUA in this environment is 
that
>> it
>> >> signaling.  As a proxy is only involved in 
transactions,
>> it
>> >Yes, I understand that. The question is: is all needed?
>> >Are we willing to pay the price of having 6 or more B2BUA
>> >(that we don't know the behaviour for unknown headers,
>> >methods, bodies, etc) in the path of the call just to be
>> >able to send a BYE? IMHO the price is very expensive.
>> 
>> I know what you are thinking--each entity that is
>> labeled "proxy" in the 3G specs needs to be a B2BUA?  
That's
>> horrible.  That's not what I am proposing...
>
>Miguel> Once you have a general proxy acting as a B2BUA, 
you 
>need to multiply the figure by 4 (as a minimum), 
(originating 
>and terminating P-CSCF, originating and terminating S-
CSCF). 
>Maybe even more if you count I-CSCF, Application servers, 
etc.
>I would not like that in order to use a particular service 
>when I call you, all 8 proxies in the network need to be 
>upgraded with the latest software. If this is the case, I 
will
>never use the IMS defined by 3GPP and use just an Internet
>connection over GPRS.

No, of the 3G SIP servers, only the P-CSCFs need to B2BUAs, 
of which there are exactly one or two.  All the other SIP 
servers defined in the call path in 3G can be ordinary SIP 
proxies.

>> I can come up with an environment where only one SIP-
>> only "transparent" B2BUA is required (the P-CSCF).  You 
may
>> need to add another B2BUA and a media relay if complete
>> anonymity is required (but only for calls that request 
it).
>
>Miguel> Don't forget the terminating side (for mobile to 
>mobile call), so you have already 3 B2BUA.
>
>Don't forget the S-CSCF, that will be the next (logical for 
>certain people) step. So you have 5 B2BUA.

Should be an ordinary proxy

>Don't forget the Application Server (e.g., the pre-paid 
application
>server sending BYEs), so you have 7 B2BUA.

Can be an ordinary UA

>> The P-CSCF (in the visited network) needs to verify from 
the
>> home network that there is some billing relationship 
between
>> the visited and home networks.  The visited network can
>> subscribe to the account status of the subscriber from the
>> home network.  If the home network notifies the P-CSCF 
that
>> the account status is now deactivated, the P-CSCF (as a
>> B2BUA), can disconnect any calls in progress and prevent 
any
>> additional calls.  The home network is merely informing 
the
>> visited network that the home network will no longer
>> reimburse the visited network for the subscribers calls.
>
>Miguel> Charging is still unstable in 3GPP. So I will not 
>comment on this until I have a clear picture of the 
architecture.
>Certainly, the P-CSCF subscribing to the "credit status" of 
a
>user seems to be a feasible solution. Probably there are 
others
>as well.

I hope that 3G will accept suggestions from the IETF 
community in this regard.

thanks,
-rohan

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Fri, 26 Oct 2001 14:53:56 -0400

inline [RRR2] ... SUBSCRIBE/NOTIFY still appears to be OK to solve the
problems ...

-----Original Message-----
From: Miguel A. Garcia [mailto:[email-masked]]
Sent: Friday, October 26, 2001 2:05 PM
To: Roy, Radhika R, ALCTA

Hi:

See my comments below.

/Miguel

"Roy, Radhika R, ALCTA" wrote:
> 
> All:
> 
> I am summarizing a little more. The complete picture looks like this:
> 
> Solution spaces:
> 
> A. UE A <-> P-CSCF1 <-> S-CSCF1 <-> UE B Communications (application layer
-
> e.g., calling cards, etc.)
> B. UE <-> GGSN and/or GGSN <-> P-CSCF1 Communications (network layer -
e.g.,
> bearer etc.)
> 
> Two probable alternate solution areas:
> 
> 1. B2B UAs
> 2. REFER/NOTIFY/SUBSCRIBE
> 
> I am only talking about the REFER/NOTIFY/SUBSCRIBE case only and, let me
> analyze the requirements very briefly.
> 
> The serving proxy S-CSCF1 can be either in the visited network or in the
> home network. 

Miguel> This is wrong. The S-CSCF can be located ONLY in the home network.
This is to guarantee that your services are still available even when you
roam.
But this does not change any assumption of the discussion.

[RRR2] It depends (may be 3GPP folks made a specific case for a specific
configuration .. let us generalize the solution ... let us assume that the
proxy that provides services can be located in any network ...).

> In any situation, we can assume that S-CSCF1 will only be
> responsible for services (e.g., calling cards, etc. - appln. layer), not
> about the bearer. So, we can assume that P-CSCF1 needs to SUBSCRIBE to
> S-CSCF1 for the service related events.
> 
> However, P-CSCF1 is only be located in the visited network and, it can be
> said safely that it will be communicating with both S-CSCF1 and GGSN. 

Miguel> That is also not exactly right. There are combinations where the 
P-CSCF communicates with the S-CSCF (e.g., non roaming case). But there
are situations where there is a hiding proxy (I-CSCF) in between the 
P-CSCF and the S-CSCF. 

[RRR2] That can be true, but there has to be a relationship between the
hiding proxy and the P-CSCF and/or S-CSCF. So, SUBSCRIBE/NOTIFY can be sent
accordingly. Taking 3GPP's given configurations, we can generalize the
solution.

> It
> will be aware of both services (via S-CSCF1) and media (via GGSN). So, for
> any events related to media both UE and S-CSCF1 need to SUBSCRIBE to
> P-CSCF1.
> 
> If this is the case, it appears that NOTIFY becomes the logical choice.
So,
> the SUBSCRIBE/NOTIFY becomes more attractive solution.
> 
> (If both P-CSCF1 and S-CSCF1 are aware of the media and/or service related
> events, subscriptions need to be made accordingly. I have elaborated these
> situations here for simplicity.)
> 
> Let me address issues raised by Georg:
> 
> a. Does P-CSCF subscribe to S-CSCF on a per-call basis or on a
> per-registration basis? Yes, I agree with you that it is better to be per
> registration basis.
> 
> b. What happens if S-CSCF refuses the SUBSCRIBE request from P-CSCF? The
> answer is: There has to be a business relationship between the home
network
> and the visited network. As a result, S-CSCF1 cannot refuse a proper
> SUBSCRIBE request.
> 
> c. What do we gain with the NOTIFY-based solution is a bearer release
> mechanism? The biggest advantage is that we do not violate or temper any
SIP
> rules: UAs will be able to send BYE to terminate both session and media.
> 
> Best regards,
> 
> Radhika R. Roy
> [email-masked]
> 
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 26, 2001 11:51 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: AW: [Sipping] 3G entities: Proxy or B2BUA?
> 
> Hi Georg et al.
>

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Fri, 26 Oct 2001 16:08:55 -0400

-----Original Message-----
From: Lawrence Conroy [mailto:[email-masked]]
Sent: Friday, October 26, 2001 4:02 PM
To: Roy, Radhika R, ALCTA; Bert Culpepper; [email-masked];

Please can someone explain (in a little more detail) why they think
that this is not possible to implement (i.e. why it won't work).

[RRR] B2BUA does work. The question is: What are the implications in
implementations?

All the best,
    Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 26 Oct 2001 13:27:16 -0700

Radhika,

Bert is correct.  The SIP roles are *roles*.  An entity 
which initiates its own SIP requests is NO LONGER a proxy.  
It may be a proxy 30ms before, and then again 30ms later.

The reason I am so insistent on the role of B2BUA for the P-
CSCF, is that in order to initiate a BYE you need to either 
be a party to the original INVITE, or you need to 
lie/cheat/pretend that you are.  A server that switches 
roles all the time is likely custom-built special-purpose 
software, but a transparent B2BUA is generically useful, and 
possibly off-the-shelf software.

thanks,
-rohan

---- Original message ----
>Date: Fri, 26 Oct 2001 15:24:28 -0400
>From: "Roy, Radhika R, ALCTA" <[email-masked]>
>To: Bert Culpepper <[email-masked]>, 
[email-masked], [email-masked], 
[email-masked], [email-masked]
>Cc: [email-masked], [email-masked], 
[email-masked], [email-masked]
>inline [RRR] ...
>From: Bert Culpepper [mailto:bert.culpepper@intervoice-
brite.com]
>Sent: Friday, October 26, 2001 2:31 PM
>To: Roy, Radhika R, ALCTA; [email-masked];
>
>
>I see the discussion moving from a proxy sending a BYE to 
proxies
>subscribing to and notifying each other, all to support a 
network
>initiated termination requirement.
>
>[RRR] Per SIP rule, a SIP Proxy cannot send BYE requests.
>
>Just to be clear, as soon as a SIP proxy generates *any* 
SIP request it
>is no longer a SIP proxy by definition.
>
>[RRR] Not necessarily. For example, SUBSCRIBE/NOTIFY can be 
sent by UAs or
>SIP Proxies equally.
>
>So let the p-CSCF, s-CSCF, x-CSCF send a BYE when it wants 
to and be done
>with it. 
>
>[RRR] Again, per SIP rule, a proxy cannot send BYE requests.
>
>It is only *not* a SIP proxy for that one SIP transaction.  
>
>[RRR] So, it breaks the SIP rule as a proxy. It has to be a 
UA.
>
>No changes to the SIP spec are required and this behavior 
breaks nothing in
>the SIP network.
>
>[RRR] A proxy does break the SIP rule, if it sends BYE 
requests. But a proxy
>behaving as B2BUA can send the BYE request.
>
>Maybe I'm missing something here and simplifying too much.  
If so, I
>apologize :(
>Regards,
>Bert

---

From: [email-masked]
Date: Mon, 29 Oct 2001 10:28:34 +0200

Hi Rohan!

I assume your comment is about SUB/NOT vs. REFER.

In any case, there needs to be some kind of filtering
for emergency calls.

On the other hand, emergency calls are AFAIK not routed
through the home network and no home services are involved.
Thus, there won't be a REFER coming from the home network
for such a session.

So far I haven't seen any reason, why SUB/NOT is a better
solution than REFER. I can see only _less_ problems than
using SUB/NOT.

Please "enlight" me, in case I miss something.

Have fun!

cheers,
 Bernie

>From: ext Rohan Mahy [mailto:[email-masked]]
>Sent: 26. October 2001 19:22
>To: [email-masked]
>I'd just like to add one point here.  If the user is making 
>an emergency call, and at that moment the S-CSCF decides 
>that the user cannot make call anymore, you probably don't 
>want to disconnect the emergency call.  A SIP SUBSCRIBEr can 
>*do* things based on changing state.
>
>thanks,
>-rohan
>
>
>>Date: Fri, 26 Oct 2001 18:50:52 +0300
>>From: <[email-masked]>
>>To: [email-masked], 
>>>UE in that case. If the network initiated call release 
>event ("nicre" 
>>-
>>>do, as the user has no money anymore - i.e. nobody pays 
>for 
>>>the bearer) has
>>>to sneak into the REFER method, which is destined to the 
>user. 
>>>To be sure it
>>>Therefore I see a real advantage in the usage of NOTIFY 
>and I 
>>>see it as the
>>>to "call released/null" state. I still hope somebody is 
>coming 
>>>up with a
>>>solution for that. 
>>>
>>>After sending the NOTIFY, the scenario now looks exactly 
>the 
>>>same as the
>>>"user walks out of radio coverage" scenario: P-CSCF 
>releases 
>>>the bearer and
>>>> > This makes a lot of sense to me. Just let the P-CSCF 
>proxy 
>>>set up an
>>>> > when time's up, refering to the corresponding call leg 
>in the 
>>body.
>>>> > > of a lower layer initiated abort.  While here, we 
>are 
>>>> talking about
>>>> > > signaling within the layer, not between layers, this 
>is 
>>>> still the case of
>Should 
>>>> we also be
>>>> > > Invite/Bye messages are the domain of the end 
>system.  
>>>> Could there also be
>>>> > > a Notify type message rather than a Bye that 
>indicates, 
>>>> to the controlling
>>>> > > UA "You are about to lose your bearer (because I 
>control 
>>>> that flow to the
>>>> > > public Internet/other carrier, etc.), add more 
>credit, or 
>>>> terminate and
>>>> > > Bye would seem more appropriate, but goes against 
>the 
>>>> grain of end-user
>>>> > > control.  Thought it might be useful to briefly 
>consider 
>>>> if other SIP
>>>> > > methods would work.
>>>> > >
>>>> > > Mike
>>>> > >
>>>> > > At 07:26 PM 10/24/2001 +0200, Mayer Georg  ICM N MC 
>MI E71 
>>wrote:
>>>> > >
>>>> > > >Hello again!
>>>> > > >
>>>> > > >there are two UAs. It seems to be a valid 
>interpretation 
>>>> that this means
>>>> > > >the B2BUA should act as a UA-S on the incoming and 
>a 
>>>> UA-C on the outgoing
>>>> > > >side (of a Request). Reading then the procedures of 
>a UA 
>>>> (also in the
>>>> > > >Ok, one could say there is a "transparent" B2BUA - 
>but 
>>>> what is this? Where
>>>> > > >is it defined? It is currently not defined and if 
>one 
>>>> tries to define it,
>>>> > > >she/he in the end needs to add the "transparent" 
>B2BUA 
>>>> specific behaviour
>>>> > > >under every line in the SIP Draft (and the 
>supporting 
>>>> Drafts) which
>>>> > > >mention UA behavior. Else the definition is either 
>as 
>>>> restrictive as
>>>> > > >stated above or it is open for interpretation - and 
>I do 
>>>> not know which of
>>>> > > >Well, I agree, we can do that - but this introduces 
>a 
>>>> complete new entity
>>>> > > >- one that I would not like to name B2BUA, because 
>it is 
>>>> something like a
>>>> > > >The problem is that if you follow the definition of 
>UA 
>>>> and B2BUA, a B2BUA
>>>> > > >release. This - furhter more - would cause that 
>both S- 
>>>> and both P-CSCF
>>>> > > >need to act as B2BUAs for every call. So each end-
>to-end 
>>>> call would be
>>>> > > >splitted up in five (!!) call-pieces which all 
>would 
>>>> have their unique
>>>> > > >call-id, etc. etc. .
>>>> > > >
>>>> > > >I know, 3GPP has sent out a long wish-list for 
>christmas 
>>>> (don't ask for
>>>> > > >the year) and this specific item on the list is 
>very ... 
>>>> interesting.
>>>> > > >
>>>> > > >Keep on signaling!
>>>> > > >
>>>> > > >Georg
>>>> > > >
>>>> > > 
>>>> > > >>This would be ideal. Unfortunately I do not 
>believe it 
>>>> is correct.
>>>> > > >>
>transactions, it
>>>> > > >>A B2BUA has the advantage and the burden of 
>keeping 
>>>per-call-leg
>>>> > > >>the overhead of maintaining this call-leg state. 
>It is 
>>>precisely
>>>> > > >>because a B2BUA maintains call state that it 
>cannot be 
>>>> transparent
>>>> > > >>have this problem, nor does a proxy. What about 
>future 
>>>> extensions
>>>> > > >>that create "call legs" that the B2BUA does not 
>know about? 
>>For
>>>> > > >>example, SUBSCRIBE for RFC2543 based B2BUAs. What 
>about 
>>>> the Replaces:
>>>> > > >>INVITE requests that use SMIL or the next 
>generation of 
>>>> SDP? Does
>>>> > > Use [email-masked] for questions 
>on current 
>>sip

---

From: "Keith Robinson" <[email-masked]>
Date: Mon, 29 Oct 2001 14:31:29 +0000

It seems to me you can either (a) use core SIP functionality (as defined in
2543-bis) to provide core network functionality (network initiated release
using BYE) or
(b) use non-core SIP functionality (SUB/NOT extensions) to provide  core
network functionality. To ensure interoperability, (a) seems the logical
choice.

Regards,

K. Robinson.

Rohan Mahy <[email-masked]>@ietf.org on 26/10/2001 21:27:16

Sent by:  [email-masked]

To:   "Roy, Radhika R, ALCTA" <[email-masked]>
cc:   Bert Culpepper <[email-masked]>,
      [email-masked], [email-masked],
      [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked]

Radhika,

thanks,
-rohan

---- Original message ----
brite.com]
proxies
network
SIP request it
sent by UAs or
to and be done
UA.
breaks nothing in
requests. But a proxy
If so, I

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 29 Oct 2001 15:19:45 -0000

"Alternative" is the wrong word. All your "alternatives" depend on the UA
still being there.

We still need a mechanism for when the UA does not respond to these
procedures. In these cases, something else must still generate a BYE and
remove resources under the control of the P-CSCF and the S-CSCF (the
outbound proxies).

Which brings us back to where we started - we either have procedure A plus
procedure B or procedure B by itself. I am not sure why we want use a
procedure that requires a UA to perform additional functionality over and
above that defined in standard SIP, when if it fails to response we still
need to bend the rules of standard SIP in order to generate a BYE anyway.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From:
> [email-masked][SMTP:[email-masked]]
> Sent: 	26 October 2001 15:50

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 29 Oct 2001 08:21:24 -0800

Bernhard,

In my proposal, the visited network subscribes to the 
account status of the mobile subscriber from an entity in 
the home network.

  SUBSCRIBE sip:[email-masked]
  From: "BT" <sip:[email-masked]>
  To: "Rohan Mahy" <sip:[email-masked]>
  Event: account-status

  NOTIFY sip:[email-masked]
  Event: account-status
  Content-Length: ..

  Status=Active

The first time the mobile subscriber registers with the 
visited network in some period of time, the PCSCF subscribes 
to that user's account status.  Upon receipt of the NOTIFY 
with status=active, the PCSCF knows that the home network 
will reimburse them for calls (yes, this is a gross 
oversimplification).

The SIP entities in the home network no longer need to keep 
any state except for registration and subscription state.  
They can send their billing information to their billing 
system when they receive SIP messages, and they can respond 
to an external change in account status by sending a NOTIFY 
showing the changed account state:

  NOTIFY sip:[email-masked]
  Event: account-status
  Content-Length: ..

  Status=Disabled;reason=theft

On receipt of this NOTIFY, the PCSCF knows that the home 
network will no longer reimburse the visited network for the 
current call (if any), or any subsequent calls.  Calls which 
aren't reimbursed (service calls, emergency, etc) can still 
go through.

I hope this helps.

thanks,
-rohan

---- Original message ----
>Date: Mon, 29 Oct 2001 10:28:34 +0200
>To: [email-masked]
>>>This is why I think the REFER is a better way, as REFER 
is 
>>meant to
>>>>There is a difference between the NOTIFY proposal and 
the 
>>>>usage of REFER:
>>>>
>>>>NOTIFY: P-CSCF subscribes to a S-CSCF event package, 
i.e. 
>>>>P-CSCF acts as a
>>>>spells nearly as nice, but sounds different) occurs at 
the 
>>>>S-CSCF it sends a
>>>>NOTIFY ->to the P-CSCF<- which is directly addressed. 
The 
>>P-CSCF then
>>>>releases the bearer. 
>>>>
>>>>REFER: Upon occurence of "nicre", the S-CSCF sends a 
REFER 
>>>>->to the UE<-.
>>>>The P-CSCF - if it wants to release the bearer 
immediately 
>>>>(which it should
>>>>first step into the right direction. In doing so there 
are 
>>>>still some minor
>>>>a) Does P-CSCF subscribe to S-CSCF on a per-call basis 
or 
>>on a
>>>>per-registration basis? I would recommend it should do 
it 
>>on a
>>>>c) What we gain with the NOTIFY-based solution is a 
bearer 
>>release
>>>>mechanism. Still the question is open how we get the 
call 
>>>>control level back
>>>>should now inform both end entities and all proxies on 
the 
>>>>route about the
>>>>> On the other hand, the REFER I-D says very clearly 
that 
>>the 
>>>>> UA, upon the
>>>>> reception of a REFER, should ask the user for 
permission 
>>to 
>>>>> > That's not inconsistent with baseline SIP like 
sending 
>>a 
>>>>> BYE would be.
>>>>> > 
>>>>> > Anders
>>>>> > 
>>>>> > Michael Hammer wrote:
>>>>> > >
>>>>> > > All,
>>>>> > >
>>>>> > > Another thought from left field.  In some 
protocols, 
>>>>> there is the concept
>>>>> > > >Reading the RFC 2543bis-04 defintion of a B2BUA 
it 
>>>>> clearly states that
 
>>>>> > > >introduce it mainly because of the case of 
network 
>>>>> initiated session
>>>>> > > >> >needs to understand every method, header, 
codec, 
>>etc that
>>>>> > > >> >This assumption is fortunately not correct.  
It 
>>is possible,
>>>>> > > >> >transparently passes headers, method, and 
bodies 
>>that it
>>>>> > > >> >does not directly understand.  An anonymizer 
is 
>>a perfect
>>>>> > > >> >can keep per-call-leg state and can be 
involved 
>>in mid-call
>>>>> > > >> >can only handle pre-call features.  A B2BUA 
can 
>>insert SIP
>>>>> > > >> >messages (for example BYE messages), run 
timers, 
>>and may
>>>>> > > >> >change the required headers: (To, From, Call-
ID, 
>>CSeq,
>>>>> > > >>not understand the REFER extension, what 
happens? 
>>It could
>>>>> > > This list is for NEW development of the 
application 
>>of SIP