Subject: Re: [Sip] Re: Unify draft and 1-of-N

From: William Marshall <[email-masked]>
Date: Fri, 25 Jan 2002 08:33:05 -0500 (EST)

I'm very concerned about the call flow shown in section 5.1 of the
unify draft, which does codec negotiation through the use of a
Re-INVITE.

The main problem is the resulting post-pickup delay.  When more than
a few hundred milliseconds, it results in a failed call (from the
user's view) and a completed billable call (from the provider's
view).  Not a happy situation, especially if it occurs on every
call attempt.  Retraining the users is hardly an option.

The only way I see to resolve this is to delay the ringing until
the re-INVITE, when the codec set is known and the extra roundtrips
are not needed before the media path is established.  And this leads
to all the problems with the original two-stage invite.

The much better solution is shown in the unify draft in section 5.5,
figure 12, utilizing a COMET/UPDATE (message (5)) that picks the
codec to use.

I would really hate to see the re-INVITE of section 5.1 described 
in bis-06 because of not wanting to define the COMET/UPDATE method.
Much better to state that codec negotiation is not suspported in
bis, and requires an extension, and then not have to consider the
backwards compatibility problems with UA's that do the immediate
re-INVITE.

Bill Marshall
[email-masked]

_______________________________________________
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: Alan Johnston <[email-masked]>
Date: Fri, 25 Jan 2002 12:40:08 -0600

Bill,

See my comments below.

Alan Johnston
WorldCom
sip:[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of William Marshall
> Sent: Friday, January 25, 2002 7:33 AM
> To: [email-masked]
> Subject: Re: [Sip] Re: Unify draft and 1-of-N
> 
> 
> I'm very concerned about the call flow shown in section 5.1 
> of the unify draft, which does codec negotiation through the 
> use of a Re-INVITE.
> 
> The main problem is the resulting post-pickup delay.  When 
> more than a few hundred milliseconds, it results in a failed 
> call (from the user's view) and a completed billable call 
> (from the provider's view).  Not a happy situation, 
> especially if it occurs on every call attempt.  Retraining 
> the users is hardly an option.

No - this is not a problem.  If I send an INVITE listing three codecs
then I must be prepared to receive media from any of those codecs.  Once
the first media packet arrives, I load that codec and the call proceeds.

The 1-of-N is problem is that at some later date, the far end may switch
to one of the other two codecs that I do not currently have loaded.  As
a result, before this switch occurs, I need to re-INVITE to settle in on
the codec which is currently in use.

As a result, the re-INVITE has no effect on the media stream - no
dropped packets, interruptions, or post dial delay.  

> 
> The only way I see to resolve this is to delay the ringing 
> until the re-INVITE, when the codec set is known and the 
> extra roundtrips are not needed before the media path is 
> established.  And this leads to all the problems with the 
> original two-stage invite.

These are non problems unless the far end system does something crazy
like randomly switching between the set of codecs.

> 
> The much better solution is shown in the unify draft in 
> section 5.5, figure 12, utilizing a COMET/UPDATE (message 
> (5)) that picks the codec to use.
> 
> in bis-06 because of not wanting to define the COMET/UPDATE 
> method. Much better to state that codec negotiation is not 
> suspported in bis, and requires an extension, and then not 
> have to consider the backwards compatibility problems with 
> UA's that do the immediate re-INVITE.
> 

The re-INVITE call flow is perfectly legitimate in bis as well as RFC
2543 for that matter and any SIP system must be able to handle it.  If
your system does not support a re-INVITE it is a seriously broken UA.

> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>