Subject: RE: [Sipping] Comment on draft-ietf-sipping-session-policy-req-01

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 1 Mar 2004 07:55:29 -0000

Yes, and any combination of multiple offer/answer sequences, and any new offer appearing in a request later in the call.

regards

Keith

> -----Original Message-----
> From: Miguel Garcia [mailto:[email-masked]]
> Sent: 01 March 2004 07:08
> To: ext Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Sipping] Comment on
> draft-ietf-sipping-session-policy-req-01
> 
> 
> Mmmm.... I am not sure what permuntations of RFC 3264 you are 
> referring 
> to. I don't believe RFC 3264 offers other options that "I give you an 
> offer, you give me an answer".
> 
> But I suspect that the requirement you are looking for is something 
> like: "The solution must support a model where the SDP offer 
> is present 
> in either a request or a response".
> 
> Is this correct?
> 
> /Miguel
> 
> ext Drage, Keith (Keith) wrote:
> > While this document does make some reference to RFC3264, in 
> REQ-POL-3, it seems to be missing a requirement something 
> along the lines of:
> > 
> > "The solution for use in conjunction with a session should 
> work in conjunction with all usage permutations of the 
> offer/answer model [3]."
> > 
> > regards
> > 
> > Keith
> > 
> > Keith Drage
> > Lucent Technologies
> > [email-masked]
> > tel: +44 1793 776249
> > 
> > _______________________________________________
> > 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
> > 
> 
> -- 
> ---
> Miguel A. Garcia           tel:+358-50-4804586
> 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

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 01 Mar 2004 12:26:19 +0200

I agree with Volker. And that comes back to my early comment, the only 
bit that perhaps is missing is to clarify that the solution needs to 
support an SDP offer included in a SIP request or a SIP response. The 
same applies for SDP answers, but I believe you want to police offers only.

/Miguel

ext Volker Hilt wrote:
> 
> Drage, Keith (Keith) wrote:
> 
>> Yes, and any combination of multiple offer/answer sequences, and any
>> new offer appearing in a request later in the call.
>>
> Yes, multiple offer/answer sequences is certainly something that needs 
> to be considered.
> 
> Having said that, I currently don't see a difference between the first 
> offer/answer and subsequent offer/answer exchanges. A proxy will insert 
> a policy if it thinks that it is necessary. Thus, if a re-INVITE changes 
> for example the IP-addresses in a session, a proxy might just pass it 
> along. In contrast, if a new codec is added in a re-INVITE, the proxy 
> might want to insert a policy. I think there is no need to repeat 
> policies that are already in use.
> 
> Volker
> 
> 
>>> -----Original Message----- From: Miguel Garcia
>>> [mailto:[email-masked]] Sent: 01 March 2004 07:08 To:
>>> ext Drage, Keith (Keith) Cc: [email-masked] Subject: Re:
>>> [Sipping] Comment on draft-ietf-sipping-session-policy-req-01
>>>
>>>
>>> referring to. I don't believe RFC 3264 offers other options that "I
>>> give you an offer, you give me an answer".
>>>
>>>  like: "The solution must support a model where the SDP offer is
>>> present in either a request or a response".
>>>
>>> Is this correct?
>>>
>>> /Miguel
>>>
>>> REQ-POL-3, it seems to be missing a requirement something along the
>>> lines of:
>>>
>>> work in conjunction with all usage permutations of the offer/answer
>>> model [3]."
>>>
>>>> regards
>>>>
>>>> Keith
>>>>
>>>> Keith Drage Lucent Technologies [email-masked] tel: +44 1793
>>>> 776249
>>>>
>>>> _______________________________________________ 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
>>>>
>>>
>>> -- --- Miguel A. Garcia           tel:+358-50-4804586 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
> 
> 
>

---

From: Volker Hilt <[email-masked]>
Date: Mon, 01 Mar 2004 21:32:49 +0900

Miguel Garcia wrote:
> same applies for SDP answers, 

Yes, I also believe this is an important requirement.

> but I believe you want to police offers only.
> 
I think most policies will probably only affect offers. However, there 
might be policies for answers. For example, a user might have a 
different bandwidth available on the up- and downlink and the provider 
wants to considers this with different policies for the two directions. 
Another example would be a policy that modifies elements of the SDP 
answer that are independent of the offer (e.g. the IP address).

Volker

>> offer/answer and subsequent offer/answer exchanges. A proxy will 
>> insert a policy if it thinks that it is necessary. Thus, if a 
>> re-INVITE changes for example the IP-addresses in a session, a proxy 
>> might just pass it along. In contrast, if a new codec is added in a 
>> re-INVITE, the proxy might want to insert a policy. I think there is 
>> no need to repeat policies that are already in use.
>>
>> Volker
>>
>>

---

From: Volker Hilt <[email-masked]>
Date: Mon, 01 Mar 2004 18:06:05 +0900

Volker