Re: [Sip] Draft submission: draft-ietf-sip-199-00

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi, 

>Should the 199 response contain a Contact header? And if yes, in case a proxy sends it, should it contain the address of 
>that proxy (since the UAS already sent a final response)?

IF the 199 is sent reliably be the proxy must contain a Contact header containing the address of the proxy, yes.

>Should we say that a proxy may only generate and send a 199 when it receives a final error response on an INVITE client 
>Transaction which was in the PROCEEDING state? (i.e. 1xx response was received before, so conceptually sending the 199 
>response is an action associated with the transition from PROCEEDING to COMPLETED)

I am not sure I understand. The idea IS to send 199 when a final error response is received by the forking proxy, if a 18x has previously been received.

Regards,

Christer




Christer Holmberg wrote:
> Hi,
>
> I agree it may be a good idea to not forbid sending it reliably.
>
> I do think it would be good to have text, saying that it can be sent unreliable even if reliable responses are required, though, so that proxies aren't forced to terminate PRACKs etc.
>
> Regards,
>
> Christer
>  
>
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of 
> Dale.Worley at comcast.net
> Sent: 21. kesäkuuta 2008 1:38
> To: sip at ietf.org
> Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
>
>    From: "Christer Holmberg" <christer.holmberg at ericsson.com>
>
>    [CHH] Whether the text should be in the document at all depends on if we
>    allow 199 to be sent reliably in the first place. Based on the comments
>    received so far we should not mandate 199 to be sent reliably, even if
>    100rel is required by the UAC. But, the question if whether we want to
>    FORBID sending it reliably.
>
> If we ever might allow 199 to be used for HERFP, we should admit the possibility of sending it reliably in the first draft.  Otherwise, we'll be locked out of sending it reliably in the future.
>
> Dale
> _______________________________________________
> 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
>
>   
_______________________________________________
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