Subject: Re: [Sipping] Early media in the INVITE offer/answer context

From: William Marshall <[email-masked]>
Date: Mon, 9 Dec 2002 09:05:55 -0500 (EST)

(trimmed the cc list to give Gonzalo a break on the list management)

> In addition to that, those mechanisms [using a different offer/answer
> context] will not always work. A dialog in
> the backwards direction can be routed to a different UA that the one
> making the call.

I fail to see the problem here.  Once a dialog is established, the UAS
can send SIP requests (e.g. UPDATE) and be guaranteed that they reach
the particular UAC that initiated the session.  This is through the use
of the Route and Contact headers.  What is the issue with using those
same routing headers with a different Call-ID for establishing an
additional dialog between the same parties?

Note that this strategy is used in several instances in 
draft-rosenberg-sipping-app-interaction-framework.

Bill Marshall
[email-masked]

-----original message-----
Date: Sun, 08 Dec 2002 18:42:54 +0200
From: Gonzalo Camarillo <[email-masked]>
To: "Peterson, Jon" <[email-masked]>
Cc: "'Rohan Mahy'" <[email-masked]>,
        "'Francois Audet'" <[email-masked]>,
        "'William Marshall'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>,
        "'Alan Johnston'" <[email-masked]>,
        "'sipping'" <[email-masked]>, "'Adam Roach'" <[email-masked]>
Subject: [Sipping] Early media in the INVITE offer/answer context

Folks,

as summarized in my previous mail, Jon questions the validity of sending
early media within the same offer/answer context as the original INVITE.
He brought up several issues, some conceptual and some technical.

Conceptual issues:

The SIP status codes already provide information about how session
establishment is progressing, so we should discourage the use of inband
information for the same purpose.

Early media that does not relate directly to call establishment (e.g.,
"Gonzalo is upstairs...", or listening to a comercial while you are
waiting for the callee to pick up) should not be part of the same
offer/answer context as the original INVITE.

Technical issue:

Forking may be difficult to handle if 18x responses with SDP are used.

My response to the conceptual issues:

It is true that the status codes already provide information about how
session establishment is progressing. However, we do not need to limit
this information to the information that can be conveyed using a status
code. If I want to use personallized ring back tones, I should be able
to do it. When Jon calls, I want him to hear my special ringback for him
(i.e., "Hi Jon, I will be with you shortly"). We may claim that this is
a stupid way of wasting badwidth, but this is not up to the protocol
designers to decide.

My point is that early media related to session progress should be
allowed.

Regarding how we establish early media, I agree that using a different
offer/answer context than the original INVITE informs the UAC that this
is another type of media. While I find this distintion conceptually
interesting (and I agree with), I am not sure whether or not it is a
useful distintion.

The signalling for setting up a different dialog or sending back a URL
to be retrieved by the client is going to represent an important
overhead. If you have to negotiate and establish QoS for this new media
stream again it will take long... and if you are using a cellular
terminal, it can take even longer...

In addition to that, those mechanisms will not always work. A dialog in
the backwards direction can be routed to a different UA that the one
making the call.

Sending a SIP URL may work, but some clients may have problems with that
as well. Some terminals will not want to reserve resources for two
streams at the same time.

We had this same discussion some time ago and Jonathan released a draft
analyzing several alternatives for early media. The conclusion was the
UPDATE work. The whole idea of UPDATE is to do early media within the
same offer/answer context as the original INVITE. If we had not intended
to do that, something like the old COMET would have been probably enough
for the preconditions stuff.

My opinion is that all the three approaches for porviding early media
have pros and cons... and the conclusion may be to document the issues
that each of them have. Depending on the scenario, one or another may be
best.

Thoughts?

Thanks,

Gonzalo
_______________________________________________
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
_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 09 Dec 2002 16:32:09 +0200

Bill,

> (trimmed the cc list to give Gonzalo a break on the list management)

I appreciate that. Thanks ;o)
 
> of the Route and Contact headers.

As long as you are talking about the same dialog, everything works fine.

> What is the issue with using those

The Contact header has global scope. That is, you can take a Contact
header from one dialog and use it to establish another. It is supposed
to work.

However, the Route entries do not have global scope. A proxy may choose
to insert state information specific to the dialog in its Route entry.
You should not use Route entries outside their dialog, because things
may not work.

And if you do not use Route entries, it is difficult to ensure that a
request will land in the desired terminal. For example, while I am on
the phone (I have sent an INVITE), I will probably divert all my
incoming INVITEs to my SIP voice mail system.

Thanks,

Gonzalo