Subject: [SIP] Questions on draft-rosenberg-sip-app-components-00.txt

From: Alan Johnston <[email-masked]>
Date: Fri, 01 Dec 2000 22:33:00 -0600

Jonathan/Peter/Henning,

A couple of questions about some of the examples in your excellent and
informative draft. (If I could only get some of the MEGACO proponents in
my organization to read and understand it...)

1. On page 16, section 5.4, referring to Figure 3, you say:

   "The next step for the AS is to get a
   stream of DTMF digits to flow from the caller to the media server. To

   do this, it sends a re-INVITE to the caller (11). This re-INVITE
   contains the same SDP as the response (6) from the called party, but
   with the addition of a new media line. This media line is audio, and
   contains a single codec, the RTP payload format for DTMF and tones
   [8]. The connection address and port are from the SDP returned from
   the media server. This tells the caller to send an additional media
   stream to the media server, using only the DTMF codec. "

I'm not sure I understand what the SDP in the re-INVITE should look
like.  Lets say the SDP in the 200 OK (6) from the Callee contained:

c=IN IP4 100.101.102.103
m=audio 5004 RTP/AVP 0

Lets say the SDP in the 200 OK (3) from the Media Server contained:

c=IN IP4 200.201.202.203
m=audio 53000 RTP/AVP 96  (Not sure about this line, but it would
indicate port 53000 and the DTMF encoding)

The text says that media line from (3) is added to the SDP from (6), but
what about the connection line which has a different IP address?  I'm
not sure that the SDP of

c=IN IP4 200.201.202.203
m=audio 5004 RTP/AVP 0
m=audio 53000 RTP/AVP 96

would have the desired effect.  Normally, wouldn't this SDP say to send
media to ports 5004 and 53000 at 200.201.202.203 (since the actual
intent is to send the PCMU to port 5004 at 100.101.102.103)?  Or, would
this SDP look completely different?

2. In Figure 5, the IVR call flow shows the Callee sending IVR commands
to the IVR Server after the receipt of the 183 Session Progress, but
before any 200 OK.  I think this could be useful, but I'm wondering if
User Agents that support Early Media like this would actually send RTP
packets prior to getting a 200 OK.  For example, if a Gateway to the
PSTN sends a 183 Session Progress, it may not include the a=sendonly
attribute, but any RTP packets prior to call completion in the PSTN
would be simply dropped.

3. In Figure 9, the Web Enabled Message Drops call flow, I am trying to
decide if the first message should be a HTTP POST or a GET as it is
shown. Your description indicates that a single click activates the
service - the trigger is simply that the particular URL has been
accessed.  I understand that each mailbox for each user would have a
URL.  My question is how the Web Caller's SIP URL is sent to the
Controller, since the Controller initiates the INVITE (3).  Would it be
somehow imbedded as a parameter in the URL?  Or, should the message be a
POST, in which case the Web Caller would type in their SIP URL, click
the submit button, and the combination of the URL and the form data
would give the controller enough information to setup the call.
Finally, one perhaps dumb question relating to this example.  If the SIP
User Agent and the HTTP Client were on the same machine, couldn't the
Web Caller just click on a link containing a SIP URL (instead of a HTTP
URL) of the desired mailbox which would cause the caller's SIP User
Agent to simply place the call?

Again, thanks for detailing this very useful method of decomposition.

Alan Johnston

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 10 Dec 2000 18:39:49 -0500

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]]
> Sent: Friday, December 01, 2000 11:33 PM
> To: Jonathan Rosenberg; Peter Mataga; Henning Schulzrinne
> Cc: SIP List
> Subject: [SIP] Questions on draft-rosenberg-sip-app-components-00.txt
> 
> 
> Jonathan/Peter/Henning,
> 

Thanks! I consider this draft an important one. As applications grow more
complex, and people begin to build more and more sip enabled servers, we
need to have a way to talk about and understand how these all work together.

> like.  Lets say the SDP in the 200 OK (6) from the Callee contained:

Bert has answered this one correctly, so let me address the rest of your
questions.

> attribute, but any RTP packets prior to call completion in the PSTN

This all gets back to the meaning of early media, and is something I hope to
discuss during IETF. The idea here is that there is nothing about the
INV/183
exchange that implies unidirectional media. If we decide that this is too
liberal an interpretation of early media (which it may very well be), the
same flow can be accomplished using re-INVITEs.

> would give the controller enough information to setup the call.

There are several ways. Certainly the form post can work. Another way is
that
the user browsing the web page has previously signed up for this service,
and during
that process, gave their SIP URL. The web server returned a cookie. Upon
revisiting the
page, the server can determine the URL of the user from the cookie provided
to the server.

> Agent to simply place the call?

Assuming that the call was to be made to a VoIP phone on that PC, yes. The
advantage of
placing the call from the controller is that the SIP URL can route to a PSTN
gateway,
ringing the phone of the user. Or, it can call a different VoIP client on
another machine.
Its a matter of flexibility.

-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: (973) 952-5000
http://www.dynamicsoft.com