Subject: RE: [SIP] Remote ringback.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 15 Aug 2000 17:58:47 -0700

Ok, if 180 is to be used for remote ringback (ie SDP in the 180 response)
then I believe that a reference needs to be made to this usage in
RFC2543bis; a clarification is also needed on the different handling of a
180 with or without SDP (for instance, if a 180 response is received with an
SDP body is it a SHOULD or a MAY that the specified audio stream should be
played?); and lastly, an example should be placed somewhere (either in
RFC2543 or otherwise definitely in the call flows draft). 

The 183 draft also needs also be explicitly clarified in this respect.[IMO]

Cheers,

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 
> -----Original Message-----
> From: Taichi Fu [mailto:[email-masked]]
> Sent: Friday, August 11, 2000 12:31 PM
> To: Fairlie-Cuninghame, Robert; [email-masked]'
> Cc: [email-masked]
> Subject: Re: [SIP] Remote ringback.
> 
> 
> At 07:28 PM 8/10/00 -0700, Fairlie-Cuninghame, Robert wrote:
> >
> >At the SIP bakeoff, a colleague had a conversation with one of the
> >co-authors of the 183 Session Progress draft.
> >
> >He (the co-author) informed us that 183 is meant to be used 
> when the remote
> >UA wants to provide 
> >some other, unknown message/signal - and _not_ simply remote 
> ringback.
> >
> >180 with an SDP body should be used for that purpose.
> 
> >This came as quite a surprise as it seems to be at odds with 
> RFC2543 which
> >makes no mention about the validity or handing 180 with SDP 
> and states that
> >183 SHOULD include an SDP for session progress tones (or 
> announcements).
> >[Without defining session progress tones.]
> 
> The rfcbis (Aug. 06 from http://www.cs.columbia.edu/sip) 
> states that 180 is to indicate that the some attemp is made 
> to alert the called party while 183 is to indicate 'progress 
> of the call which is not otherwise classified' (p.62). So the 
> distinction between 180 and 183 seems clear in rfcbis. Maybe 
> there is still a little room left to exactly define the 180 
> and 183 semantics, but if it is certain that a called party 
> is located and alerting is being applied successfully, I 
> think 180 should be used. If it is not certain, 183.
> 
> >Even the 183 draft seems to only associate 180 with local alerting.
> >
> >At the bakeoffs 183 seems to have been implemented widely for remote
> >ringback.
> >
> >Can anyone shed some light on this?
> >
> >Robert.
> >
> >-- My opinions are my own. I tried selling them once but everybody
> >	seems to already have one. -- 
> >
> >
> >
> >_______________________________________________
> >SIP mailing list
> >[email-masked]
> >http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Aug 2000 00:33:58 -0400

Simon Barber wrote:
> 
> According to the grammar multiple to and from lines are allowed (just as
> RFC822 allows multiple to and from addresses). 

Hows that? The BNF is quite explicit that it is a single name-addr or
addr-spec:

>  From         =  ( "From" | "f" ) ":" ( name-addr | addr-spec )
>                         *( ";" addr-params )
>         addr-params  =  tag-param
>         tag-param    =  "tag=" UUID
>         UUID         =  1*( hex | "-" )

>   To  =  ( "To" | "t" ) ":" ( name-addr | addr-spec )
>                *( ";" addr-params )

-Jonathan R.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Aug 2000 00:53:40 -0500

Jonathan,

Perhaps Simon was referring to the following, which says that a
general-header can occur any number of times in a message.  I saw no
reference to the restriction that a `From' could only occur once in a
message (although it makes sense).

> generic-message =
>         start-line *message-header CRLF [message-body]
> 
> message-header =
>         general-header |
>         request-header |
>         response-header |
>         entity-header
> 
> general-header =
>         Accept              ; Section 6.6
>          | Accept-Encoding  ; Section 6.7
>          | Accept-Language  ; Section 6.8
>          | Call-ID          ; Section 6.12
>          | Call-Info        ; Section 6.13
>          | Contact          ; Section 6.14
>          | CSeq             ; Section 6.20
>          | Date             ; Section 6.21
>          | Encryption       ; Section 6.22
>          | From             ; Section 6.24
>          | MIME-Version     ; Section 6.28
>          | Organization     ; Section 6.29
>          | Record-Route     ; Section 6.34
>          | Require          ; Section 6.35
>          | Supported        ; Section 6.41
>          | Timestamp        ; Section 6.42
>          | To               ; Section 6.43
>          | User-Agent       ; Section 6.45
>          | Via              ; Section 6.46

Jonathan Rosenberg wrote:                 (Wed, 16 Aug 2000 00:33:58)
-- 
Brian F. G. Bidulock
[email-masked]

---

From: "Simon Barber" <[email-masked]>
Date: Tue, 15 Aug 2000 21:14:04 -0700

According to the grammar multiple to and from lines are allowed (just as
RFC822 allows multiple to and from addresses). The text often refers to
comparisons involving the To line (single).

Are multiple To/From lines allowed?

Is there any equivalent of Bcc:?

Simon Barber

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Fairlie-Cuninghame,
Robert
Sent: Tuesday, August 15, 2000 5:59 PM
To: 'Taichi Fu'; [email-masked]'
Subject: RE: [SIP] Remote ringback.

Cheers,

Robert.

---

From: Laurent Steffan <[email-masked]>
Date: Wed, 16 Aug 2000 11:28:02 +0200

Actually, the draft does state that multiple headers are not always allowed:

"Multiple header fields with the same field-name may be present in a message
if and only if the entire field-value for that header field is defined as a
comma-separated list (i.e., #(values))." (par. 6.5, "Header field format")

Thats's the case for the Via: header, which can therefore appear multiple
times (or equivalently can contain several via values). That's not the case
for the From: field, so it cannot appear several times. At least that's how
I read it.

Best regards,
Laurent Steffan

======== le 16/08/00 7:53, Brian F. G. Bidulock à [email-masked] a
écrit : ========

>>> To  =  ( "To" | "t" ) ":" ( name-addr | addr-spec )

=======================================================================
Laurent M. STEFFAN                          Tel : + 33 (0)1 55 91 28 49
ATOS Consulting Technologies                Fax : + 33 (0)1 55 91 26 53
Les Miroirs, Tour C
18, av. d'Alsace                     Internet : [email-masked]
92926 Paris La Defense Cedex - France
=======================================================================

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Aug 2000 04:47:00 -0500

Laurent,

I figured it must be somewhere, I just missed it...

Thanks for the pointer.

--Brian

Laurent Steffan wrote:                     (Wed, 16 Aug 2000 11:28:02)

-- 
Brian F. G. Bidulock
[email-masked]

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 17 Aug 2000 13:19:28 -0400

----- Original Message -----
From: Fairlie-Cuninghame, Robert <[email-masked]>
To: 'Taichi Fu' <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 15, 2000 8:58 PM
Subject: RE: [SIP] Remote ringback.

> RFC2543 or otherwise definitely in the call flows draft).

For clarity, I agree that the rfc2543 should mention what receiving 180,
181, 182, 183 with an SDP for an INVITE explicitly means.

If A receives 18x with SDP from B, can/should A start sending to B?  I
assume no for 180 and yes for 181, 182 and 183 but I have not found it
explicitly stated anywhere.

There were some test cases that I was hoping to test at the bakeoff, but
didn't get the chance.  Text relating to the test cases may be useful in the
rfc.

- A invites B.  B replies 180 with SDP.  B then replies 180 without SDP.
Expected result: A should start providing local ringback.

- A invites B with multiple codecs.  B replies 180 SDP with codec 0; then B
replies 180 SDP with codec 2.  Expected result: A should stop using codec 0
and start using codec 2.

- A invites B.  A forking proxy was involved.  A forking proxy returned two
18x with SDP and different "TO" tags.  Should the received media be mixed?
 I assume no until maybe after having received a 200 on one of the legs.

> The 183 draft also needs also be explicitly clarified in this
respect.[IMO]

My understanding is that the 183 draft is expired, and any aspects from
the draft that were to be adopted have been pulled into rfc2543bis.

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 21 Aug 2000 18:42:39 -0400

----- Original Message -----
From: Henning Schulzrinne <[email-masked]>
To: Brett Tate <[email-masked]>; Jonathan Rosenberg
<[email-masked]>; <[email-masked]>
Sent: Monday, August 21, 2000 4:19 PM
Subject: Re: [SIP] Remote ringback.

> Since I'm just coming back to a week's worth of SIP discussion, can
> somebody summarize this discussion or its result, as I've lost track
> what, if any changes/clarifications, should be made to The Spec?
>
> My rough understanding is:
>
> - SDP in 1xx means take media from there, don't generate local ring
> tone. (I think there was an earlier discussion that "early media" should
> not be restricted to 180 or 183.)

When the 183 draft was folded into the rfc2543, I thought that
the SDP's presence in 181, 182 was to roughly mean
the same thing as an SDP in 180 or 183.  I am hoping to get
rfc2543 to clearly state what receiving a 18x with an SDP
specifically means.

In addition, does a connection address of not being 0.0.0.0
in a 183 SDP mean that the SDP sender is currently listening
for any dtmf, voice, etc?  Previous emails in this thread mention
possible uses.

>
> - Later 1xx's update SDP as usual. (This primarily affects where RTCP is
> to be sent.)

I agree, and I am hoping to get this explicitly stated in rfc2543.

>
> - Removing SDP switches back to local ring-back.

I agree, and I am hoping to get this explicitly stated in rfc2543.

>
> - It's up to the UA whether it wants to mix audio/video during call
> setup if it gets multiple 1xx due to forking. (If "early media" is an
> announcement like "the number you have dialed has been changed. The new
> number is ...", mixing with ring tone from another destination would be
> very confusing. Not sure what to do about this.)

I am just hoping for a suggested policy from a called/calling party
perspective.  If A does not intend to actually listen as a result of the
18x, should something indicate this as a result of guaranteed
provisional delivery.  ( I guess that some of this belongs in the
guaranteed provisional delivery draft. )

>
> This goes back to an earlier, long-ago discussion whether it's better to
> use 4xx/5xx for announcements, but if I remember right, the conclusion
> was that this wasn't always feasible since gateways wouldn't be able to
> distinguish failure announcements from ring tone. (I thought the
> announcement tri-tone was for stuff like that...)
>
> - If the caller wants to change its IP address during the call setup, it
> needs to CANCEL/BYE the call and try again. This may occur during really
> long call setups, e.g., if somebody called me last week and wanted to
> catch me as soon as I walked into the office this morning, so this is
> not completely hypothetical.

For basic SIP, I completely agree for simplicity reasons.  However
an extension could be possible to address this situation.  If
the REFER method can't be used, I assume someone might
propose a another extension.

>
> Thanks.
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Aug 2000 20:49:49 -0400

> for any dtmf, voice, etc?  Previous emails in this thread mention

Can you summarize for my benefit? I'm worried about anything that
*relies* on such a feature, as it is not likely to be interoperable and
has potential security implications. (I wouldn't want my microphone to
be active before the call is connected...)

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 21 Aug 2000 21:41:39 -0400

> be active before the call is connected...)

I completely agree with your concerns about voice being passed 
from calling party prior to 200/ACK; this is especially true for a 180.
However I think that inband DTMF should be possible when a 18x
has been passed containing a complete SDP with connection
address not being 0.0.0.0. 

I think that there is a potential concerning a 182 for A to pass inband
DTMF to move up in the queue.

I also foresee the same sort of DTMF possibility concerning a 181.  
It could be used concerning calling-verses-forwarding billing 
acceptance, to pick a forwarding location, or to allow an attempt 
to bypass the forwarding.

I also foresee using the same sort of DTMF possibilities with a 183.  
The user could select various options relating to the "special 
announcement".  The user could respond to a request to press "1",
as a means to inform the called that the caller wants setup to
continue to be tried.  The user could be requested to enter a 
location for a call-back when the called party actually answers.

I agree that the thought of two way media being established before 
200/ACK seems strange.  But I think that one way media is just as 
strange though useful from a PSTN perspective.

I don't think that there will be any backwards compatibility problems
since any services attempting such a thing would have to be
structured to know that PSTN or other protocol limitations might
restrict passing DTMF from occurring.  Also, many gateways and
networks will limit the length time in non-billable call setup.  Also,
the delivery of 18x might not always be guaranteed or played for
caller.

As always, just looking for clarity, simplicity, and cool new features.

Brett Tate
BroadSoft

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Aug 2000 16:19:53 -0400

Thanks.