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

From: "Culpepper, Bert" <[email-masked]>
Date: Mon, 4 Dec 2000 15:42:29 -0600

If I may, I'll take a shot at 1.

> -----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,
> 
> 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?

I believe the authors leave it to the reader to decide how to build the 
SDP component to specify the desired media destinations.  Using 
your example a complete media description will be as follows.  (The 
c= line in the session desc. (not shown) will have the callee's IP 
address, the a= line below shows the event format specified in 
RFC 2833).

m=audio 5004 RTP/AVP 0
m=audio 53000 RTP/AVP 96
c=IN IP4 200.201.202.203
a=rtpmap:96 telephone-event

The above indicates a different destination for the second media 
stream according to RFC 2327 (SDP).

> 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
> 

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

---

From: Alan Johnston <[email-masked]>
Date: Tue, 05 Dec 2000 11:12:30 -0600

Thanks very much, Bert!  I never noticed that capability in RFC 2327.

Alan.