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

From: William Marshall <[email-masked]>
Date: Fri, 25 Jan 2002 13:56:07 -0500 (EST)

Alan Johnston wrote:
> Bill Marshall wrote:
> > 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.

But the problem is that 5.1 sent an INVITE listing all as a=inactive, so
the UAC is not preparing to receive any media at all.  It is not until the
second INVITE (after the called party has answered) that any receive
ports are assigned.  This is what causes the extreme post-pickup delay.

While I recognize that this call flow is perfectly legitimate in 2543
as well as bis, it has certain problems and should not be considered
as solving anything.

Bill Marshall
[email-masked]

-----original message-----
Date: Fri, 25 Jan 2002 12:40:08 -0600
From: Alan Johnston <[email-masked]>
Subject: RE: [Sip] Re: Unify draft and 1-of-N
To: "'William Marshall'" <[email-masked]>, [email-masked]

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.
> 
> 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.
> 

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.

> 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
> 

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Sun, 27 Jan 2002 13:44:57 -0500

> as well as bis, it has certain problems and should not be considered

Fair enough. I think that Alan's alternative, of instead loading the
first codec received, and then immediately re-inviting to prevent a
change, is probably better. 

In either case, bis is not going to contain any flows for "1 of N
negotiation", since that kind of stuff is in offer/answer. I wasn't
planning on putting this in offer/answer  either. To be honest, the nice
thing about the current offer/answer is that a UA can use either the
a=inactive or load-first-codec appraoch, without interoperability
issues, so long as the other side is offer/answer and bis compliant.
Thus, someone who NEEDS 0% risk of a codec change can use a=inactive,
most would use something like what Alan has suggested.

A FAQ or something could document the various ways to solve these
problems depending on the constraints of your system.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com