Subject: RE: [Sipping] TISPAN

From: "Warren, Dan, VF UK - Technology \(TS\)" <[email-masked]>
Date: Tue, 7 Jun 2005 09:39:58 +0100

Miguel, Richard

The ENUM service described was proposed to GSM-A by one specific company, and is still under discussion.  It is being fought strongly by Vodafone for a number of reasons, not least that which you describe below, and also because of the potential impacts the discrimination between addresses based on the presence of the IMS specific identification would have on session handling.  It is NOT an agreed GSM-A requirements and as such is not agreed to be in the GRX, although there is still some work to be done to chase the proposal away completely.

If either or both of you would like to provide further ammunition, please feel free to mail me back away from the list.

Cheers

Dan 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Miguel Garcia
> Sent: 07 June 2005 08:25
> To: Stastny Richard
> Cc: Sipping (E-mail)
> Subject: Re: [Sipping] TISPAN
> 
> 
> Richard:
> 
> First time I hear about such ENUM service. I am not following 
> what the 
> GSM-A is doing, so I can't really comment.
> 
> /Miguel
> 
> Stastny Richard wrote:
> 
> >>so once more, I
> >>don't recall any point of non interoperability.
> > 
> > 
> > Nice to hear.
> > 
> > I just wonder for what reason GSM-A required for their ENUM 
> implementation
> > in GRX e164.3gppnetwork.org (or whatever it will be) to 
> have an additional
> > special enumservice (either SIP+IMS or SIP:IMS) to 
> distingiush between
> > IMS SIP and vanilla SIP?
> > 
> > If what you said is true, they do not need this
> > 
> > regards
> > 
> > Richard
> > 
> > ________________________________
> > 
> > Von: Miguel Garcia [mailto:[email-masked]]
> > Gesendet: Mo 06.06.2005 09:22
> > An: Stastny Richard
> > Cc: Jonathan Rosenberg; Sipping (E-mail)
> > Betreff: Re: AW: [Sipping] TISPAN
> > 
> > 
> > 
> > Inline comments.
> > 
> > Stastny Richard wrote:
> > 
> > 
> >>Well said, Jonathan!
> >>
> >>
> >>
> >>>I think it is essential that we allow interoperability 
> between "vanilla"
> >>>SIP clients and ones on an IMS network.
> >>>I don't see any reason why any
> >>>call feature would be applicable only to IMS or NGN or TISPAN or
> >>>whatever network.
> >>
> >>
> >>They do. The basic idea of TISPAN and 3GPP NGN IMS is to be 
> in a walled
> >>garden and not in central park, becauae this is insecure 
> and to be sure of  this
> >>they want to be non-intereoperable.
> >>
> > 
> > 
> > Richard:
> > 
> > I cannot disagree more with your words. I am trying to 
> recall from my
> > memory one single point where a vanilla SIP client couldn't 
> interoperate
> > with a SIP client connected to the IMS or to an NGN network, and
> > honestly speaking, I can't recall any. The only thing that 
> comes to my
> > memory was that, at some point in time, 3GPP required all 
> the sessions
> > to use preconditions, so interoperability with those 
> vanilla SIP clients
> >   that did not implement preconditions wasn't possible. 
> This limitation
> > was relaxed in the Release 6 of the 3GPP specifications, so 
> once more, I
> > don't recall any point of non interoperability.
> > 
> > /Miguel
> > 
> > 
> > 
> >>regards
> >>Richard
> >>
> >>
> > 
> > 
> > --
> > Miguel A. Garcia           tel:+358-50-4804586
> > sip:[email-masked]
> > Nokia Research Center      Helsinki, Finland
> > 
> > 
> > 
> > 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email-masked]
> Nokia Research Center      Helsinki, Finland
> 
> 
> _______________________________________________
> Sipping mailing list  https://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  https://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