Subject: [Sipping] RE: Meaning of status codes

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Dec 2002 06:42:11 -0500

I think we're making progress here. Perhaps it all boils down to just this
one issue inline below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 3:09 AM
> To: Peterson, Jon
> Cc: Francois Audet; 'William Marshall'; [email-masked]';
> [email-masked]'; [email-masked]'; 'Alan
> Johnston'; sipping; Adam Roach
> Subject: Re: Meaning of status codes
> 
[snip]
> 
> > However, as I said above, early media
> > through gateways (the problem we are considering) is a case in which the
> > media stream is used to describe the status of the call.  This is not a
> > 'normal' SIP condition - native SIP should never do this. This is an
> > aberrant condition that occurs only in gateway interworking.
> 
> I believe that we are almost in agreement about everything but this
> part. You believe that a vanilla SIP UAS will never send early media
> with a 180, and I believe it MAY.
> 

There is a difference between a SIP user agent generating early media and a
gateway doing so. A gateway that relays in-band status information from the
PSTN in a media stream has no way of knowing what the status of the call is,
and hence what response code to send. A SIP user agent sends a 180 because
it actually knows that someone is being alerted. In the hardest early media
cases, where the gateway only receives an ACM yet the media may in fact
contain a busy signal, the gateway will not be able to send a SIP status
code that gives any indication of the progress of the call (hence the
leaning towards 183). In other words, the gateway MUST express its status
(even the most rudimentary concepts, like ringing or busy) in the media
session.

I think a SIP UAS has other ways to set up early media than with a 180, as
we've discussed in a separate thread. I see no reason why a separate dialog
in the backward direction could not be established if you want to play some
media that is discontinuous with the media of the call. It is not reasonable
for a gateway to do this, however - its early media is actually continuous
with the call. While I believe that a UAS should be able to establish a
media session when an INVITE transaction has not yet completed, I don't see
why it needs to be within the same offer/answer context proposed in the
original INVITE. 

In other words, I don't think we need to solve this problem (early media in
180) for vanilla SIP user agents - there are other ways this functionality
can be achieved, and doing it in 180 is complicated (and, in my mind,
un-SIPlike). Consider forking cases, for example. If you end up contacting
numerous UASs, all of which want to share some kind of audio message with
you ("Gonzalo is upstairs but will be here soon"), managing multiple such
media sessions in a single offer/answer context is problematic - if each UAS
established a separate dialog in the backwards direction, and a separate
o/a, it would be much more manageable. In any event, the SIP UAS has at
least the capability to express its status out-of-band with status codes -
this sort of audio message is supplemental to the status reported by the
status code, unlike the gateway audio which actually replaces an out-of-band
status indication.

I would prefer, as a matter of scope, to consider early media purely as a
gateway interaction problem. I think this is the hard problem, but also the
thing that needs solving (leaving aside for the moment the clipping issues).

And actually, one more note below.

[snip]
> 
> Note that I am not claiming that you MUST send a 180 if you have early
> media. I am saying that, if the user is being alerted, you MUST send a
> 180. But if the user is busy, you, of course, will not send a 180. 

In some cases, the gateway will not know what the media represents, or
whether or no the user is being alerted. That sort of MUST is tough to
enforce.

> You
> would send a "18x Busy" response or, if you do not have any 18x status
> code that is appropriate (because 18x Busy does not exist), you would
> send 183 Session Progress.
> 

Clearly, a 486 should be sent if the callee is busy and the gateway knows
this is true. The tough cases are the ones where the gateway doesn't know.
 
_______________________________________________
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: Aymeric MOIZARD <[email-masked]>
Date: Thu, 05 Dec 2002 17:19:40 +0100

Hi,

I was checking
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-00.txt
and found what is probably a mistake in a SIP message:

section 4.1: about the message samples:

       Via: SIP/2.0/UDP proxy1.work.com;maddr=1.2.3.4:5060

There is a "maddr" with a port inside? The bnf states that
maddr should contains a "host" only!

Just for info, I don't understand the meaning of the maddr here.
Shouldn't it be replaced by a "received" parameter here?

thanks
Aymeric