[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Thoughts on SIP Identity issues
I believe that the problem statement (and associated use cases) that John presented in the WG session are valid. I think it was unfortunate that those use cases couldn't be discussed more in the WG session. This email appears to me simply John trying to further the discussions to bring out arguments.
One particular note I would like to share - given a comment at the mic regarding 4474 working as designed and desired - is that there are situations (good, bad or indifferent) that necessitate changes in the SDP. John cited media steering as a use case. Another use case is media steering for transcoding. Use case below:
Ent A--->SSP1--->Ent B
In this use case, Ent A and SSP1 have established certain "rules of engagement", like G729, 2833, t.38, etc. Ent B and SSP1 have established their own "rules of engagement", for instance G711 for voice, inband DTMF/FAX, etc. Being there's no common denominator for the media, the SDP in INVITE "steers" to a device that can trancode.
Another use case, would be for those SSPs that have Lawful Intercept requirements. Steering the media to something that will can intercept should that be a regulatory obligation.
Adam
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
> Cullen Jennings
> Sent: Tuesday, July 29, 2008 7:21 PM
> To: Elwell, John
> Cc: SIP IETF
> Subject: Re: [Sip] Thoughts on SIP Identity issues
>
>
> On Jul 29, 2008, at 17:53 , Elwell, John wrote:
>
> > Flawed argument 2:
> > The problem exists when we go through service providers. Service
> > providers use only E.164-based SIP URIs. We can't do anything about
> > E.164-based SIP URIs. Therefore we can't do anything to address the
> > case
> > where the request goes through service providers. Therefore there is
> > nothing we can do.
>
>
> Hmm, I don't think anyone made quite that argument. Personally, I'd
> rather spend time thinking about the problems that were presented
> today in the meeting than repeat previous discussions.
>
> Cullen <with my individual hat on>
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip