Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

From: "Taylor, Carol-Lyn D" <[email-masked]>
Date: Mon, 9 Nov 2009 04:51:50 -0500

Leaving Frankfurt now 4:50am your time - 9hr flight
--------------------------
Sent using BlackBerry

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Christer Holmberg <[email-masked]>; Jeroen van Bemmel <[email-masked]>; DRAGE, Keith (Keith) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Mon Nov 09 04:17:56 2009
Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert Recv-Info header

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 09 November 2009 07:55
> To: Jeroen van Bemmel; DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [sipcore] INFO EVENT @ IETF#76: When to insert 
> Recv-Info header
> 
> 
> Hi, 
> 
> >I also think it's overkill. Furthermore, I don't see a real world use
> case for changing the set of supported INFO 
> >packages mid-dialog. Surely the UAS can simply reply with a 403
> response when it receives an INFO request which it 
> >doesn't want to process anymore?
> >
> >To me, INFO packages should be like the Dialog's route set: learn the
> supported set from the initial INVITE and 1xx-2xx 
> >responses, after that don't change it anymore
> 
> I think Adam made the same comment in the SIPCORE session.
> 
> Personally I think there could be cases where one wants to 
> add a package
> during a dialog. For example, assume I call you. Then, during 
> the dialog
> we decide to start using application X which uses an Info Package, so
> our phones send Recv-Info:X to each other. Application X may 
> not even be
> running when we initiate the dialog.
> 
> However, if we are going to require the header in a lot of messages,
> maybe we should remove PRACK from the list of allowed messages. Would
> people have problems with that?
> 
> But, I would like Paul to comment whether mandating the 
> header in every
> message would actually solve his 3pcc use-case.
> 
> >PS The usage of 'nil' to denote no supported packages is not 
> consistent
> with conventions used today, e.g. for Supported 
> >(suggest to simply use an empty value instead)
> 
> I think there was some WGLC comment(s) asking about the same thing.
> Personally I have no problem to use an empty header instead of 'nil'.
> However, I want to ensure that nobody objects to such change before I
> implement it.
[JRE] I made that comment during WGLC, but received no support at the time. I would still prefer to follow normal conventions.

John

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore