Re: INFO Framework - one pakage per INFO

> That's not always technically possible, AFAICT.  If the body 
> content is bad, there's no guarantee it even got to the app-layer.
> 

Now you are getting really confused on layers. These are the circumstances where the correct error is 4xx - 6xx indicating that the SIP level was unable to deliver to the application.

regards

Keith 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email protected]] 
> Sent: Friday, December 05, 2008 3:31 PM
> To: Elwell, John; Paul Kyzivat; DRAGE, Keith (Keith)
> Cc: SIP List
> Subject: RE: [Sip] INFO Framework - one pakage per INFO
> 
> 
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On 
> Behalf Of 
> > Elwell, John
> >
> > I think the 488 precedent was unfortunate. If you send SDP 
> offer in a 
> > reliable provisional response or a 2xx response, 488 isn't 
> available 
> > to you (except I suppose you could put a Reason header in 
> the PRACK or 
> > ACK request, but I don't really want to go there).
> 
> The same could be said of 413, 415, 493, etc.  If the UAC 
> can't fundamentally handle an INVITE response's body, it can 
> send a CANCEL, with the Reason header.  I thought that was 
> the point of the Reason header - to be able to send the 
> failure reason in requests.
> From RFC 3326:
>    "SIP responses already offer a means of informing the user of why a
>    request failed.  The simple mechanism in this document accomplishes
>    something roughly similar for requests."
> 
> 
> > So I don't think we need we need a way of indicating in an INFO 
> > response problems with body content in the request.  Let the 
> > application send an INFO request in the reverse direction.
> 
> That's not always technically possible, AFAICT.  If the body 
> content is bad, there's no guarantee it even got to the app-layer.
> 
> -hadriel
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip