Subject: RE: [Sip] The Problem with PRACK

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 15 Mar 2006 10:06:34 +0100

Hi,

A simple use-case, not necessarily related only to 3G, is when one wants
only to use a single codec. The UAC then send his lists of codecs, gets
back the UAS list of codecs, and then send a new offer with only one
codec both supports.

Because, unfortunately there is no mechanism in SIP/SDP to say: "here is
my list of codecs, please choose one (or whatever number)". In H.248 we
DO have that capability, using the ReserveValue/Group properties ;)

Another use-case is where the first offer indicates "inactive", e.g.
because of radio bearer and/or other resource reasons, and then want to
be able to change that to "sendrecv" before 200 OK.

Regards,

Christer 

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: 15. maaliskuuta 2006 10:52
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Sip] The Problem with PRACK

Juha Heinanen writes:

 > still don't get it.  why can't the 3g proxy allocate bandwidth for
the  > highest bandwidth codec in the invite?

... and then possibly reduce the allocation when 200 OK comes back or
remove the allocation completely if something else comes back.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 15 Mar 2006 11:18:47 +0200

> back the UAS list of codecs, and then send a new offer with only one

this is theoretical, since many existing SIP implementations don't
return a list of codecs, but only one, so there would be nothing else
for the UAC to choose from.  if UAS would return many, why can't the UAC
send a re-invite after ACK?

 > be able to change that to "sendrecv" before 200 OK.

i don't understand the example, but again, why can't re-invite be used?

why i'm pissed off because of PRACK is that now some non-3gpp SIP UAs
have tried to implement it and most of them have done it somehow wrong.
customers who buy these phones then complain to me about it.  if SIP UA
vendors can't get it right, the feature is clearly too complicated and
must be deprecated.

-- juha