[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] I-D on service identification now available
Hi,
>Rather than having the service invocation be an implicit
>side-effect of analyzing the signaling, I'd much rather have
>the invocation be explicit.
Both Jonathan's and Keith's draft are based on signaling analyzing
(including service id type of information), aren't they?
>Pre-loaded routes give us a reasonable way to do proxy services.
One needs to remember that routing towards the correct intermediates is
only one step. You also need to to be able to route the request towards
terminals which support the service.
>In cases where the services are implemented as B2BUAs, we
>don't need that sort of complexity.
>
>If Alice is calling Bob and wants to invoke a recorder for
>the call, Alice could send her initial request to the
>recorder-B2BUA, along with whatever parameters are needed
>(file format, location, billing account, etc.) and a URI to
>be used for Bob.
Based on the assumption that Bob knows that he has to invoke a recorder
in the first place (maybe he knows that in this specific example), that
Bob knows has the URI of the recorder (and possible all other
intermediates that need to be inserted), and that Bob knows where and in
which order to put the URI(s) in the pre-Route (there can also be other
pre-Route headers in the request).
I also think it's important to remember that RFC3261 allows a proxy to
forward requests pretty much based on ANY information (DNS lookups,
databases, signalling information etc etc), so I think it would unfair
to say that such behavior would "break" SIP as a protocol (no, I didn't
say that someone has said it as part of this thread).
Regards,
Christer
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP