Subject: RE: [SIP] Contact in OPTIONS

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 29 May 2000 14:57:32 -0400

One example of when a proxy might want to step out of the signalling path is
that of overlap outpulsing in a gateway situation.  The proxy might stay in
the path until it had determined that all digits had been collected.  At
that point, having translated the digits to an ultimate destination, it
could retire from the call.  

> -----Original Message-----
> From:	Lars Berggren [SMTP:[email-masked]]
> Sent:	Monday, May 29, 2000 5:46 AM
> To:	Henning Schulzrinne
> Cc:	Adam B. Roach; Jo Hornsby; Jonathan Rosenberg;
> [email-masked]
> Subject:	Re: [SIP] Contact in OPTIONS
> 
> On Fri, 26 May 2000, Henning Schulzrinne wrote:
> > Adam B. Roach wrote:
> > > 
> > > Actually, I thought B was somewhat controversial; I'm surprised
> > > that it was changed without a lot of discussion on the list.
> > > Personally, I have no objection to the new behaviour; I just
> > > severely dislike the fact that it is not backwards compatible
> > > with the 2543 draft. Specifically, 2543-based call-stateful
> > > proxies (including firewalls) will break in all kinds of ways
> > > with 2543bis-based clients, if this change is finalized. Yuck.
> > 
> > Consider the inclusion in 2543bis as an incentive to reach closure. It
> > might help to provide real examples where Record-Route is essential and
> > whether they'd be better off with next-request or rest-of-call
> > semantics. Firewalls clearly fall into the rest-of-call class.
> > 
> 
> I recall an earlier discussion on the list where arguements were made that
> the next-request behaviour would help a UA that crashes, reboots and
> receives a re-INVITE for the call. The INVITE is designed so that it 
> carries the information necessary to join the session regardless of
> whether you know about previous requests or not. The next-request
> mechanism would adhere to that design decision.
> 
> Also, in favour of the next-request behaviour, if the route can be changed
> as the call progresses, I guess it can be useful. A proxy might want to
> step out of the signalling path for example, but I don't have any real
> world example on this.
> 
> However I also dislike the fact that the next-request mechanism is not
> backwards compatible.
> 
> /Lars
> 
> Lars Berggren       <mailto:[email-masked]>
> Intertex Data AB    tel: +46-8-6282828
> Sundbyberg, Sweden  fax: +46-8-6286414
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 29 May 2000 22:19:39 -0400

> Tom-PT Taylor wrote:
> 
> One example of when a proxy might want to step out of the signalling
> path is that of overlap outpulsing in a gateway situation.  The proxy
> might stay in the path until it had determined that all digits had
> been collected.  At that point, having translated the digits to an
> ultimate destination, it could retire from the call.

Careful here; the way overlap is currently designed, the proxy would not
have any choice about dropping out or staying in until the call
completes. Record-Route takes effect only after the 200 OK. Thus, in
your example, the proxy can elect to receive all of the overlap digits
and then "drop out" by simply never inserting record-route in the first
place. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip