Subject: RE: AW: [Sipping] 3GPP network hiding and session release req'ts

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 23 Oct 2001 09:07:32 -0500

I understand your concerns. The fact is that
the REFER mechanism does not *have* to be 
supported in the terminal for this application.
As I mentioned in a previous e-mail, no matter
what mechanism you use, you will need a timer 
in the P-CSCF to ultimately clean things up.
If the terminal/PC/whatever does not support REFER,
it will return a 5xx and the P-CSCF can act accordingly.
(Tear down bearers, etc.)

If you are concerned about SIP extensions not being
handled in the 3GPP proxy case, then here is a list
of things to start worrying about:

  1) Security (encryption, integrity protection, authentication, etc)
  2) Codecs 
  3) QoS (COMET, PRACK, 183 ...)
  4) IPv4
  5) DNS

  ...

Naturally, all of these can be solved. Using 
interoperability as an argument against REFER
is a bit short-sighted though considering all
the other interoperability issues that exist
in the current 3GPP architecture.

/sean

>-----Original Message-----
>
>Correct.  However, if you mandate that all 3GPP 
>devices support REFER, but in the below situation
>the 3GPP terminal proxies the REFER to a SIP endpoint
>which DOES NOT support REFER, what happens?
>
>The point I am trying to make is that if you 
>mandate that 3GPP terminals MUST support various
>extensions, then in the 3GPP proxy situation, all
>the SIP devices connected to it MUST also support
>the same extensions -- they cannot be SIP devices
>that only implement RFC2543 if you expect them
>to work gracefully.  
>
>So a 3GPP terminal that was functioning as a proxy
>could not be connected to a 'generic' SIP device
>that did not also support all mandated 3GPP 
>extensions, correct?  Otherwise, what is the
>behavior when the REFER reaches an endpoint 
>proxied through the 3GPP terminal that does not
>support REFER?
>
>Kim
>
>> "Sean Olson (EUS)" wrote:
>> 
>> >The only issue I see with this is that making such
>> >things mandatory in the 3GPP environment would seem
>> >to require that 3GPP endpoints be always endpoints
>> >and not proxies.  That is, it sounds like you could
>> >not have a wireless 3GPP last-mile-replacement to
>> >act as a proxy for a group of non-3GPP SIP phones
>> >without also mandating the same requirements.  (i.e.
>> >no 3GPP enabled computers/PDAs functioning as SIP
>> >proxies for fax machines, handsets, etc. on a local
>> >LAN, bluetooth network, etc.  No SIP<->3GPP<->SIP.)
>> 
>> This is not correct. The terminal could very well proxy
>> the REFER in the same manner that it proxies the INVITE,
>> BYE, etc.
>> 
>> >
>> >If no 3GPP endpoint is going to be allowed to
>> >function as such a gateway proxy, then it is a
>> >moot issue.
>> >
>> >--
>> >Kim Liu  [email-masked]    :  Everyone is a darn fool for at
>> >Senior Software Engineer    :  least five minutes a day;
>> >Lucent Technologies         :  wisdom consists of not
>> >Clearwater, FL, 33761       :  exceeding the limit
>> 
>> BR,
>> Sean Olson
>> Ericsson Inc.
>
>-- 
>Kim Liu  [email-masked]    :  Everyone is a darn fool for at 
>Senior Software Engineer    :  least five minutes a day;
>Lucent Technologies         :  wisdom consists of not 
>Clearwater, FL, 33761       :  exceeding the limit
>

---

From: Kim Liu <[email-masked]>
Date: Tue, 23 Oct 2001 10:23:49 -0400

I am not arguing against REFER -- I am pointing
out that the more extensions that are MANDATED
by the 3GPP, the more interop issues are going
to be created.  If the mechanism does not have
to be supported, then why mandate it?

Please see the original message I was replying
to.  I was referring to the statement "So why
not mandate also REFER."

> in the current 3GPP architecture.

I am not arguing against REFER specifically.  I
am more concerned that every additional 'mandated'
3GPP requirement takes it farther from interoperating
with a non-3GPP but SIP compliant end point connected
to a 3GPP terminal proxy.

If REFER is not mandated, then there is not an issue.

_______________________________________________
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