1 Aug 2004 06:07
Comments on dialog-package 04
Cullen Jennings <fluffy <at> cisco.com>
2004-08-01 04:07:38 GMT
2004-08-01 04:07:38 GMT
I was always concerned about how this would work on a simple black phone. To work, the dialog state need to indicate the phone has gone off hook and is collecting digits even though it has not sent an INVITE yet. Likewise it needs to indicate when it was still off hook even though it had received a BYE. As a side note, unlike the state transition diagram in 3261, all phones I have seen have a state machine that includes these states. I like that the examples show the state being reported as a dialog with no to tag before the INVITE is sent. I think there should be explicit text in the document explaining this. Actually I think that a new state would be more appropriate but I can accomplish what I want if there is no new state and text explaining a dialog with no to tag. I'm still not sure how I am supposed to deal with it in the hang up case. If Alice has camped on Bob's phone. If Bob receives a BYE, but has not actually hung up and Alice sends an INVITE, Bob will return busy on phones that only support one call. Again, I think another state is the best way to deal with this but other ways are possible. I find the terminated state underspecified. How long will a device continue reporting that something is in the terminated state after it terminates. 0 seconds? This would violate the event subscription idea that state data is idempotent on subscribes. Infinite seconds? this clearly won't work. The draft should suggest something that does work not just leave it as a hanging open detail left for implementers to figure out. The idea of reporting SDP here scares the crap out of me. SDP has things like SRTP keying material. Do you really need to do this? None of the applications described in the beginning offered any motivation for this. It seems that if we are going to do this, we need to report two SDPs - the SDP(Continue reading)
RSS Feed