[asterisk-scf-dev] SessionCommunicationsIf Questions/Comments

[Joshua Colp]

This reply contains replies to some items. Replies may not be redeemed for prizes.

----- Original Message -----
> Greetings,
> 
> I've been able to pull a few minutes together lately to do some more
> in depth looking at the code developed for Asterisk SCF. I've been
> taking some notes on questions and comments I have along the way.
> 
> First off, this is really great stuff. I'm very excited to see all of
> this coming together. You guys are awesome. Thank you for all of your
> hard work so far!
> 
> Now, to my questions/comments ... I will start with some questions and
> comments regarding some things in SessionCommunicationsIf.ice.
> 
> 
> 1) ResponseCode class
> 
> 1.a) For clarification, the value encapsulated here is the ISDN cause
> code, correct? The ones in causes.h of Asterisk 1.X?
> 
> http://svnview.digium.com/svn/asterisk/trunk/include/asterisk/causes.h?view=markup

Correct. Right now there is no centralized place to store a list of human readable names that map,
but we can for shizzle do that in slice.
 
> 
> 2) Session and SessionListener interfaces
> 
> 2.a) I see that ResponseCode is used as a parameter in 4 places:
> 
> - progress() and stop() for the Session interface
> - progressing() and stopped() for the SessionListener interface
> 
> The use of the cause values make sense to me for stop() and stopped(),
> but I don't understand how it maps to progress() / progressing(). It's
> not clear to me when progress() / progressing() are supposed to be
> used. "progress" has a special meaning in telephony protocols, so is
> it the same thing as that? That seems to be the case based on existing
> usage so far.
> 
> I see that the SIP session manager calls progressing() when it
> receives a 183 Session Progress. The ResponseCode it provides with
> that is 42. Where does 42 come from? 42 is CONGESTION in ISDN cause
> code land.

That was to get things rolling, not meant for long term consumption.
 
> If the mapping to/from 183 Session Progress or an ISDN PROGRESS
> message is correct, then perhaps the ResponseCode parameter should
> just be removed?

Thinking about it further I believe you are correct.
 
> 2.b) How should 100 Trying for SIP or PROCEEDING in ISDN map to these
> interfaces? I couldn't find a way to do that right now.

That's because there is none, it hadn't crossed our minds as something that needed
to be mapped into Asterisk SCF.

> 2.c) This one is a bit pedantic ... I see that SessionListener has a
> method called ringing(), while Session has ring(). I propose that they
> both be ringing(). ring(), to me, sounds more like a command to ring a
> phone (or make an outgoing call), not send notification that the far
> end is ringing, which is what they both appear to be for.

I could see how someone could read into it as doing that, changing it would
be fine with me.
 
> 
> 3) SessionInfo class
> 
> 3.a) What is the overview of the intent of this class? What are some
> example use cases of what/when this information would be wanted or
> needed?

It's a class that contains general session interface. One use could be querying
a session manager component, getting a list of sessions, and then getting the
information for each. It's informational.

> 3.h) One thing that struck me as missing in the
> SessionCommunicationsIf was "identity" information. I'm referring to
> the caller ID, connected ID, and redirecting ID type things. That
> information probably belongs in SessionInfo, but there are likely some
> methods that need to be added to the Session and SessionListener
> interfaces, as well. Or is this the wrong place for that information?

Yes, the whole ID thing (caller/connected/etc) has yet to be explored in Asterisk SCF.
You are probably correct on what you have said though for where things need to be.

-- 
Joshua Colp
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org