Subject: [Sipping] Re: Summary of: Meaning of status codes

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

> [CHH] At this point I think there is another question we need to add to this
> discussion: does the SDP/non-SDP have anything to do with the meaning of the
> status code?

It is my belief that all the work done with offer/answer was intended to
completely separate the SDP/non-SDP from the meaning of the status code.
Any remnant of a link between them is due only to a pre-3261 (and pre
2543bis-05) design.

> [CHH] Now I wonder what you mean by saying that "a gateway has be be
> prepared to stop local ringback when the first madia packets arrive". Of
> course, a media gateway has to be prepared, in the sense that SOMETHING
> triggers it to stop local ringback, and one could also argue that it should
> be able to receive media packets while still generating local rinback, to
> avoid clipping. However, I don't think we have agreed that the media packet
> as such should be a trigger to stop local ringback, have we (there has been
> concerns raised about that solution proposal)?

As you said, this is needed to prevent clipping.

A particularly bad UA design (or a particularly bad local policy) is to
clip the start of media.  It leads to upset customers on both ends.
If we've not yet agreed to prevent this, we should do so.  Note that
the UAS can certainly _cause_ clipping, by not completing the offer/answer
until the 200-OK final response, but then it bears all the responsibility
for the botch.

Bill Marshall
[email-masked]

-----original message-----
Date: Mon, 09 Dec 2002 10:42:07 +0200
From: Christer Holmberg <[email-masked]>
To: Gonzalo Camarillo <[email-masked]>
Cc: "Peterson, Jon" <[email-masked]>,
        "'Rohan Mahy'" <[email-masked]>,
        "'Francois Audet'" <[email-masked]>,
        "'William Marshall'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>,
        "'Alan Johnston'" <[email-masked]>,
        "'sipping'" <[email-masked]>, "'Adam Roach'" <[email-masked]>
Subject: Re: Summary of: Meaning of status codes

Hi,

I appologise if some of you already got this mail, but since it didn't show
up on the mailing list I thought something may have gone wrong when sending
it.

Anyway, I have a couple of comments (inline) on the summary.

> I will try to summarize all the discussions so far in this thread.
>
> Adam, Fracois Audet, Rohan, Jon and Gonzalo stated that if the callee is
> being alerted, 180 is the right status code to use.
>
> Alan, John Hearty and Michael Hammer said that current gateways send a
> 183 (even if the user is being alerted) when there is early media.
> Therefore, in order to be backward compatible, they would like to avoid
> using 180 with SDP.

[CHH] At this point I think there is another question we need to add to this
discussion: does the SDP/non-SDP have anything to do with the meaning of the
status code?

> Jon said that vanilla SIP UAs should not send early media with the same
> offer/answer context of the original INVITE. He gave some alternatives
> to the 18x with SDP approach. 18x with SDP would be used only by
> gateways.

[CHH] Here I think it is important not to forget the manyfolks resrource
reservation mechanism. There was a comment that the 183 would be used "in a
wrong way there", and that can of course be discussed separately, but let's
not forget there is a scenario where the UAS (no matter what kind of SIP
node it is) will have to send 18x with SDP.

> As I see this, we have two issues:
>
> 1) how big is the backwards compatibility problem that Alan brought up.
>
> 2) 18x with SDP for early media: is it conceptually correct for vanilla
> UAs? are there technical issues?
>
> I will send a separate note about 2).
>
> About 1), I am not sure whether or not we face a backwards compatibility
> problem. The issue is that an ingress gateway (UAC) will generate local
> ringback upon reception of a 180 (even if it has SDP).
>
> Let's suppose that we do not have early media in a particular call. A
> current gateway that uses the strategy described above, will have to be
> prepared to stop local ringback when the first media packets (the
> "hello" from the callee) arrive, because it cannot rely on receiveing
> the 200 OK first (there is a race condition).
>
> Therefore, current gateways are already prepared to stop local ringback
> if inband alerting is received (the gateway will not know if what is
> being received is the "Hello" or "beep, beep...")

[CHH] Now I wonder what you mean by saying that "a gateway has be be
prepared to stop local ringback when the first madia packets arrive". Of
course, a media gateway has to be prepared, in the sense that SOMETHING
triggers it to stop local ringback, and one could also argue that it should
be able to receive media packets while still generating local rinback, to
avoid clipping. However, I don't think we have agreed that the media packet
as such should be a trigger to stop local ringback, have we (there has been
concerns raised about that solution proposal)?

> I do not see any issue here that keep us from sending a 180 and inband
> ringing at the same time. Alan, can you elaborate on what you believe is
> the problem?

[CHH] From my point of view the problem is the same as it has been from the
beginning: how does the UAC know if it should expect early media or not
(note: I didn't say there there always will be early media in this case).
Yes, we could agree that a UAS always send 180 when the called party has
been alerted (this is what I thought was supposed to be the focus of this
discussion, but it seems like we are once again trying to solve all issues
at once...), but that still doesn't mean we have solved the early media
issue. Again, I don't think we have agreed to use the detecting-of-media
mechanism to decide if to generate local ringback or not.

In any case, I'm glad you did this summary, because at least I find it very
difficult to follow the discussion, now when it once again has taken off in
different directions.

Regards,

Christer Holmberg
Ericsson Finland
_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Mon, 09 Dec 2002 17:31:45 +0200

Hi,

> until the 200-OK final response, but then it bears all the responsibility

Well, as I said, you could choose to pass media even if you do generate local
ringback, to avoid clipping (yes, you will have a short period of media mixed with
the local ringback, and I don't know how much happier the customer will be by
that), but my point was that we haven't agreed that the RTP packet itself should
stop the local ringback generation. There are a number of issues, related to both
media and signalling,  related to that solution which we would have to answer
before making such a decission.

Regards,

Christer Holmberg
Ericsson Finland