> From: Wainwright, John [mailto:[EMAIL PROTECTED] > > I like the simplicity of it but I have a couple of questions/comments. > 1. I didn't want to make an assumption on the interface between the > softswitch and the media server - it does not have to be SIP
Although implicitly or explicitly, there will be a SIP User Agent which is the location where signaling transitions from SIP to whatever means is used to communicate with the Media Server, and that UA is what would execute these actions. > 2 At what point would the SDP/dialog data be updated in the > initial UA ? In > your sequence would this be between 6. & 7. after a 183 or > 200 is received ? As others have pointed out, RFC 3261 places tight restrictions on where SDP can be placed. Normally, the SDP in a 183 must be duplicated in the 200 that completes the transaction. But in this case, since the contact with the ultimate destination really is on a different fork of the INVITE from the Media Server, the completed dialog will have a different To-tag and thus be a different dialog than the early dialog established by the 183 from the Media Server. So the 200 can carry a different answer to the offer in the INVITE from the answer in the 183. But the completed dialog will cause the originating UA to terminate the early dialog. > From: Dale Worley > > 4. User sends information, Media Server collects and processes it to > determine required action. Though ideally you can avoid having to use a Media Server to capture the required information. In many cases, you can put a dialing prefix at the beginning of the number called. Then the switch can recognize the prefix, remove it, perform any special processing needed, and forward the call to the destination indicated by the remainder of the AOR. Dale _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
